2024 年 6 月 14 日、Google 渋谷オフィスにて Chrome Tech Talk Night #16 〜パスキーが開催されました。 CTTN #16 は、開発者のみなさんがパスキーの基本について学び、よくある疑問を解決できることを目指したイベントです。 FIDO Alliance メンバー企業でアクティブに仕様策定に参加しているエキスパートの皆様がご登壇されました。

資料はこちらに公開されています：Chrome Tech Talk Night #16 パスキー

以下はClaude Sonnet 3.5 によるまとめとNotta.ai によるまとめをもとに若干手を入れたものです。なお、私はこの分野は素人なので、間違いがあると思うので、その場合はご指摘いただければ幸いです。

Table of Contents

Chromeテックトーク16 – パスキーについて #passkeys_jp

1. イントロダクション

イベント名: Chromeテックトーク16
主題: パスキー
話者:
- Google デベロッパーアドボケート: えーじ氏 (@agektmr)
- NRIセキュアテクノロジーズ株式会社: 古川英明氏 (@hdfrk)
- メルカリ: kokukuma氏 (@kokukuma)
- メルカリ: 大井孝太郎氏（プロダクトマネージャー）(@koiPM4)

2. メルカリにおけるパスキー導入事例 (大井氏)

2023年3月: メルコイン（暗号資産交換業）開始時にFIDOを導入
導入理由: フィッシングリスクの軽減
導入過程:
1. 2023年3月: アプリでのFIDO導入（デバイスバウンドパスキーのみ）
2. 2023年4月: シンクドパスキー対応
3. 2024年2月: アプリでのログインにパスキー対応
現状（2024年5月時点）:
- パスキー利用者数: 約400万人
- 認証成功までの平均時間: 4.4秒（SMS OTPの17秒と比較して13秒短縮）
- 認証成功率: 82.5%（SMS OTPの67.7%と比較して約15%向上）
- 認証数はSMS認証をすでに超えている（数字は非公開）¹
- メルコインにおけるフィッシング被害: 0件
課題:
1. さらなるフィッシング対策強化
2. 利用者数の拡大
3. サービス利用中の認証体験の最適化
おまけ
- 動かして学びたい人向けリンク
  - Webauthn.io
    パスキーの登録と認証を試せるデモサイト
  - ウェブアプリでフォームの自動入力を使用してパスキーを実装する
    とりあえずこれやれば、パスキーだいたいわかる
  - 読んで学びたい人向け
    - passkeys.dev
      Device Supportの部分何度も見ちゃう。
      実装もちょっと載ってる。
    - Web+DB vol 136 実戦投入パスキーいまこそ実現，パスワードレス認証！
      いいまとめ。
    - パスキーによるパスワードなしのログイン
      Googleさん公式のガイド。動画や図で分かりやすい
    - Supporting passkeys
      Appleさん公式のデベロッパー向けのAPI Document
  - じっくり読んで学びたい人向け
    - Web Authentication: An API for accessing Public Key Credentials
      WebAuthNの仕様
    - FIDO Alliance Design Guidelines
      パスキーのデザインガイドライン
    - Synced Passkey Deployment: Emerging Practices for Consumer Use Cases
      Consumer向けパスキーデプロイ時の考慮事項

3. パスキーの登録について (kokukuma氏)

パスキー登録には、同じデバイス上で登録する方法と、別のデバイスで登録する方法の2つがあります。同じデバイスの場合は生体認証などを経てデバイス上でパスキーが作成されます。別のデバイスの場合は、QRコードを読み取ることで認証を行い、そのデバイス上でパスキーが作成されます。登録時に必要となるパラメータ(チャレンジ、RPIDなど)の役割や、APIコールの流れが説明されました。

ユーザー体験

ユーザー体験には同じデバイス上での登録と別のデバイス上での登録の２種類ある。
同じデバイス上だと、登録しようとすると生体情報などが要求されて登録する形。
別デバイス上だと、モバイルデバイスでQRコードを読んで生体認証をして登録を行う形になる。
Webauthn.io をみるとよくわかる。

登録プロセス

サーバーがチャレンジを生成 (PublicKeyCredentialCreationOptions)
ブラウザがオーセンティケーターにデータ(rp.Id,User info, RP info, clientDatahash)を渡す
オーセンティケーターでユーザー検証、パスキー生成
生成されたデータをブラウザに送信
ブラウザがそのデータをサーバーに返送
サーバーで検証と保存

