まとめ

PassKeyの利点

• アカウントのセキュリティ向上
  -> 脆弱な認証情報や再利用される認証情報、認証情報の漏洩、フィッシングなど、セキュリティ問題の全カテゴリーを解決することが可能になる。
• サインインが簡単になり、ユーザー体験が向上する
  -> パスワードよりも優れたユーザー体験を実現できる。パスワードのない未来が楽しみ！
• オープンスタンダードに基づいて構築されているため、どんなデバイスからでもサインインすることができる
• AirDropを使ってアカウントを他の人と共有することができる
• 既存のアカウントにPasskeyを追加することができる
• 既存のサインインフローにそのままPasskeyでの認証を追加することができる
  -> 新しくサインイン画面をデザインする必要はなく、使い慣れた既存のサインインフローで使うことができる。
• 少ないコードで実装することができる

PassKey

https://developer.apple.com/videos/play/wwdc2022/10092/

PassKeyとは

次世代の認証技術。

まず、今日の認証技術であるPasswordについての説明。
ほぼ全てのアプリやウェブサイトでサインインに使われている

Passwordの困難な点

• 正しく使うのが難しい（？）-> 多くの人が強く、ユニークなパスワードを作ってくれていない。
• セキュリティと利便性がトレードオフの関係
• フィッシングやリユースが可能である

これらのPasswordの問題を解決するのがPasskeyです。

macOS VenturaとiOS16では誰でもPasskeyが作れるようになります。

PasskeyはPasswordに比べユーザー体験を向上させるのみならず、ほとんどのセキュリティ問題がなくなる。
セキュリティ問題

• 弱い
• (証明書の)リユース
• (証明書の)漏洩
• フィッシング

デモアプリでのPasswordを使った認証フロー

1. ユーザーネームテキストフィールドをタップし、自分のアカウントのAutoFillサジェスチョンが表示される。オートフィルを選択し、生体認証でサインインする。
   

2. パスワードテキストフィールドも上記と同じフローでサインインする。
   

3. SMSでワンタイムコードが届くまで待機。
   

4. ついにサインイン完了
   

デモアプリにPasskeyを追加する

1. システムシートでPasskeyを生成する
   

2. Continue を押して生体認証する
   

3. 完了！めっちゃ簡単にPasskeyを生成することができました
   

少しのステップで、私のデバイスはユニークで暗号として強いキーのペアを私のアカウントに生成し、自分のiCloudキーチェーン上に保存しました。なので、自分の全てのmacOS VenturaとiOS16のデバイスで同期されたPasskeyを使うことができます。

Passkeyでの認証フロー

1. ユーザーネームテキストフィールドをタップし、QuickTypeバー上に自分のアカウントのPasskeyが表示される。Passkeyをタップし、生体認証でサインインする。
   

2. サインイン完了！ワンステップ！
   

Passkeyを保存するときに、新しいパスワードや複雑な要求を満たす挑戦には出会しません。
それぞれのPasskeyはシステムによって生成され、強いことと、一つのアカウントのみで使われることを保証します。
さらに、Passkeyで認証する場合、サインインフローに表示され、シングルタップで利用することができる。
システムは正しいアプリやWebサイト上で自分だけPasskeyを使えるようにしているので、強いフィッシング対策が備わっている。

もちろん、パスキーはウェブ上でも動く。

SafariでのPasskeyでの認証フロー

1. ユーザーネームテキストフィールドを選択。iCloudキーチェーン上にPasskeyが保存されているのでPasskeyを使うことができる。
   

2. タッチIDで生体認証しサインイン完了！
   

PasskeyはOpen Standardsに基づいて構築されている。
(オープンスタンダードとは、様々なプラットフォーム上で利用可能であり、無償で利用できるもののこと)

クロスプラットフォームなのでWindowsPCなどからも利用可能！

WindowsPCなどからの認証フロー

1. ユーザーネームを入力し、サインインボタンを押下
   

2. スマホでのサインインを提供するシートが表示されるので選択する
   

3. QRコードが表示されるので、スマホのカメラでスキャンする
   
   

4. Passkeyでのサインインが認識される。このオプションを選択すると、自分のスマホとブラウザが安全に相互連携される。Continueボタンを押下し生体認証する。
   
   

5. サインイン完了！
   

クロスプラットフォームサインイン体験はPasskeyの背後にある標準の一部であり、最高級のシステム特徴。
表面上は驚くくらいシンプルに見えるけれど、ただのQRコードではない。
舞台裏では、デバイスたちはローカルキー合意を行い、近接を証明し(proving proximity)、端から端まで暗号化されたコミュニケーションチャネルを構築する。
サインインを簡単にできる上に、Passkeyにより強いフィッシング耐性を保つ。

