ゼファーネットのロゴ

生成的データ インテリジェンス

Code

Passkeys: 一体、なぜ?

プラトン再発行
プラトン再発行

日付：

閲覧数： 436

と呼ばれるこれらのこと パスキー 最近は確かにラウンドを行っています。 彼らはでの主なアトラクションでした W3C TPAC 2022、支持を得た サファリ16、彼らの道を見つけています macOSとiOS、予定されている 1Password のようなパスワード マネージャーの未来。 彼らです すでにサポートされています Android に搭載されており、今後のリリースで Chrome OS と Windows にもすぐに採用される予定です。

Geeky OS のセキュリティ強化は、フロントエンド コミュニティで大きく取り上げられることはありませんが、パスキーが「モノ」になるのは当然のことです。 また、パスワードとパスワード アプリが認証やフォーム処理などのユーザー エクスペリエンスにどのように影響するかを考えると、今後何が起こるかを知るために、少なくともそれらについて頭を悩ませたいと思うかもしれません.

それがこの記事のポイントです。 私は、パスキー (およびその上に構築されている WebAuthn API) を研究し、実験してきました。 私が学んだことを共有しましょう。

目次

用語

ここでは、掘り下げる際に知っておく必要のある用語のセクションを示します。ほとんどの技術と同様に、パスキーは難解な言葉遣いや頭字語で作成されており、理解の障害となることがよくあります。 ここでいくつかの謎を解こうと思います。

  • 依存パーティ： 認証するサーバー。 この記事では、証明書利用者を意味するために「サーバー」を使用します。
  • クライアント： この場合、Web ブラウザまたはオペレーティング システムです。
  • オーセンティケーター： 公開鍵ペアの生成と保存を可能にするソフトウェアおよび/またはハードウェア デバイス。
  • フィドー: FIDO クレデンシャルに関する仕様も作成するオープン標準化団体。
  • Web認証: パスキーの基礎となるプロトコル。 FIDO2 資格情報または単一デバイスの FIDO 資格情報。
  • パスキー: WebAuthn、ただしクラウド同期あり (マルチデバイス FIDO 資格情報、検出可能な資格情報、または常駐資格情報とも呼ばれます)。
  • 公開鍵暗号化: 秘密鍵と公開鍵を含む、生成された鍵のペア。 アルゴリズムに応じて、署名と検証、または暗号化と復号化に使用する必要があります。 これは次のようにも知られています。 非対称暗号.
  • RSA： クリエイターの名前、Rivest Shamir と Adel の頭字語。 RSA は素因数分解に基づく古い公開鍵暗号方式ですが、依然として有用です。
  • 楕円曲線暗号（ECC）： 新しい暗号化ファミリー 楕円曲線に基づく.
  • ES256： ECDSA 署名アルゴリズムを使用する楕円曲線公開鍵 (PDF）と SHA256 ハッシュ用。
  • RS256： ES256 と同様ですが、RSA を使用します。 RSASSA-PKCS1-v1.5 およびSHA256。

パスキーとは何ですか?

パスキーについて具体的に説明する前に、パスキーと呼ばれる別のプロトコルについて説明する必要があります。 Web認証 (FIDO2 とも呼ばれます)。 パスキーは、WebAuthn の上に構築された仕様です。 WebAuthn では、公開鍵暗号を使用してパスワードを置き換えることができます。 ハードウェアキーや トラステッド・プラットフォーム・モジュール (TPM)、秘密鍵と公開鍵を作成します。

公開鍵は、誰でも使用できます。 ただし、秘密鍵は、それを生成したデバイスから削除することはできません。 これは WebAuthn の問題の XNUMX つでした。 デバイスを紛失すると、アクセスできなくなります。

Passkeys は、資格情報のクラウド同期を提供することでこれを解決します。 つまり、コンピューターで生成したものを携帯電話でも使用できるようになりました (紛らわしいことに、単一デバイスの資格情報もあります)。

現在、執筆時点では、iOS、macOS、および Android のみがクラウド同期パスキーを完全にサポートしており、使用されているブラウザーによって制限されています。 Google と Apple は、それぞれの Googleパスワードマネージャー & AppleiCloudキーチェーン サービス、それぞれ。

パスキーはどのようにパスワードを置き換えますか?

公開鍵暗号化では、として知られていることを実行できます。 署名. 署名はデータの一部を取得し、秘密鍵を使用して署名アルゴリズムを実行し、公開鍵で検証できます。

誰でも公開鍵のペアを生成できます。また、そもそも誰でも生成できた可能性があるため、誰のせいでもありません。 便利なのは、秘密鍵で署名されたデータのみを公開鍵で検証できることです。 これは、パスワードを置き換える部分です。サーバーは公開鍵を保存し、残りの半分 (秘密鍵など) を持っていることを確認し、ランダム チャレンジに署名してサインインします。

追加の利点として、ユーザーの公開鍵をデータベース内に保存しているため、何百万ものユーザーに影響を与えるパスワード侵害の心配がなくなりました。 これにより、パスワードに依存する世界が現在直面しているフィッシング、侵害、およびその他の多数のセキュリティ問題が減少します。 データベースが侵害された場合、そのすべてがユーザーの公開鍵に保存されるため、攻撃者にとって事実上役に立たなくなります。

メールとそれに関連付けられたパスワードを忘れることもありません。 ブラウザーは、どの Web サイトでどの資格情報を使用したかを記憶します。数回クリックするだけでログインできます。生体認証や PIN など、パスキーを使用するための XNUMX 番目の確認手段を提供できます。 、しかし、それらは依然として昨年のパスワードよりもはるかに高速です.

暗号化の詳細

公開鍵暗号化には、秘密鍵と公開鍵 (鍵ペアと呼ばれる) が含まれます。 キーは一緒に生成され、個別に使用されます。 たとえば、秘密鍵は秘密に保つことを目的としており、公開鍵はメッセージを交換する相手を対象としています。

メッセージの暗号化と復号化に関しては、受信者の公開鍵を使用してメッセージを暗号化し、受信者の秘密鍵だけがメッセージを復号化できるようにします。 セキュリティ用語では、これを「機密性の提供」と呼びます。 ただし、誰でも公開鍵を使用して暗号化されたメッセージを送信できる可能性があるため、送信者が本人であることを証明するものではありません。

メッセージが実際に送信者からのものであることを確認する必要がある場合があります。 このような場合、署名と署名の検証を使用して、送信者が本人であることを確認します (別名 信頼性）。 公開鍵 (とも呼ばれます) 非対称の) 暗号化、これは通常、メッセージのハッシュに署名することによって行われるため、公開鍵だけがそれを正しく検証できます。 ハッシュと送信者の秘密鍵は、アルゴリズムを実行した後に署名を生成し、送信者の公開鍵を使用して、誰でもメッセージが送信者からのものであることを確認できます。

パスキーにアクセスするにはどうすればよいですか?

パスキーにアクセスするには、まずパスキーを生成してどこかに保存する必要があります。 この機能の一部は、オーセンティケーターで提供できます。 アン オーセンティケータ 暗号化キーを生成する機能を提供する、ハードウェアまたはソフトウェアに基づくデバイスです。 取得したワンタイム パスワードについて考えてみてください。  , 1Passwordまたは のLastPassなどがある。

たとえば、ソフトウェア オーセンティケーターは、Trusted Platform Module (TPM) またはデバイスのセキュア エンクレーブを使用して資格情報を作成できます。 その後、認証情報をリモートで保存し、パスキーなどのデバイス間で同期できます。 ハードウェア認証システムは、 YubiKey、デバイス自体でキーを生成して保存できます。

オーセンティケーターにアクセスするには、ブラウザーがハードウェアにアクセスできる必要があり、そのためにはインターフェイスが必要です。 ここで使用するインターフェイスは、Client to Authenticator Protocol (CTAP) です。 これにより、さまざまなメカニズムを介してさまざまなオーセンティケーターにアクセスできます。 たとえば、CTAP を利用することで、NFC、USB、および Bluetooth を介してオーセンティケーターにアクセスできます。

パスキーを使用する興味深い方法の XNUMX つは、携帯電話を Bluetooth 経由で、パスキーをサポートしていない別のデバイスに接続することです。 デバイスが Bluetooth 経由でペアリングされると、電話を介してコンピューターのブラウザーにログインできます。

パスキーと WebAuthn の違い

パスキーと WebAuthn キーはいくつかの点で異なります。 まず、パスキーはマルチデバイスの資格情報と見なされ、デバイス間で同期できます。 対照的に、WebAuthn キーは単一デバイスの資格情報です。これは、検証のために XNUMX つのデバイスにバインドされていることを示す派手な方法です。

次に、サーバーに対して認証するには、WebAuthn キーがログイン用のユーザー ハンドルを提供する必要があります。 allowCredentials リストがサーバーからクライアントに返され、ログインに使用できる資格情報が通知されます。 パスキーはこの手順を省略し、サーバーのドメイン名を使用して、そのサイトに既にバインドされているキーを表示します。 システムですでに認識されているため、そのサーバーに関連付けられているパスキーを選択できます。

それ以外の場合、鍵は暗号的に同じです。 保存方法と、ログイン プロセスを開始するために使用する情報のみが異なります。

プロセス…一言で言えば

WebAuthn またはパスキーを生成するプロセスは非常に似ています。サーバーからチャレンジを取得してから、 navigator.credentials.create 公開鍵ペアを生成する Web API。 次に、チャレンジと公開鍵をサーバーに送り返して保存します。

公開鍵とチャレンジを受信すると、サーバーはチャレンジとそれが作成されたセッションを検証します。 それがチェックアウトされると、公開鍵と、ユーザー識別子や認証データなどのその他の関連情報がデータベースに保存されます。

ユーザーにはもう XNUMX つのステップがあります。サーバーから別のチャレンジを取得し、 navigator.credentials.get チャレンジに署名するための API。 署名済みのチャレンジをサーバーに送り返すと、サーバーはチャレンジを検証し、署名が成功した場合はログインします。

もちろん、各ステップにはさらに多くの作業があります。 しかし、これは一般的に、WebAuthn またはパスキーを使用して Web サイトにログインする方法です。

肉とじゃがいも

パスキーは XNUMX つの異なるフェーズで使用されます。 証明 & アサーション フェーズ。

アテステーション フェーズは、登録フェーズと見なすこともできます。 新しい Web サイトの場合はメール アドレスとパスワードでサインアップしますが、この場合はパスキーを使用します。

アサーション フェーズは、サインアップ後に Web サイトにログインする方法に似ています。

証明

フルサイズを表示

　 navigator.credentials.create API は、認証フェーズの焦点です。 システムに新しいユーザーとして登録されており、新しい公開鍵ペアを生成する必要があります。 ただし、生成するキー ペアの種類を指定する必要があります。 つまり、オプションを提供する必要があります navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};
const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