重要パラメーター

AuthenticatorAttachmentとhint
- 使える認証器の種類(例: platform, cross-platform)を指定する
- 組み合わせで表示したくないもの（例：コンシューマコンテキストでのsecurity keyなど）を指定することもできる。
- authenticatorSelection.AuthenticatorAttachment: RPは、navigator.credentials.create() を呼び出してパスキーを作成するときに、これを使用して、登録を許可する認証機のタイプを指定。
  - e.g., “platform”, “cross-platform”
- Hints (near future): RPは、この列挙を使用して、リクエストを最も適切に完了する方法に関するヒントをユーザーエージェントに伝えることができます。
  - e.g., “security-key”, “client-device”, “hybrid”
- どういう指定をするかは、RPのパスキー導入目的による
challengeとrp.id
- phishing耐性のある認証を成り立たせる為の必須パラメータ
- rp.idとそのsubdomainの範囲が、同じパスキーを利用できる範囲になる
- Safari ではWWDC2024で発表されたようにRelated Domains が使えるようになってこの制限が弱まっている。
- challenge: パスキー登録をスタートさせたセッションと紐づく、サーバで作成されたランダムな値を指定。パスキー登録時に検証される。
- rp.id: ユーザの登録や認証を行う有効なドメイン名を指定する。登録されたパスキーは、登録されたrp.idに紐づくRPでの認証でのみ利用できる。
user.id と excludeCredentials
- プロバイダーごとにパスキーを1つだけ作るために使用
- user.id: RP内でユーザを一意に識別する値です。ユーザがログインに使う識別子とは異なり、ユーザの個人情報を含まないものにします。
- excludeCredentials: 同じデバイスによる多重登録を防ぐために、登録済みのパスキーの識別子をすべて渡します。個々に指定されたパスキーが既に存在する場合、認証器はエラーを返します
user.displayname と user.name
- 認証時のアカウント選択時に表示したいものを指定
- user.name: ユーザーアカウントのわかりやすい識別子です。表示のみを目的としています。
- user.displayName: ユーザーアカウントのわかりやすい名前で、表示のみを目的としています。RPは、ユーザーがこの名前を選択できるようにする必要があります
- Conditional UIとかで表示される値なので、ユーザが見て判別できる値を入れる。
- 変更され得ない、アカウントに一意な情報がベスト。
- displayName と nameはまぁ、同じ値でいいだろう…
residentKey / userVerification / attestation
- authenticatorSelection.residentKey: Discoverable Credentialsにするかどうかを指定。
- authenticatorSelection.userVerification: ローカル認証(生体認証、PIN入力など)の必要性を指定。
- attestation: パスキー生成時の証明伝達に関する設定を指定できます。

Client側の実装雰囲気

credentials.createの結果がcredに入ってきて、それをBase64URLエンコードするなど色々して、credential.responseにセットする形。

Server側の実装雰囲気

SimpleWebAuthn を使った例。verifyRegistrationResponseの中身は長すぎるので、別途コードを参照のこと。

たくさん検証パラメータはあるが、中でも重要なのを２つ紹介

CollectedClientData
認証リクエストに関する情報

type: webauthn.create
challenge: 認証器に渡したチャレンジが返ってくる。
origin: ブラウザから認証器に渡されたオリジンの文字

検証

type が、 webauthn.create
challengeが、サーバ側に保存してある値と一致していること
originが、許可したいoriginであることを確認

この検証により、先ほどのrp.Idと組み合わせてフィッシング耐性を獲得している。

attestationObject

authenticator data: 利用された認証器に関する情報
Flags: 認証器の状態や認証の種類を示すフラグ。検証はUPが設定されていることを確認、RPの要求に応じてUVが設定されていることも確認。
attestation statement: 公開キー資格情報自体とそれを作成した認証者に関するステートメントを含む、特定の種類の署名済みデータオブジェクト。証明機関のキーを使用して作成された証明署名が含まれる。検証にはattStmt, authenticatorData, clientDataHashを受け取り、attestation statementが有効かどうかを判定する。synced passkeyの場合、attestation statementはついてこない。

サーバ側に保存しておくもの

