2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

パスキー認証について調べてみた。

Last updated at Posted at 2024-06-30

パスキー認証について、社内で勉強会を行いました。
その際に、パスキー認証について調べてみた結果をこちらでもアウトプットしてみます。

認識に誤りがありましたら、ご指摘いただきたいです。

目次

1. パスキー認証とは

パスキー認証は、FIDO(ファイド)アライアンスとW3Cが共同で規格化したものですが、正確に、"パスキー認証とは何か"は定義されておらず、調べていくと、意味としては2種類あるようです。
なので、今回はこの2種類について調べてみました。

1つ目は、FIDO2認証やWebAuthnなど、パスワードレスな認証技術のこと。
2つ目は、秘密鍵のデバイス間での共有(= マルチデバイスFIDOクレデンシャル」)のこと

を指すようです。

今回は、1つ目を広義のパスキー。2つ目を狭義のパスキーとして記載しています。

2. 公開鍵暗号方式(復習)

前提として、パスキー認証は公開鍵暗号方式をもとに実行します。

ここでは復習として記載しています。詳細は下記サイトで詳しく記載されていますので、こちらをご確認ください。

3. 広義のパスキー

上で記載した通り、広義のパスキーとして記載するパスワードレスな認証技術は、"FIDO2"と"WebAuthn"という技術のことを指しています。

FIDO2

FIDO2とは、生体情報も含めた認証を行い、「公開鍵暗号方式」を用いてサーバと端末間で通信を行うパスワードレス認証のことを指します。
メリットは、下記が挙げられます。

  1. セキュリティ面で安全性が担保されている
  2. 利便性が高い

「1.」は認証に必要な生体情報をサーバ側で保有せず、利用者側で保持するため、サービスを実施するサーバに対して攻撃が行われた際に、利用者情報が外部へ流出しない点です。

また、「2.」のメリットとも被る点はありますが、利用者側でパスワードの設定が不要であることから、セキュリティが脆弱なパスワードを設定する可能性がなく、パスワードの使い回しなども発生しないため、安全性が担保されているといえます。

「2.」では、端末に生体情報を登録するだけであるため、利用者がパスワードを覚えておく必要がありません。そのため、パスワードを用いた認証に比べ、利用者の負担が少なくなります。

デメリットとしては、下記が挙げられます。

  1. 端末の買い替えや紛失時の認証手段がなくなる
  2. 未対応のWebサービスがまだまだ多い

「1.」は、端末へ生体情報を登録するため、端末の変更が発生した際の認証手段がなくなる点です。

「2.」については、GoogleやApple、メルカリやドコモ(dアカウント)など、大手企業を中心にパスキー認証を導入する企業が近年増えてきていますが、世の中を見るとまだまだパスキー以外の認証手段が主流である点です。

FIDO2の2つの仕様

FIDO2についてメリットとデメリットを記載しましたが、そもそも、FIDO2は2つの仕様から成り立ちます。

  1. WebAuthn(認証サーバとブラウザ間の動作を規定した仕様)
  2. CATP(ブラウザと認証器間の通信を規定した仕様)

上記2つの仕様について、下記に記載します。

WebAuthn

WebAuthnとは、WebサイトがFIDOベースの認証システムでログインできるようにするためのプロトコル仕様です。

これまで、FIDO認証の技術はネイティブアプリ用の規格しか用意されていませんでしたが、WebAuthnはWebアプリ用の標準規格のため、ブラウザ上での実行が可能となりました。

WebAuthnには、①登録 と、②認証 の2ステップが存在します。
この2ステップの実行フローについて以下に記載します。

①登録

(数字は画像内の数字と同様)

  1. ユーザは認証サーバにリクエストを送信し、ユーザ登録を要求
  2. 認証サーバはチャレンジと呼ばれるランダムな文字列を生成
  3. 認証サーバは、認証サーバの情報とチャレンジを含むレスポンスをブラウザに対して返却
  4. ブラウザは、[3.]で受け通った情報を認証器(デバイス)に送信し、本人確認をリクエスト
    ※生体認証を実施し、問題ない場合は[5.]を実施
  5. 認証器(デバイス)は、ユーザの秘密鍵と公開鍵のペアを生成し、端末内に保存
  6. 端末にてユーザIDを裁判し、ユーザIDと[4.]で受けとったサーバ情報を紐づけて端末内に保存
  7. Attestationと呼ばれるオブジェクトを生成
    ※Attestationは以下を含み、[5.]にて生成した秘密鍵で暗号化(署名)したものを指す。
    ・認証器の情報
    ・ユーザの公開鍵
    ・認証サーバの情報
    ・チャレンジ
  8. 認証器は[7.]で作成したAttestationオブジェクトと[6.]で採番したユーザID、[5.]で生成した公開鍵をブラウザに返却
  9. ブラウザは、受け取った情報をサーバに送信
  10. サーバは受け取った情報を公開鍵を用いて復号化を行い、情報の署名検証を行う
    ※サーバが[2.]で送信したチャレンジと、[9.]でブラウザから送信されたAttestationオブジェクト内のチャレンジが同一であるか、比較を行う。
    一致した場合、登録リクエストを送信している対象が本人であることを確認できる(= 本人認証が完了する)。
  11. [10.]で本人認証が完了した場合、ユーザIDとユーザの公開鍵、認証器の情報をDBへ保存
  12. 登録完了のレスポンスをブラウザへ返却