私たちは得るでしょう PublicKeyCredential が含まれています AuthenticatorAttestationResponse 作成後に戻ってきます。 クレデンシャルには、生成されたキー ペアの ID が含まれています。

応答は、いくつかの有用な情報を提供します。 まず、この応答に公開鍵が含まれているので、それをサーバーに送信して保存する必要があります。 第二に、私たちはまた戻ってきます clientDataJSON プロパティをデコードして、そこから type, challenge, origin パスキーの。

証明のために、私たちは検証したい type, challenge, origin サーバー上に公開鍵を格納し、その識別子 (例: kid. オプションで保存することもできます attestationObject 私たちが望むなら。 保存する別の便利なプロパティは、 コーセー 上記で定義されているアルゴリズム  PublicKeyCredentialCreationOptions 　 alg: -7 or alg: -256、アサーション フェーズで署名されたチャレンジを簡単に検証するため。

アサーション

フルサイズを表示

　 navigator.credentials.get API はアサーション フェーズの焦点になります。 概念的には、サインアップ後にユーザーが Web アプリケーションにログインする場所です。

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};
const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

再び取得します PublicKeyCredential ととも​​に AuthenticatorAssertionResponse この時。 資格情報には、キー識別子が含まれています。

また、 type, challenge, origin   clientDataJSON 再び。 ザ・ signature が応答に含まれるようになりました。 authenticatorData. それらと clientDataJSON これが秘密鍵で署名されていることを確認します。