Attested Credential Data
- Credential ID: excludeCredentialで指定したり色々。
- Credential Public Key: 認証時assertionの検証に使うため
- AAGUID: passkey providerを判別するため
Flags
- BE: synced passkeyかどうかを判別するため
- UP/UV: 登録時にローカル認証してるかどうか。

注意点

エクステンションの多くはブラウザやOSに完全に実装されているわけではない
コンディショナルクリエーション: ユーザーのインタラクションなしでパスキーを作成可能

4. パスキーの認証フロー超概観 (古川氏)

パスキー認証では、サーバーからチャレンジなどのパラメータを受け取り、デバイス上でパスキーを用いてそれらに署名を行います。その署名がサーバーに送られ、サーバー側で公開鍵を使って検証されます。この一連の流れが、ブラウザ、JavaScriptアプリ、認証デバイスを含む各コンポーネント間でどのようにデータが行き来するかが詳細に説明されました。また、パスキーの鍵自体はサーバーに送られないことや、生体情報もサーバーに共有されないことが強調されました。

主なパスキーの呼び出し方法

コンディショナルUI
- inputないしtextareaフォーム内での、autocompleteの属性としてwebauthnの値を設定する
- ブラウザ側でConditional UIが利用可能かを判定
- Conditional UIが利用可能な場合にConditional UIを発動
- ユーザー操作中断時のエラー表示も準備
パスキーでログインボタン
- ボタンを押下することでパスキーのスクリプトが発動するようにする
- allowCredentialsの中身は空
  - allowCredentials = [];
ID入力からのパスキー要求
- 入力されたIDから当該ユーザーのパスキーのcredential IDを絞り込む
- 当該のcredential IDを、allowCredentialsの中に含める
  - allowCredentials = [credentialId, credentialId];

認証フローの概要

ユーザーがパスキーでログインを選択
サーバーが認証開始要求を受信
チャレンジなどのデータをブラウザに送信 (PublicKeyCredentialRequestOptions)
ブラウザがオーセンティケーターにデータを渡す (authenticatorGetAssertion)
- authenticatorGetAssertion の入力値にはrpId, hash などがあるが、このhashの中にシリアル化されたclientDataのハッシュが含まれる。この中に、先ほどサーバーで生成されたhashも含まれる。
オーセンティケーターでユーザー検証
- ユーザー検証「利用者を識別すること」を目的とした「認証器がクレデンシャル生成ないしアサーションの取得のためのローカルでの許可」の確認（PINやパスワードの入力、生体情報での識別）
パスキーによる署名
- authenticatorDataとclientDataHashを結合してクレデンシャルのプライベート鍵を用いてassertion signatureを生成
署名されたデータをブラウザに返送
- この時selectedCredential.userHandleにユーザー識別子がセットされて返るのでサーバはどのユーザかがわかるようになる。
署名されたデータをサーバーに返送(AuthenticatorAssertionResponse)
サーバーで検証
- 登録されている公開鍵で署名を検証

クロスデバイス認証

異なるデバイス間でパスキーを共有し、認証を行う方法としてクロスデバイス認証があります。この場合、ログインするデバイスでQRコードが表示され、パスキーを持つ別のデバイスでそのQRコードを読み取ることで認証が可能になります。Bluetooth接続が必須となり、一定の距離内でのみ認証できます。クロスデバイス認証の導線と、各デバイスでの操作手順が解説されました。

QRコードを使用して異なるデバイス間で認証可能
Bluetooth接続が必要

5. よくある誤解と質問への回答

パスキーはサーバーに送られない
フィッシング対策はRPIDとオリジンチェックによって実現
必ずしもユーザー検証が必要なわけではない。
- “Relying Party”のJavaScriptアプリケーションが“Relying Party”のサーバーに返答するauthenticatorData内のフラグで、Bit 2がユーザー検証の有無を示す。
生体情報はサーバーに共有されない
パスキープロバイダーは基本的に秘密鍵を見ることができない
1つのアカウントに対して複数のパスキーを作成可能
シンクドパスキーとデバイスバウンドパスキーの違い
- シンクロパスキー: デバイス間で同期可能
- デバイスバウンドパスキー: 特定のデバイスにのみ紐づく

6. 今後の展望

レポートAPI: ユーザー情報の変更をオーセンティケーター側に伝える仕組み
アテステーションの活用: セキュリティレベルの確認や特定デバイスの制限など

