今日、インターネットセキュリティに大きな問題があることは周知の事実です。 ユーザーは軽いパスワードを使用し、他のリソースでそれらを再利用します。 パスワードマネージャはまだ平均的なユーザーにとって新しいものであり、祖母に高いエントロピーを持つランダムなワンタイムパスワードの使用を強制することはほとんどできません。 人生は腐敗と痛みです...

web2.0の夜明けに、パスワードが不足していることを認識し始め、2要素認証または2FAを発明しました。

今日の2FAソリューションとは何ですか？

• SMS-SMS経由で送信されるワンタイムパスワード。

  
  

• OTP（TOTP / HOTP）-マスターキーに基づいて生成されたワンタイムパスワード。 例：Google認証システム、Yubikey、銀行OTPトークン。

  
  
• 暗号化トークン-ユーザーの多要素認証用のハードウェア。 例：RSA SecureID、Rutoken。

ソリューションの選択肢が多いため、ユーザーはまだアカウントを離れています。 では、なぜ既存の技術では問題が解決しなかったのでしょうか？

多くの理由があります。

• フィッシング-リストされたソリューションのほとんどすべてがMITM（中間者）攻撃、およびそれに応じたフィッシングに対して脆弱です。 ユーザー名とパスワードを既に入力しているユーザーがワンタイムパスワードを入力できないようにするにはどうすればよいですか？

  
  

• セキュリティ-この場合、SMSについて説明します。 SMSは現在、市場で最も人気のある2FAソリューションです。 SIMカードの再リリースに関する話は、ロシアだけでなく、 アメリカ 、 南アフリカ 、 イギリス 、その他の国でも発生しています。 ほぼすべてのプロバイダーがSIMカードを復元する機能を提供しており、ソーシャルエンジニアリングの方法をキャンセルした人はいません。

  
  

• コスト-スイスの銀行で、顧客が7桁の外貨を保管している場合、RSAトークンは顧客の口座のセキュリティを確保するためのわずかな価格です。 また、TwitterまたはFacebookの場合、各ユーザーに高価なトークンを配布することは不可能です。 SMSにも費用がかかります。FreeBSDでKDEにパッチを適用する方法についてのアマチュアアニメディスカッションフォーラムがある場合、SMSを購入する余裕はほとんどありません。

  
  

• 互換性-ドライバーをいじるのが好きな人はいません。これが、RSAとRutokenがまだ世界を征服していない理由の1つです。

  
  
• 使いやすさ-ワンタイムパスワードの入力は面倒です。 画面のロックを解除し、メッセージを開き、コードを読み、間違いを犯し、電話とコンピューターを焼きます。これは、ユーザーインタラクションと2要素認証の標準アルゴリズムです。

このリストは長い間続けることができますが、その考えは伝えられていると思います。 今日のソリューションは、ユーザーを確実に保護することができず、使いにくく、高価であり、普遍的ではありません。

FIDO U2F-2番目の要素の普遍化

2013年、シリコンバレーでFIDO （Fast IDentity Online）アライアンスが組織され、インターネットでの簡単で安全な認証の課題に対処しました。 現在、FIDOには300人以上の準会員と30人の役員がいます。 取締役のリストには、Google、Yubico、Microsoft、Visa、Mastercard、American Express、Paypalなどの企業が含まれます。

FIDOが設定する主な目標は、使いやすく安全でプライベートな標準化されたソリューションです。

現在、FIDOは次の2つの標準を導入しています。U2F（Universal Second Factor）-ユニバーサル2番目の要因、UAF（Universal Authentication Framework）-生体認証のユニバーサル認証フレームワーク。 今日はU2Fについてお話します。 トピックが興味深い場合、将来的にはUAFに関する記事を書くことができます。

U2Fは、電子デジタル署名を使用した呼び出し応答認証に基づく、2要素認証用のオープンなドライバーレスプロトコルです。