Passkey利用時のインターフェイスガイドライン

• 第一に、PasskeyはPasswordの取り替え品
• Passkeyに言及する際のガイドライン
  • "passkey"は商標登録されていない、ユーザーから見える用語
  • "passkey"は"password"のような普通名詞。（つまり、小文字で、複数形になる）
  • AppleプラットフォームでのSFシンボルは以下２つがシステムで一貫したアイコンとして提供されている。
    
• passkeyを提供するのに全く新しいインターフェイスをデザインする必要はない。
  • 既存のユーザーネームフィールドがもう一つの大きな特徴を持つようになる。
  • AutoFillを使用したパスキーは、ファーストクラスの機能として提供され、既存のサインインフローにそのまま追加することができる。（AutoFillを使用したパスキーの提示は、パスキーの主要な使用方法）
    
    
    
  • より高度な使い方として、Appleのプラットフォームには、パスキーを使ったサインイン用の幅広い追加UIオプションがあります。
    

Passkeyの使用方法とAutoFillを使用したPasskeyの表示方法について

• Passkeys は WebAuthentication または WebAuthn 標準をベースに構築されており、公開鍵暗号方式を使用します。
• 入力可能な単語や文字列ではなく、一意の暗号キー ペアがアカウントごとに生成されます。
• パスキーによるサインインを行うには、サーバーのバックエンドに WebAuthn を採用する必要があります。 標準的な WebAuthn サーバーの実装であれば、パスキーに対応することができます。
• Apple プラットフォームのアプリでは、パスキーは AuthenticationServices フレームワークの ASAuthorization API ファミリーに含まれます。
  -> これは、パスワード、セキュリティ キー、Sign in with Apple など、あらゆる種類の認証情報を扱うための API です。
  -> また、AutoFillのサポートなど、使用できる新しいメソッドもいくつか追加され、このAPIをさらに柔軟にして、既存のサインインフローにシームレスに適合させることができるようになりました。

実装方法

• アプリのインターフェイスで、ユーザー名フィールドがユーザー名textContentTypeを使用していることを確認します。
  -> これにより、パスキーの候補を提供する場所がシステムに通知されます。
• この設定が完了したら、AutoFillによるパスキーリクエストを開始するために必要なコードを以下に示します。
• 他の WebAuthn リクエストと同様に、まずサーバーからチャレンジを取得する必要があります。
• 次に、プロバイダとリクエストを作成します。
• ASAuthorizationPlatformPublicKey CredentialProvider は、パスキー リクエストを扱うための ASAuthorizationProvider です
• WebAuthn の用語では、サインイン時にアサーションを使用するため、ここでは既存のパスキーでサインインするためのアサーションリクエストを作成しています。
• 実際にリクエストを処理するのは ASAuthorizationController です。
• パスキーリクエストでインスタンスを作成し、そのデリゲートとpresentationContextProviderを設定します。
• そして最後に、performAutoFillAssistedRequests を呼び出して、リクエストを開始します。
• このリクエストがアプリで実行されている間、ユーザー名フィールドがフォーカスされるたびに、システムは QuickType バーに利用可能なパスキーを提供します。
• キーボードが表示されたときにパスキーの準備ができるように、ユーザー名フィールドがフォーカスされる前に、ビューライフタイム内の早い段階でこのリクエストを開始するようにしてください。
• QuickType バーの項目が選択されると Face ID が呼び出され、ASAuthorizationController Delegate コールバックを受け取ってサインインを完了します。
• どの種類のクレデンシャルでも認証に成功すると、didCompleteWithAuthorizationコールバックを受け取ります。
• 最初にすべきことは、取得したクレデンシャルの種類を確認することです。パスキーによるサインインの場合、それは ASAuthorizationPlatformPublicKey CredentialAssertion となります。
• アサーション・オブジェクトには、バックエンドでサインインを検証するために必要なフィールドが含まれます。値を読み込んでサーバで検証し、サインインを完了させる必要があります。

AutoFill によるパスキーリクエストは強力です。
この小さなコード変更で、アプリのサインインフローは非常に柔軟になりました。
もちろん、主なケースは、QuickTypeバーからパスキーの候補を選択して、そのパスキーですばやくサインインすることです。