この会議では、パスキーの基本概念から実装の詳細、実際の導入事例まで幅広くカバーされており、現在のパスキー技術の状況と今後の課題について深い洞察が得られました。

Q&A

なお、セッション中にいくつかQ&Aが行われていました。

Q. メルカリでパスキーの登録時にSMS OTPを要求するのはなぜですか？

フィッシング対策の強化:
- メルカリの大井氏によると、これはフィッシングリスクをさらに軽減するための措置です。
既存の強力な認証方法の活用:
- パスキー登録前の段階では、IDパスワードとSMS OTPの組み合わせが最も強力な認証方法となっています。
多層防御:
- 仮にIDとパスワードがフィッシング攻撃で漏洩したとしても、SMS OTPという追加の障壁があることで、不正なパスキー登録のリスクを減らすことができます。
2段階の検証:
- ログイン時にIDパスワードとSMS OTPを使用し、その後パスキー登録時にも再度SMS OTPを要求することで、2回のSMS OTP検証を行うことができます。
リスク軽減:
- この方法により、フィッシングされた情報を使って攻撃者が不正にパスキーを登録するリスクを軽減できます。
ユーザー体験とセキュリティのバランス:
- 大井氏は、これがUXとセキュリティのバランスを取る上で一定の妥協点であると述べています。
サービスによる判断:
- ただし、全てのサービスがこの方法を採用しているわけではありません。各サービスのリスク評価や、ユーザーがパスキー登録に至るまでの経路によって、追加認証の要否を判断する必要があります。
既存アカウントの保護:
- 特に既存のユーザーベースを持つサービスでは、アカウント乗っ取りのリスクを軽減するために、パスキー登録前の認証を強化する必要があります。

このアプローチは、パスキーという強力な認証方法を導入する際に、その登録プロセス自体もセキュアに保つための戦略の一つとして位置付けられています。

Q: パスキー実装のアンチパターンとしてこういうことをやってしまうと脆弱性を作ってしまうというものがありますか。

A: パスキーのライブラリを使わずに全部自分で実装して、オリジンを検証しないと脆弱性を生む可能性があります。また、パブリックキーの検証をしないと脆弱性になります。さらに、ユーザーベリフィケーションのフラグ(UV)を適切に検証しないと、セキュリティリスクが高まります。

Q: ユーザーネームにメールアドレスを入れた場合、ユーザーがログインに用いるメールアドレスを変更した際、認証機側のユーザーネームを更新することはできますか。

A: 現状ではユーザーネームを更新することはできません。ただし、今後レポートAPIが実装されれば、RPからユーザー情報の変更を認証機に通知し、ユーザーネームを更新できるようになる予定です。

Q: FIDOクレデンシャルとパスキーって何が違うんですか。

A: FIDOアライアンスの定義では、あらゆるパスワードレス認証のクレデンシャルをパスキーと呼んでいます。セキュリティキーやUAFなども、ファイルクレデンシャルの一種であり、パスキーに含まれます。

Q: フィッシング耐性の観点でChromeのパスワードマネージャーとパスキーの差が知りたいです。

A: パスワードマネージャーは文字列を保存しているため、ユーザーがコピー&ペーストしてしまえばフィッシングサイトで使用できてしまいます。一方パスキーはコピー&ペーストができないため、フィッシング耐性があります。パスキーならコピペできないので、サジェストされないサイトではログインできません。

Q: extensionsについてどれくらい自由に指定できるものなのでしょうか？

A: エクステンションは、ブラウザやOSに実装されている機能次第で、自由に指定できるわけではありません。ドキュメントに記載されているエクステンションのみ使用可能です。

Q: メルカリでは当初デバイスバウンドだけだったのがシンクドも利用可能にしたとのことでしたが、シンクド共有をしたことによる新たな普段や特有のトラブルはありましたでしょうか？

A: シンクドパスキーを導入したことで、iCloudの設定が適切でないユーザーからの問い合わせが増えるなどの新たな課題が発生しました。また、デバイスを紛失した場合の対応も必要になりました。一方で、デバイスバンドパスキーに比べて問い合わせ数は減少しました。

Q. クロスデバイス認証は背後からQRコードを読み取られるリスクがあると思うのですが、これを禁止することはCredentialCreationOptionsなどの指定で可能ですか？