どのように機能しますか？

U2Fプロトコルには、ユーザー、ブラウザ（技術クライアント）、プロトコル自体の3つの抽象化レベルがあります。

ユーザー

ユーザーにとっては、すべてが非常に簡単です。 ユーザーはユーザー名とパスワードを入力し、U2Fデバイスを挿入し、ボタンを押して認証に成功します。 実際、それについてはすでにHabraHabrに書いています。

ブラウザ

U2Fとのブラウザー側の対話アルゴリズムは次のとおりです。

• ユーザーはログインとパスワードの検証に合格します

  
  

• たとえば、U2F JS APIを介したGoogleの依存パーティは、チャレンジ署名を要求します

  
  
• ブラウザはリクエストをデバイスに転送します

ユーザーが、たとえば、ボタンを押すか、2要素認証を実行するという希望を確認した場合、デバイスはコール署名を返します

• ブラウザは署名を依存関係者に渡します

  
  
• アフィリエイトが署名を検証

プロトコル-または2要素認証を保護するための5段階半の手順

ステップ1-コールレスポンス

まず、簡単な電話応答を行います。 サーバーはランダム呼び出しを送信します。 デバイスはコールに署名し、サーバーに署名を返します。その後、サーバーは署名を検証します。

ステップ2-フィッシング保護

元のURLとチャンネルIDに署名する

mail.ruではなくr n ail.ruにログインした場合、署名を使用してアカウントにログインできるため、アンサーコールだけではフィッシングの問題は解決しません。 これを防ぐために、ブラウザーは呼び出しに署名要求の送信元のURLとTLSチャネルIDを追加し、その後、依存関係者がこのデータを確認します。

ステップ3-プライバシーまたは登録依存のキーペア

登録依存のペアを生成します

現時点では、デバイスは1組のキーですべてに署名しています。 これは、公開キーがどこでも同じであるという事実により、プライバシーの問題を引き起こします。 たとえば、悪名高いAshleyMadison.comに登録されている場合、攻撃者はマージされた公開キーと他のアカウントをバインドし、潜在的に物理的および道徳的な害を引き起こす可能性があるとしましょう。

登録中にプライバシーを保護するために、依存関係者はアプリケーションID（AppID）とシード（乱数）を渡します。 このデータに基づいて、デバイスは一意の登録依存キーペアを生成します。 デバイスがペアを生成する方法はプロトコルでは説明されていませんが、デバイスの製造元の裁量で完全に説明されています。 たとえば、各Yubikeyには独自のマスターキーがあり、HMACおよびPRNG（Pseudo Random Number Generator）と組み合わせて新しいペアを生成します。

https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

キーペアは登録ごとに一意であるため、複数のアカウントで単一のU2Fデバイスを共有することが可能になります。

ステップ4-クローン保護

U2Fはプロトコルにすぎないため、ハードウェアとソフトウェアで異なる実装を行うことができます。 一部の実装は、クローン作成に耐性がない場合があります。 これを防ぐために、U2Fデバイスには組み込みのカウンターがあります。 署名と登録ごとに、カウンターの状態が1つずつ増加します。 カウンターステータスが署名され、依存関係者に返されます。 U2Fデバイスが傾斜している場合、複製されたデバイスのカウンターステータスは元のデバイスのカウンターステータスよりも小さい可能性が高く、検証中にエラーが発生します。

ステップ5-キー認証

異なるプロトコルの実装は安全ではない場合があります。 これを回避するため、各U2Fデバイスには統合されたパーティ証明書があり、これは約10万デバイスごとにインストールされます。 各署名と登録は、公開鍵が公開ディレクトリにある証明書でさらに署名されます。

なぜこれが必要なのですか？ たとえば、子猫に関するフォーラムの場合、ユーザーのU2Fデバイスの安全性についてあまり心配する必要はありません。銀行の場合は、ハードウェアで作成されたデバイスのみを許可できます。