しかし、他の選択肢もあります。
先ほど紹介したコードでは、追加の変更なしに近くのデバイスからパスキーサインインすることも可能です。
鍵のアイコンをタップして、利用可能なすべてのパスキーとパスワードを一覧表示するビューを表示し、近くのデバイスでサインインするオプションにたどり着くことができます。
その後、クロスデバイスのパスキーサインインを実行できます。
どちらの場合も、パスキーが使われると、同じASAuthorizationController Delegateコールバックを受け取ります。
これをサポートするために必要な特別なことは何もありません。
もしユーザーがまだパスキーを持っていない場合は、ログインフォームをそのまま使用することができます。
QuickTypeバーにパスワードの候補が表示されますし、フィールドに入力することもできます。
パスワードの項目が選択された場合でも、クレデンシャルはテキストフィールドに入力され、実行中のリクエストをキャンセルすることができます。
このAPIは、既存のサインインフローにそのまま追加できるように設計されており、ユーザーにとって非常に使いやすいものとなっています。

既にパスキーの使用にアップグレードした人が、AutoFill の提案を使う代わりに、とにかくユーザ名を入力しようと決めた場合、AutoFill のリクエストをキャンセルして、ASAuthorizationController を使ってモーダルパスキーサインインシートを表示させる必要があります。
ここからはシングルタップで、同じ ASAuthorizationController Delegate のコールバックを受け取ることができます。

以下は、以前のコードです。
AutoFill リクエストからモーダルリクエストに切り替えるには、この performAutoFillAssistedRequests メソッドの呼び出しを performRequests() の呼び出しに置き換えるだけです。
これにより、利用可能なすべてのパスキーと、近くのデバイスからのパスキーを使用するオプションが表示されたモーダル シートが表示されます。
アプリでパスキーをサポートするために必要なコードの変更は、これだけです。
Web プラットフォームも、AutoFill アシストとモーダルパスキーの両方のリクエストをサポートしています。
Web では、セキュリティ キーにも使用される標準の WebAuthn API を介してパスキーが使用されます。
アプリと同様に、AutoFill アシスト リクエストを採用すると、Touch ID だけですばやくサインインしたり、利用可能なすべてのパスキーとパスワードを取得したり、近くのデバイスからパスキーを使用したりすることができ、これらはすべて非常に少ないコードで実行できます。

PassKeyが実際にどのように機能し、何がそれを安全にしているのかより技術的な詳細

今日、あなたがパスワードでサインインするとき、一般的に実際に起こっていることは、あなたがパスワードを入力した後、パスワードはハッシュ化され塩漬けされ、結果として難読化された値がサーバーに送られ、サーバーはそれを保存します。
その後、同じハッシュ化されたソルト値を生成できれば、そのアカウントへのアクセスが許可されます。
つまり、サーバーは、攻撃者にとって非常に価値のあるこのパスワードの導出を保存する責任があるのです。
もし、これを入手できれば、あなたのパスワードが何であるかを突き止め、アカウントにアクセスすることが可能になるのです。
しかし、パスキーの仕組みはまったく異なります。
パスキーは、入力可能な単一の文字列ではなく、実際には関連する2つのキーの組で構成されています。
これらのキーは、アカウントごとに、安全かつ一意にデバイスで生成されます。
1つは公開鍵で、サーバーに保存されます。
もう一方は秘密鍵で、サインインしている間もあなたのデバイスに残ります。
公開鍵は秘密ではありません。
あなたのユーザー名と同じように公開されています。
秘密鍵は、実際にサインインするために必要なものです。
秘密鍵はサーバーに知られることはなく、あなたのデバイスで安全に管理されます。
サインインしようとすると、サーバーはあなたのデバイスに一回限りのチャレンジを送ります。
WebAuthn ではさまざまなチャレンジ・レスポンス・アルゴリズムが使用できますが、Apple プラットフォームのパスキーは標準の ES256 を使用しています。
あなたの秘密鍵だけが、あなたのアカウントに対するチャレンジの有効な解を生成することができます。
あなたのデバイスは、署名と呼ばれるこの解をローカルに生成し、その解をサーバに送り返すだけです。
あなたの秘密鍵は、あなたのデバイスにのみ保存され、秘密にされます。
サーバーは、あなたの公開鍵を使って解決策を検証します。
あなたのデバイスが提供したソリューションが有効であれば、あなたはサインインしたことになります。公開鍵は、ソリューションが有効かどうかを確認するために使用できますが、ソリューションそのものを生成することはできません。
つまりサーバーは、秘密鍵が実際に何であるかを知らなくても、あなたが正しい秘密鍵を持っていることを確認することができるのです。
また、サーバーは秘密鍵を知らないので、漏えいするユーザー認証情報がなく、攻撃者のターゲットとして価値が低くなります。
この暗号と鍵の保護はすべて、完全に透過的であり、デバイスによって実行されます。
顧客はそれを知ることも考えることもありません。
顧客から見れば、パスキーは非常にシンプルで、どこでも使えるということです。
また、パスキーはフィッシングに強い安全な方法で、デバイス間のサインインに使用することができます。