A. 現在はできません。

Q: caBLE, ハイブリッドでのパスキーの利用ですが、操作端末とパスキーを持つ端末をそれぞれ別で操作することはできないんでしょうか？Bluetoothでの接続が必須となるのでしょうか？

A: はい、Bluetooth接続が必須となります。離れた場所にある端末ではパスキー認証ができず、Bluetooth通信が可能な一定距離内でのみ認証が行えます。

Q: パスキーの仕様書として、WebAuthnのレベル3はまだドラフトという認識ですがレベル2とレベル3の現在の立ち位置の違いを伺いたいです。またレベル3にも、w3.org とW3C.GitHubIOの仕様書の2種類が存在していますが今回のハッカソンの実装上はどれを参照するのが良いのでしょうか？

A: レベル3はまだドラフトの段階で、ブラウザに実装されていない機能が多数含まれています。一方でレベル2はブラウザにおおむね実装されているため、ハッカソンではレベル2の仕様を参照するのが適切です。レベル3の仕様書は最新のドラフトですが、まだ実装されていない部分が多いでしょう。

Q: IDパスワードはパスワード間違いが多いと思いますがパスキーでの認証成功率は何に依存するのでしょうか？

A: パスキーでの認証成功率は、生体認証の失敗、デバイスの状態(パスキーが同期されていないなど)、ユーザーの操作ミスなどに依存します。パスワードに比べて成功率は高いものの、完全ではありません。

Q: 「Passkeys」という言葉の正確な定義は何でしょうか？

A: 仕様書の中で「パスキー」という言葉の明確な定義はありません。ただし一般的には、パスキーとは認証に使う秘密鍵のことを指します。厳密な定義はないため、ワードとしての「パスキー」の捉え方で問題ありません。

Q: Synced passkeys と Device-bound Passkeys などそれぞれの言葉はどの仕様で定義されていますか。

A: これらの言葉の定義は、仕様書ではなくFIDOアライアンスのFAQなどで記載されています。正式な仕様での定義ではありません。

Q: シンクド（同期）パスキーとそうでないパスキーの違いが知りたいです。

A: 同期パスキーは、クラウドなどを介して複数のデバイス間で共有できるパスキーです。デバイス固定パスキーは、特定のデバイスにのみ存在し、他のデバイスで利用できません。Appleデバイスでは全てのパスキーが同期パスキーとなり、Androidデバイスではオプションで同期/デバイス固定を選択できます。

Q: アテステーションはどういったユースケースが想定されているものなのでしょうか？

A: アテステーションは、デバイスが信頼できるものかどうかを検証するために使われます。デバイスメーカーによって異なる署名が入っているため、エンタープライズ向けのサービスでは利用が難しい場合があります。一般的なコンシューマー向けサービスでは、アテステーションの有無に関わらずパスキーを提供するのが適切とされています。

4:57 メルカリにおけるパスキーの導入事例
24:23 パスキーの登録
50:28 パスキーによる認証フロー概観
1:12:40 休憩
1:25:22 Q&Aタイム

より詳細な情報

上記のまとめだとあまりにも簡潔にすぎるので、Claudeに追加でいくつか質問しました。なお、音声のトランスクリプトしか入れていないのにコードサンプルが出てくるのは、Claudeが持っている知識を使っていると思われます。（なので、正しいかどうかは謎）

Q. パスキーの登録における、Server側の実装について説明してください。

パスキーの登録における、サーバー側の実装について、会議での説明を基に詳細にまとめます：

チャレンジの生成:
- サーバーは、認証のためのランダムな値（チャレンジ）を生成します。
- このチャレンジは後でチャレンジレスポンス認証に使用されます。
登録オプションの準備:
- サーバーは以下の情報を含む登録オプションを準備します：
  - チャレンジ
  - ユーザー情報（ユーザー名、ユーザーID等）
  - 既存のクレデンシャルID（既に登録されている場合）
  - リライングパーティ（RP）の情報（名前、RPID等）
