WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Move beyond passwords

Move beyond passwords

Privacy & SecuritySafari & WebAuthentication
元の動画を見る

ハイライト

iOS 15 と macOS Monterey は、公開キーベースのパスキーを iCloud キーチェーンに保存してワンクリック ログイン、デバイス間同期、フィッシング対策を実現する WebAuthn テクノロジー プレビューを開始し、サーバーは認証キーを保存しなくなります。

主要内容

パスワードに関する根本的な問題

パスワードは何十年も前から存在しており、誰もがそれを使用しています。しかし、業界は、パスワードの利便性がセキュリティを犠牲にしていることをますます認識しつつあります。

Verizon 2020 Data Breach Investigations Report によると、ハッカー関連のデータ侵害の 80% 以上に、資格情報の総当たりクラッキングまたは紛失/盗難された資格情報の使用が含まれていました。

パスワードに関する主な問題は、パスワードが「共有キー」であること、つまりユーザーとサーバーの両方が同じ秘密を保持していることです。この秘密が送信されるたびに、傍受の危険が生じます。フィッシング攻撃、パスワードの再利用、脆弱なパスワードなどの問題はすべてこれに起因します。

既存の改善ソリューションには限界があります。

  • パスワード マネージャー: 強力なパスワードを生成できますが、セキュリティはマスター パスワードと同等です。
  • SMS/OTP 検証コード: まだ入力可能なフィッシング共有シークレット
  • フェデレーション認証 (Apple でサインインなど): 信頼を少数のアカウントに集中させますが、すべてのシナリオに適用できるわけではありません。

WebAuthn: 共有秘密の代わりに公開鍵

WebAuthn (Web 認証) 標準では、パスワードの代わりに公開キーと秘密キーのペアが使用されます。動作はまったく異なります。

  1. 登録時に、デバイスは公開鍵と秘密鍵のペアの鍵を生成します。
  2. 公開キーは保管のためにサーバーに送信されます (公開キーは公開することができ、機密性の要件はありません)。
  3. 秘密キーはデバイス上に残り、誰とも共有されることはありません
  4. ログインすると、サーバーはチャレンジを送信し、デバイスは秘密キーで署名した後に戻ります。
  5. サーバーは公開キーを使用して署名を検証し、身元を確認します。

秘密キーは、プロセス全体を通じてデバイスから離れることはありません。たとえサーバーが侵害されたとしても、攻撃者が入手できるのは公開鍵のみであり、公開鍵自体には何の価値もありません。

セキュリティ キーとパスキー

ハードウェアセキュリティキー（セキュリティキー）は、セキュリティに優れたWebAuthnに対応済みですが、ハードウェアの追加購入や持ち運びが必要となり、一般ユーザーにとっては使い勝手があまり良くありません。

Apple の解決策は iCloud キーチェーンのパスキーです。WebAuthn 認証情報を iCloud キーチェーンに保存し、WebAuthn のセキュリティと iCloud キーチェーンの利便性を組み合わせます。

  • ワンクリックログイン: 通常はワンクリックまたはFace ID認証のみ
  • クロスデバイス同期: すべての Apple デバイスで利用可能
  • 安全なバックアップ: すべてのデバイスを紛失した場合でも、iCloud から復元できます。
  • フィッシング対策: オペレーティング システムは、認証情報がそれを作成した Web サイト/アプリでのみ使用されるように厳しく制限しています。
  • エンドツーエンドの暗号化: Apple ですら読み取ることができません

テクノロジープレビューのステータス

macOS Monterey および iOS 15 では、パスキーはテクノロジー プレビューとしてリリースされ、デフォルトでオフになっています。 iOS の「設定 > 開発者」または macOS Safari の「開発」メニューで手動でオンにする必要があります。このプレビューはテスト専用であり、運用アカウントには推奨されません。

詳細

アカウントを登録する

(17:32)ASAuthorizationPlatformPublicKeyCredentialProvider登録リクエストを作成します。

func createAccount(with challenge: Data, name: String, userID: Data) {
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com"
    )

    let registrationRequest = provider.createCredentialRegistrationRequest(
        challenge: challenge,
        name: name,
        userID: userID
    )

    let controller = ASAuthorizationController(
        authorizationRequests: [registrationRequest]
    )

    controller.delegate = self
    controller.presentationContextProvider = self
    controller.performRequests()
}