ステップ6半-オーバーキル保護

ユーザーがデバイスから離れている状況では、悪意のあるソフトウェアが徹底的な検索またはその他の種類の攻撃によってデバイスを攻撃しようとする場合があります。 これを防ぐため、U2F規格では、ハードウェアとソフトウェアのすべての実装をユーザーがアクティブにする必要があります。 ユーザーは、二要素認証に関する決定を確認する必要があります。 このアクションには、ボタンを押すだけ、PINコードを入力する、指紋などを取得することができます。

複数のエントリーサービス

Gmailを例にとってみましょう。

ウェブインターフェースとモバイルの両方からGmailにログインできます。 アプリケーションのAppIDとサービスのAppIDが異なる場合、Androidアプリケーションからユーザーを承認するにはどうすればよいですか？

これにはファセットがあります。

ファセットは、選択したサービスの認証を許可されているすべてのIDのリストを含むJSONファイルです。 たとえば、Googleのファセットは次のとおりです。

{ "trustedFacets": [{ "version": { "major": 1, "minor" : 0 }, "ids": [ "https://accounts.google.com", "https://myaccount.google.com", "https://security.google.com", "android:apk-key-hash:FD18FA800DD00C0D9D7724328B6...", "android:apk-key-hash:Rj6gA3QDA2ddyQyi21JXly6gw9...", "ios:bundle-id:com.google.SecurityKey.dogfood" ] }] } 

ファセットは、AppIDと同じドメイン空間に存在する必要があります。 たとえば、AppIDがhttps://example.com/facets.jsonの場合、 https：//**security**.example**.com はテストに合格しますが、 https：//security.example .net ** は合格しません。

モバイルアプリケーションの場合、ファセットには「OS：TYPE：ID」という形式のURIスキームがあります。 Androidの場合、SHA-1 apk署名証明書が計算されます。 iOSの場合、これはバンドルIDです。

ファセットはHTTPS経由で配布する必要があります！

仕様書

現時点では、USB、NFC、およびBluetooth LEの仕様は準備ができています。

ブラウザのサポート

Chromeは2015年初頭からU2Fをそのままサポートしています。FirefoxでのU2Fサポートは現在活発に開発されています。 MicrosoftはFIDO2.0スタックの一部としてWindows 10とEdgeの両方のU2Fサポートを発表しましたが、Insider Buildですでに利用可能です。

誰が使用していますか？

Google、Github、Wordpress、Dropbox、Evernote。 英国政府は最近、国営サイトにU2Fサポートを導入しましたが、これは非常に多くのことです。

U2Fに切り替える際に考慮すべきことは何ですか？

• HTTPSは必須です。さらに、ユーザーにHTTPSを提供しない場合、ユーザーのセキュリティについて心配する必要はなく、U2Fはほとんど関心がありません。 Firefox、Chrome、およびEdgeでは、U2F APIを使用するためにHTTPS接続が必要です。

  
  

• TLS SessionIDを試してください。

  
  
• U2Fは2番目の要因です。 銀行のようにならないでください。 主要因として2FAを使用しないでください。

まとめると

U2Fは、適切に設計され、強力で、オープンで、標準化されたテクノロジーです。 Googleは、現在、2要素認証の主な方法としてU2Fを使用している従業員に対してGoogleによるテストに成功しました。

U2Fは単なるプロトコルであり、U2Fに基づくソリューションの巨大な市場の創出を伴います。 セキュアな要素を備えた暗号キー、JavaCard実装から、モバイルアプリケーションや生体認証で保護されたU2Fデバイスまで、U2Fはそれを適用できる想像力の自由を与えます。

注釈

• https://fidoalliance.org/specifications/download/

  
  

• https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

  
  
• https://developers.yubico.com/U2F/

U2Fとその実装、およびFIDOアライアンスの他のソリューションについて詳しく知りたい場合は、コメントに書いてください。