データのエンコード:
- 準備した情報は通常、Base64でURLエンコードされてクライアントに送信されます。
クライアントへの送信:
- エンコードされたデータをJSONフォーマットでクライアントに送信します。
レスポンスの受信:
- クライアントから送り返されたアテステーションレスポンスを受信します。
- このレスポンスには、クライアントデータJSON、アテステーションオブジェクト等が含まれています。
デコードと検証:
- 受信したデータをBase64デコードします。
- デコードしたデータを検証します。
検証プロセス:
- チャレンジの一致確認: 保存していたチャレンジと一致するか確認
- オリジンの確認: RPが許可したオリジンかどうか確認
- 公開鍵の抽出: アテステーションオブジェクトから公開鍵を抽出
- フラグの確認: UV（User Verification）、UP（User Presence）等のフラグを確認
パスキーの保存:
- 検証が成功した場合、以下の情報を保存します：
  - 公開鍵（必須）
  - クレデンシャルID（エクスクルードクレデンシャルに使用）
  - アルゴリズム（認証に使用される暗号アルゴリズム）
  - 登録要求時の追加情報（任意）
エラーハンドリング:
- 検証プロセスで問題が発生した場合、適切なエラーメッセージを生成し、クライアントに返します。
セキュリティ考慮事項:
- アテステーション検証: デバイスや認証器の信頼性を確認する場合に実施
- ユーザー検証（UV）フラグの扱い: サービスのポリシーに応じて、UVフラグの有無による処理を決定
レスポンス:
- 登録成功または失敗のレスポンスをクライアントに返します。

実装上の注意点:

ライブラリの使用: 多くの場合、WebAuthn/FIDO2ライブラリを使用して実装を簡略化します。
セキュアな乱数生成: チャレンジ生成には暗号学的に安全な乱数生成器を使用します。
RPID設定: フィッシング対策として重要なRPIDを適切に設定します。
データの永続化: 公開鍵などの重要データを安全に保存するための仕組みを整えます。

この実装フローは基本的なものであり、具体的なサービスの要件や使用するライブラリによって詳細が異なる可能性があります。セキュリティを重視しつつ、各サービスの特性に合わせた実装を行うことが重要です。

Q. パスキーの登録における、Client側の実装について説明してください。

パスキーの登録における、クライアント側の実装について、会議での説明を基に詳細にまとめます：

サーバーからの情報取得:
- サーバーのURLにアクセスし、登録に必要な情報（オプション）を取得します。
- 取得したデータは通常Base64でURLエンコードされているため、デコードする必要があります。
データの準備:
- デコードしたデータを適切な形式に変換します。
- 主な項目には以下が含まれます：
  - チャレンジ
  - RPID（Relying Party ID）
  - ユーザー情報（name, displayName等）
  - 公開鍵の生成に関するパラメータ
navigator.credentials.create() APIの呼び出し:
- Web Authentication APIを使用して、パスキーの作成を開始します。
- 準備したデータを引数として渡します。

const publicKeyCredential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});

ユーザーインタラクション:
- ブラウザはユーザーに対して認証器（オーセンティケーター）の選択を促します。
- ユーザーは生体認証やPIN入力などで本人確認を行います。
パスキーの生成:
- 選択された認証器がパスキー（公開鍵と秘密鍵のペア）を生成します。
- 秘密鍵は認証器内に安全に保存されます。
アテステーションレスポンスの取得:
- 認証器は生成したパスキーに関する情報を含むアテステーションレスポンスを返します。
レスポンスの処理:
- 返されたアテステーションレスポンスを適切な形式に変換します。
- 主な項目には以下が含まれます：
  - クライアントデータJSON
  - アテステーションオブジェクト
  - 公開鍵
サーバーへのデータ送信:
- 処理したデータをサーバーに送信します。
- データは通常、Base64エンコードされてJSONフォーマットで送信されます。

const response = await fetch('/register', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    id: base64url.encode(publicKeyCredential.rawId),
    rawId: base64url.encode(publicKeyCredential.rawId),
    type: publicKeyCredential.type,
    response: {
      clientDataJSON: base64url.encode(publicKeyCredential.response.clientDataJSON),
      attestationObject: base64url.encode(publicKeyCredential.response.attestationObject),
    },
  }),
});

エラーハンドリング:
- プロセス中に発生する可能性のあるエラーを適切に処理します。
- 主なエラーには以下があります：
  - ユーザーによるキャンセル
  - 非対応デバイス
  - タイムアウト
UI更新:
- 登録プロセスの状態をユーザーに適切にフィードバックします。