キーポイント:

  • relyingPartyIdentifier通常はドメイン名で、アプリケーションと Web サイトを関連付けるために使用されます。
  • challengeサーバーから取得した1回限りのチャレンジ値です。
  • nameアカウント名はユーザーに表示されますか
  • userIDバックエンドアカウント識別子です
  • ASAuthorizationControllerシステムシートが表示され、Face ID/Touch ID で確認した後、登録を完了できます。

＃＃＃ ログイン

(17:39) ログインは登録と非常に似ていますが、代わりにアサーション リクエストを使用するだけです。

func signIn(with challenge: Data) {
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
        relyingPartyIdentifier: "example.com"
    )

    let assertionRequest = provider.createCredentialAssertionRequest(
        challenge: challenge
    )

    let controller = ASAuthorizationController(
        authorizationRequests: [assertionRequest]
    )

    controller.delegate = self
    controller.presentationContextProvider = self
    controller.performRequests()
}

キーポイント:

  • createCredentialAssertionRequestログインに使用されます (WebAuthn 用語では「アサーション」と呼ばれます)。
  • 必要なだけchallengeパラメータ、必須ではありませんnameそしてuserID
  • authorizationRequestsパラメーターは配列であり、パスワードの要求、Apple でサインイン、およびその他の認証方法を同時に渡すことができます。
  • システム シートには、利用可能なすべてのバウチャー オプションが表示されます

コールバックの処理

(17:41) デリゲート コールバックで登録またはログイン結果を処理します。

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    switch authorization.credential {
    case let registration as ASAuthorizationPlatformPublicKeyCredentialRegistration:
        let attestationObject = registration.rawAttestationObject
        let clientDataJSON = registration.rawClientDataJSON
        // 发送到服务端验证，完成账户创建

    case let assertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
        let signature = assertion.signature
        let clientDataJSON = assertion.rawClientDataJSON
        // 发送到服务端验证，完成登录

    default:
        break
    }
}

キーポイント:

  • 登録時に取得rawAttestationObjectそしてrawClientDataJSON、検証のためにサーバーに送信されます
  • ログイン時に取得しますsignatureそしてrawClientDataJSON、サーバーは公開キーを使用して署名を検証します。
  • 認証情報のデータ形式は WebAuthn Web API と一致しており、サーバー側のロジックを再利用できます

アプリケーションと Web サイトの関連付け

(19:46) プラットフォームによって提供されるフィッシング対策保護を有効にするには、関連ドメインで構成する必要があります。webcredentials関連付けの種類:

applinks:example.com
webcredentials:example.com

これにより、アプリと Web サイトの間に強力な関連付けが確立され、資格情報が正しいドメインでのみ使用できるようになります。

セキュリティキー API

(13:21) iOS 15 と macOS Monterey では、すべてのアプリに対してセキュリティ キー API も公開されています。これは ASAuthorization API ファミリの新しいメンバーであり、WebAuthn API とネイティブに同等です。

セキュリティ キーは、エンタープライズ アプリケーションや金融アプリケーションなど、高度なセキュリティ要件が必要なシナリオに適しています。ユーザーはハードウェア キーを購入して持ち歩く必要がありますが、最高レベルのセキュリティが受けられます。

重要ポイント

  • アプリにパスキーのサポートを追加: WebAuthn の登録とログイン フローを既存のログイン システムに統合します。サーバー側から開始して WebAuthn バックエンドを構築し、それを iOS アプリで使用しますASAuthorizationPlatformPublicKeyCredentialProviderフロントエンドを実装します。ユーザーは、Face ID を使用してワンクリックで登録およびログインできます。

  • 統合認証ポータル: 使用するASAuthorizationController配列パラメータ属性。パスキー、パスワード、および「Apple でサインイン」リクエストを渡します。システムは利用可能なすべてのオプションを自動的に表示し、ユーザーが最も便利な方法を選択できるようにします。

  • クロスプラットフォーム認証情報共有: 合格webcredentials関連ドメインはアプリと Web サイトを関連付け、あるプラットフォームでユーザーが作成したパスキーを別のプラットフォームで使用できます。これにより、従来のパスワード管理における「アプリのパスワード」と「Webサイトのパスワード」の分離の問題が解消されます。

  • 高セキュリティ シナリオ向けのハードウェア キー: 金融や医療などの高セキュリティ要件があるアプリケーション向けに、セキュリティ キー API が統合されています。 iOS 15 は、USB、NFC、および Lightning セキュリティ キーをサポートし、ユーザーにハードウェア レベルの保護を提供します。

関連セッション

コメント

GitHub Issues · utterances