　 authenticatorData 追跡する価値のあるいくつかのプロパティが含まれています 最初は、最初の 256 バイト内にある、使用しているオリジンの SHA32 ハッシュです。これは、リクエストが同じオリジン サーバーからのものであることを確認するのに役立ちます。 第二は、 signCount、これはバイト 33 から 37 までです。これはオーセンティケータから生成され、以前の値と比較して、キーに怪しいものが含まれていないことを確認する必要があります。 マルチデバイス パスキーの場合、この値は常に 0 である必要があり、シングル デバイス パスキーの場合は、以前の signCount よりもランダムに大きくなる必要があります。

ログインをアサートしたら、ログインする必要があります — おめでとうございます! パスキーは非常に優れたプロトコルですが、いくつかの注意点があります。

いくつかの欠点

パスキーには多くの利点がありますが、この記事の執筆時点ではいくつかの問題があります。 XNUMX つには、パスキーのサポートに関してはまだ初期段階であり、Windows では単一デバイスの資格情報のみが許可され、Linux システムではほとんどサポートされていません。 パスキー.dev 提供 このプロトコルの Caniuse のような素敵なテーブル.

また、Google と Apple のパスキー プラットフォームは相互に通信しません。 Android フォンから iPhone に資格情報を取得したい場合は…まあ、今のところ運が悪いです。 相互運用性がないというわけではありません。 電話を認証システムとして使用して、コンピュータにログインできます。 しかし、オペレーティング システムに組み込み、ベンダー レベルでロックせずに同期するだけで、はるかにクリーンになります。

物事はどこに向かっていますか？

未来のパスキー プロトコルはどのようなものですか? かなり良さそうです！ より多くのオペレーティング システムからサポートが得られるようになれば、使用量も増えるはずです。 いくつかの パスワードマネージャ 直接サポートすることさえあります。

パスキーは Web でのみサポートされているわけではありません。 Android & iOS どちらもファースト クラス シチズンとしてネイティブ パスキーをサポートします。 私たちはまだこれらすべての初期段階にいますが、ますます言及されることを期待しています.

結局のところ、私たちはパスワードの必要性を排除し、そうすることで世界をより安全にします!

リソース

パスキーについて詳しく知りたい場合は、次のリソースを参照してください。 この記事のためにまとめたリポジトリとデモもあります。

スポット画像

最新のインテリジェンス

スポット画像

著作権 @ 2024 Plato Technologies Inc.