その仕組みは次のとおりです。
ここには2つのデバイスがあります。
クライアントは、私がサインインするデバイスまたはウェブブラウザで、認証者は、私のパスキーを持っているデバイスである。
まず、クライアントがQRコードを表示し、それを認証側が読み取ります。
このQRコードには、1回しか使えない暗号鍵のペアをコード化したURLが含まれています。
次に、ネットワーク中継サーバーのルーティング情報を含むBluetoothアドバタイズを生成します。
このローカル交換により、サーバーの選択とルーティング情報の共有が可能になりますが、さらに2つの機能が追加されます。
サーバには見えない帯域外の鍵合意を行うため、ネットワーク上を流れるものはすべてエンドツーエンドで暗号化され、サーバは何も読むことができない。
また、2つのデバイスが物理的に近接していることを強く主張することができます。
つまり、電子メールで送信されたQRコードや偽のウェブサイトで生成されたQRコードは機能しません。遠隔地の攻撃者はBluetoothアドバタイズを受信してローカル交換を完了することができないためです。
つまり、これがローカルな部分です。
ローカル交換と鍵の合意が行われると、2つのデバイスは電話機が選んだリレーサーバーに接続します。
そこでは、標準的なFIDO CTAP操作が行われます。この操作は、先ほどの鍵を使って暗号化されているので、リレーサーバーには何が起こっているのかが見えません。
このプロセス全体は、デバイスとウェブブラウザによって実行されます。
ウェブサイトは、クロスデバイス通信のどの時点でも関与しません。
クロスデバイス・クロスプラットフォーム・サインインは、パスキーが使用できる場所であればどこでも機能するシステム機能です。
以上、パスキーの仕組みと、デバイスをまたいでも強力なセキュリティ保証が可能な理由について、より技術的に見てきました。

次は、多要素認証です。
現在、認証は「要素」で考えるのが一般的です。
異なる種類の攻撃に対して、異なる因子が強かったり弱かったり、因子を組み合わせることで、より優れた集団的なカバーが可能になります。
しかし、パスキーを使えば、もうそのような考え方は必要ありません。
今日、サインインに最もよく使われる方法を紹介します。
頭の中にあるパスワードは、かなり脆弱です。
パスワード管理ソフトは、ユニークなハイエントロピーの文字列を生成するのに優れており、デバイスの盗難に対するローカルな保護機能を持ち、フィッシングに関するいくつかのヒントを提供しています。
SMSやタイムベースのコードを追加することで、盗難やフィッシングに対処できる場合もありますが、本当の解決にはなりません。
しかし、パスキーは、デバイスが生成するユニークなキーペアです。
Appleのデバイスでは、パスキーはローカルデバイスの保護という強力な基盤の上に構築されています。
また、パスキーはフィッシングの人的要因も完全に排除します。
また、アプリやウェブサイトのサーバーは秘密鍵を持っていないため、漏洩することはありません。
パスワードベースのサインインフローに要素を追加することは、パスワードだけよりも多くの種類の攻撃から保護することができるため、理にかなっています。
しかし、パスキーだけでも多くの攻撃から守ることができるので、追加の要素は必要ないのです。
パスワードのない未来が楽しみです。

ここでは、それを実現するための方法を紹介します。
まず最初に、WebAuthn をサーバに導入する必要があります（まだ導入していない場合）。
Passkeys は、標準的な WebAuthn サーバの実装であれば動作するはずです。
サーバーの準備ができたら、あなたのアプリケーションやウェブサイトで新しい API を採用してください。
AutoFill によるパスキー リクエストは、既存のサインイン フローに組み込むことができます。また、必要に応じて、より高度な UI オプションも用意しています。
そして最後に、ユーザーをパスワードから解放してください。
パスキーは、アプリケーションやウェブサイトに安全にサインインするための、利便性とセキュリティの問題を解決する業界標準のソリューションです。
顧客をパスワードからパスキーに誘導することで、信じられないほど迅速で便利なサインイン体験を提供しながら、すべての人のセキュリティレベルを引き上げることができます。