image.png
参照:https://www.nri-digital.jp/tech/20230124-12533/

②認証

(数字は画像内の数字と同様)

  1. ユーザは認証サーバにリクエストを送信し、ユーザ認証を要求
  2. 認証サーバはチャレンジと呼ばれるランダムな文字列を生成
  3. 認証サーバは、認証サーバの情報とチャレンジを含むレスポンスをブラウザに対して返却
  4. ブラウザは、[3.]で受け取った情報を認証器(デバイス)に送信し、本人確認をリクエスト
  5. 認証サーバの情報から、登録済のユーザ一覧を表示
  6. ユーザ一覧から、ログインを行うユーザを選択
  7. 認証器(デバイス)にて、生体認証を実施
  8. 認証成功後、端末内のユーザIDをもとに、端末内に保存されている秘密鍵を取得
  9. Assertionと呼ばれるオブジェクトを生成
    ※ Assertionは以下を含み、[8.]にて取得した秘密鍵で暗号化(署名)したものを指す。
    ・認証サーバの情報
    ・チャレンジ
  10. 認証器(デバイス)は、[9.]で作成したAssertionオブジェクトと⑥で選択したユーザ情報をブラウザに返却
  11. ブラウザは、受け取った情報をサーバに送信
  12. 認証サーバは受け取ったユーザ情報から、認証サーバ内に保存されている公開鍵を取得
  13. [12.]にて取得した公開鍵で復号化を行い、情報の署名検証を行う
    ・サーバが[2.]で送信したチャレンジと、[11.]でブラウザから送られてきたAssertionオブジェクト内のチャレンジが同一であるか比較を行う。
    ・一致した場合、認証リクエストを送信している対象が本人であることを確認できる(=本人認証が完了する)。
  14. 認証完了のレスポンスをブラウザへ返却
    image.png
    参照:https://www.nri-digital.jp/tech/20230124-12533/

CTAP

CTAP(シータップ)とは、FIDO2に対応したデバイスが、BluetoothやUSBなどを通じて、外部の生体認証端末(認証器)とデータのやり取りをする際に、両者を媒介するプロトコル仕様のことを指します。

FIDO2まとめ

今回記載したことを踏まえると、FIDO2では、

・WebAuthnによってブラウザを介したWebサービスとのやり取りが可能となり
・CTAPによって一般的な環境(モバイル端末・デスクトップ端末)でも外部の認証器を使用したパスワードレス認証が実現した。

といえます。

4. 狭義のパスキー

これまで記載してきたFIDO2では、デメリットとして、以下が挙げられていました。

  1. 端末の買い替えや紛失時の認証手段がなくなる
  2. 未対応のWebサービスがまだまだ多い

この中で、「1.」を解決するFIDO認証が、狭義のパスキーとして今回記載する 秘密鍵のデバイス間での共有(マルチデバイスFIDOクレデンシャル)です。

これまでの公開鍵暗号方式では秘密鍵はスマホやPC(=端末)に保存されていましたが、秘密鍵のデバイス間での共有によって、ユーザのプラットフォームアカウントに紐づけてクラウド上で秘密鍵を同期(※)することが可能となりました。

つまり、同じアカウントへのログインにおいて、複数の異なるデバイスで、FIDO認証を用いたログインが可能となりました。

※Appleの場合、デバイス内のiCloudキーチェーンにより、エンドツーエンドで暗号化されたのちに同期されます。
https://developer.apple.com/jp/passkeys/

5. パスキー認証とパスワード認証

ここまで、パスキー認証について振り返ってきました。
パスキー認証について、安全性が担保されていること。また、秘密鍵の共有により、端末を交換した際の不便さも解消されつつあることから、現在主流であるパスワード認証が今後なくなっていく可能性も感じることができます。

では、パスキー認証があれば、現在認証手段として主流であるパスワード認証は今後不要になるか。と言われると、そう簡単に「はい、そうです。」とは言えないようです。

これは、パスキーを間違えて削除したしまった場合において、アカウントリカバリー手段のベストプラクティスがまだ確立されていないことが要因としてあるそうです。このため、パスワード認証もとい、パスキー認証以外の認証手段は今後も必要となってきます。(パスキー認証以外の認証方法でのアカウントリカバリーの手段が必要)
参照:https://youtu.be/lRBG-t9UDGo?si=jnr3UVRs3hSqTlmV

6. まとめ

パスキー認証とは何か。まとめると、冒頭で述べたように下記2点であるといえます。
・ 生体情報も含めて認証を行い、「公開鍵暗号方式」を用いてサーバと端末間で通信を行うパスワードレス認証
・秘密鍵のデバイス間での共有

以上です。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?