パスワードのない未来:より安全で使いやすい認証システムを目指して

わかりやすい比metaでパスワードを秘密鍵に置き換える

EOSIO Labs™イニシアチブの導入により、EOSIOで構築されたブロックチェーンテクノロジーの将来に関してオープンなイノベーションを開始しました。このイニシアチブでの最初のリリースでは、秘密鍵管理の将来と、そのセキュリティと鍵管理への影響、つまりユニバーサル認証システムライブラリ(UAL)を調査します。このリリースの哲学の根底にあるのは、インターネット、ブロックチェーンなどでパスワードと認証がどのように実装されているかに焦点を合わせた、より大きな問題の調査です。この記事に付随するソフトウェアリリースはありませんが、この記事の目的は、既存の認証システムを悩ます問題、およびそのような問題に付随するパスワードを超えて移動しようとする現代の試みを議論することです。次に、これらの問題に安全で使用可能な方法で対処するために、航空券や図書館カードなど、「パス」のメタファーを使用した新しいモデルを抽象的に提案します。

伝聞問題

ユーザーを認証する現在の方法は、「伝聞問題」と呼ぶものに苦しんでいます。伝聞は、十分に立証できない、一方の当事者から他方の当事者の声明または行動について受け取った情報です。私たちのスタンスは、ユーザーを認証する現在の最先端の方法に依存するシステムから供給されたすべての情報は、関係者のいずれかが情報の有効性を疑問視する場合、単なる伝聞としての資格を得るというものです。

説明のために、有名な政治家によって執筆されたと言われている評判の悪いソーシャルメディアの投稿が、その政治家のキャリアを破壊する恐れがあると想像してください。政治家が実際にその名誉をpost損した記事を執筆したことをどのようにして確認できますか著者は確かに問題の政治家である可能性がありますが、政治家のソーシャルメディアアカウントにアクセスできる人も同様です。この推論を拡張するために、可能性のある「著者」のプールには、政治家に近い任意の数の人々、または標的型攻撃の敵対的ハッカーを含めることができます。しかし、政治家とソーシャルメディアサービスプロバイダーを含む誰も、政治家が問題の投稿の著者であるかどうかを決定的で非状況的な証拠として提示することはできません。

法律用語および技術用語を使用する場合、この特性は否認可能性と呼ばれ、望ましい特性ではありません。上記のソーシャルメディアの例では、2つの主要な要因が否認可能性のこの特性につながります。最初の要素は、その秘密の所有を検証するために秘密の開示を必要とする認証スキームです。この要因の対象となるセキュリティスキーム(パスワードなど)では、当事者および取引相手以外の誰でも検証可能なユーザーアクティビティのログを作成することはできません。 2番目の要因は、システム内のデータが実際にユーザーの意図を表していることを証明する手段がないことです。これは、「ブランクチェック」という別の問題につながります。

ブランクチェックの問題

ブランクチェックの問題は、その特定のアクションについてユーザーの明示的な同意を必要とせずに、ユーザーに代わってアクションを実行できるシステムに存在します。また、ユーザーの同意を取得する手段が、個々のアクションの意味をユーザーに通知し、各アクションに明示的に同意したという証拠のログに満たない場合にも存在します。

上記の例では、この問題により、ソーシャルメディアサービス自体とその従業員の多くが、とんでもない投稿を投稿した可能性のあるパーティーのリストに追加されます。ソーシャルメディアサービスまたはその従業員の1人が、政治家に代わって「役職」へのアクセスを侵害していないことをどのように証明できますか? 「ブランクチェック問題」という名前の適切性を示すこの問題のより重要な例は、銀行口座の例です。技術的に言えば、銀行が資金を清算またはロックすることを防ぐものは何もありません。また、銀行は一見正当な取引の記録を作成できるため、不正行為を証明する手段はありません。これは間違いなく重大な結果をもたらし、多くの利害関係者に重大な影響を及ぼします。

「二つになる」

抜け目のないオブザーバーは、これらの問題が実際に同じ根本的な問題の2つの結果であることに気付いているかもしれません:証明可能な監査ログの欠如非対称暗号化に基づく証明書ベースのシステムなど、現在のシステムにはこの基本的な欠点に対処するテクノロジーがありますが、それらは一般の人々がアクセスできるレベルの使いやすさをまだ達成していません。以下に示す理論的ソリューションのわかりやすいメタファーでこの課題に対処することで、あらゆる種類のユーザーに対して、すべてのシステムのセキュリティと使いやすさを改善し、プロセスでのユーザーエクスペリエンスを改善する機会があります。

パスワード

サイバーセキュリティについて議論する場合、2つの基本的な用語を定義する必要があります。「認証」。ユーザーが特定の資格情報(通常はユーザー名とパスワード)を所有していることを証明するプロセスです。 「承認」。これは、ソフトウェアプラットフォーム内でのユーザーのアクションがIDに応じて許可または制限されるプロセスです。

1960年代以来、パスワードは、ユーザーがデバイスまたはサービスに対して自分自身を認証できるようにする事実上の方法です。現在、パスワード認証は、エンジニアにとって十分に理解されている技術です。ユーザーにとって、パスワードは簡単に把握できる概念になっています。彼らは技術に詳しくないユーザーにとっても快適で馴染みがあります。しかし、そのシンプルさと親しみやすさは強みですが、パスワードにも多くの弱点があります。

このような弱点は、本質的に技術的かつ人間的です。それらの一部は、NISTデジタルアイデンティティガイドラインの網羅的な詳細を含め、広く議論されているため、ここでは繰り返しません。ただし、覚えておくべき重要なことは、パスワードでは、ユーザーが承認したアクションの信頼できる監査可能なログが有効にならないことです。パスワードで認証するには、パスワードを明らかにする必要があります。また、ユーザーのパスワードの有効性を確認するために、サービスプロバイダーは何らかの形で集中インフラストラクチャにパスワードを保存する必要があります。これは、サービスプロバイダー以外の誰もが、保持している監査ログがユーザーのアクションの正確な表現であることを確信できないことを意味します。このため、認証のためにパスワードに依存するシステムは、上記のように、伝聞問題と空白チェック問題の両方の影響を受けます。

パスワードを改善または置換しようとする現代の試み

パスワードを段階的に改善または置換しようとする試みが長年にわたっていくつかありました。以下では、いくつかの最も成功したケースとその長所と短所を確認します。

パスワードマネージャー

パスワードマネージャーの存在は、パスワードの基本的な欠陥のいくつかを認めていることを表しています。彼らは、ユーザーが十分に複雑なパスワードを生成して記憶する必要がないようにすることで状況を改善しようとします。したがって、はるかに高いレベルのセキュリティ厳格を満たす単一目的のパスワードを許可します。

正しく使用すると、パスワードマネージャーはセキュリティを向上させ、パスワードベースの認証を使用したシステムの使いやすさを制限します。それでも、両親、子供、または技術に詳しくない友人に今日のパスワードマネージャーソフトウェアの反復を使用するように教えようとした人は、彼らが広く採用されておらず、そのようになるほど使用できないことを痛感しています。

技術的な観点から、パスワードマネージャーの標準はありません。ユーザーがアカウントを作成しているとき、ログインしているとき、またはパスワードを更新して便利にしたときを推測しようとしますが、失敗することがよくあります。これらは、改善されたソリューションの基礎を提供しますが、最終的には、まだ単なるパスワードであり、「伝聞問題」と「ブランクチェック問題」の両方の影響を受けます。

二要素認証

パスワードの脆弱性を認識して、パスワード自体が単一障害点ではないことを保証するために、追加のセキュリティを重ねる試みが行われました。このアプローチは通常、2番目の要素、または2要素認証(2FA)と呼ばれます。 2FAにはさまざまな実装があり、それらはすべて、パスワードベースの認証システムにさまざまな程度の増分セキュリティを追加しますが、セットアップとエンドユーザーの操作の面で追加の複雑さを補います。一般的な2FAソリューションは、SMSメッセージに基づいて、時間ベースのワンタイムパスワード(OTP)を提供します。パスワード自体と同様に、2要素ソリューションは、監査可能ではなく、SMSメッセージをデバイスに配信する電話会社のセキュリティ慣行に対して脆弱であるという問題に悩まされています。

この証明可能な監査能力の欠如は、2FAがまだ「伝聞問題」または「ブランクチェック問題」を解決していないことを意味します。

WebAuthn標準

WebAuthnは、World Wide Web Consortium(W3C)、メンバー組織の国際コミュニティ、フルタイムのスタッフ、およびWeb標準を開発するための共同作業によって提案された新しい認証標準です。 WebAuthnは、パスワードの代わりに非対称暗号化を使用することにより、Webベースのトランザクションに関するこれらの問題をすべて解決することに非常に近づきます。ただし、デバイスを紛失したユーザーがすべてのサービスからロックアウトされるのを防ぐために、WebAuthnは、置き換えとしてではなく、パスワードと組み合わせて使用​​するように設計されています。

WebAuthnのもう1つの重要な制限は、同意の証明としてではなく、存在の証明として設計されたことです。ピアによる監査が可能なトランザクションごとの許可要求を許可するように定義されていません。繰り返しになりますが、WebAuthnに依存しているシステムには証明可能な監査ログがなく、「Hearsay問題」と「Blank Check」問題の両方の影響を受けます。

潜在的なソリューションとしてBlockchain

ブロックチェーンは、この目標を達成するためにトランザクションの公開鍵暗号署名を使用して、ユーザーが許可するすべてのアクションに対してユーザーを認証するという考え方を広めました。これはパスワードの大幅な改善であり、WebAuthnが提供できるものを超えた一歩です。また、Hearsay問題に対処するために必要な最初の要素である証明可能な監査可能性も満たします。

残念ながら、今日のブロックチェーンのユーザーインターフェースは、ユーザーに信頼できるコンテキストで表示できるように、ユーザーにわかりやすい方法で承認リクエストを記述するための標準も定義していません。この人間に優しい要求レンダリング標準がなければ、ユーザーは同意するものを知ることができません。つまり、ブロックチェーンは証明可能な監査可能なログを作成しますが、システム内のデータが実際にユーザーの意図を表していることを証明する手段がありません。このように、彼らはまだ伝聞やブランクチェックの問題の対象となっています。

ソーシャルメディアの例に戻ると、ソーシャルメディアプラットフォームがブロックチェーン上に構築されている場合、問題の政治家が実際に投稿につながったアクションに署名したことを証明できますが、証明することはできません彼ら(または別の政党)は、政治家をだまして、虚偽の表現で行動に署名させなかった。

理論解は:キーまたはパスワードの代わりに「合格します」

システムのセキュリティを向上させるには、ユーザーの同意を証明するものと、パスワードを超えるシンプルさと使いやすさのレベルが必要です。つまり、技術者だけでなく、あらゆる種類のユーザーがすぐに理解できる隠phorを通じて、非対称暗号化などの複雑なテクノロジーを伝える必要があります。これらの基準を満たす1つの概念は、「パス」の概念です。パスの概念を説明する際に、パスマネージャーアプリケーションで使用されるパスのこの理論的な解決策が、先ほど説明したハーシー問題とブランクチェック問題の両方を満たす方法を示します。

ユーザーにとって、パスは、クレデンシャルの所有を証明する身近で具体的な手段を表します。毎日、私たちは日常の一部として物理的なパスとやり取りしています。ライブラリユーザーは、ライブラリカードを提示して提示するだけです。航空会社の乗客は、チケットを提示して提示するだけです。これらは単一目的パスの例です。単一目的パスを提供しないサービスの場合、運転免許証を提示して身元を証明することができます。

認証と承認のユースケースをサポートするために、デジタル「パスマネージャー」の概念を導入します。 Pass Managerは、登録、認証、および承認のユースケースのためのパスワードなしのパラダイムです。

パスマネージャーで何ができますか?

発行と失効

  • サービスプロバイダーは、ユーザーに対して新しいパスを発行するようにパスマネージャーに要求できます。
  • ユーザーがグループに自分のパスを整理することができます。 (例えば、私の仕事は渡し、私の個人的なパス)
  • ユーザーは、複数のデバイス間でパスを認証および認証解除できます。

認証

  • サービスプロバイダーは、ユーザーがパスを所有していることの証明を要求できます。
  • ユーザーは、パスを所有している証拠を提供できます。

認可

  • サービスプロバイダーは、ユーザーが所有するパスの権限で、特定のアクションを実行するユーザーの承認の証明を要求できます。
  • ユーザーは、人間に優しい方法で明確にレンダリングされた認証要求を見て、彼らが持っているパスの権限に、アクションを許可するかどうかを選択することができます。

どのようにパスマネージャの仕事でしょうか?

パスマネージャーは、パスの発行と取り消し、パス、認証、および承認のための(まだ定義されていない)標準化されたプロトコルを実装します。パスは、資格情報(キー)をカプセル化する概念的な抽象概念です。

デジタルパスマネージャーの使用経験は、パスカードの物理的なアナログに非常に類似している必要があります。ユーザーは単にサービス(Webアプリ、ネイティブアプリ、POSシステム、キオスク)に到着し、サインインまたはアクションを承認するためのパスを提示します。これは、大学の学生が大学のスポーツイベントに入学するために大学IDを使用し、いったん入場すると、キャンパスのダイニングバランスのあるスタンドで食料を購入するために使用され、取引にコミットする前に注文確認が提示されるようなものです。

内部では、暗号化署名、ハードウェアキー、クレデンシャルセキュリティ用の生体認証、移植性のためのトランスポートに依存しないプロトコルなど、さまざまなテクノロジーが連携して機能し、ユーザーに優れたセキュリティと使いやすさをもたらします。

Pass Managerがユーザーの同意を求めた場合はいつでも、アクションの人間にわかりやすい説明をユーザーに表示し、その説明(または暗号的に検証可能な派生物)をPass Managerからの署名付き応答に含める必要があります。キーを使用することは、ログが否認不可であり、第三者が検証できることを意味します。また、署名された応答に人間に優しい説明を含めることは、ユーザーの意図の証拠として役立ちます。これらの特性は、伝聞やブランクチェックの問題の両方を解決します。

このモデルは、現在のWebテクノロジーと将来のブロックチェーンテクノロジーのユースケースの両方をサポートできます。また、ログインと承認の両方のユースケースに明確なユーザーエクスペリエンスを提供することもできます。

パスマネージャーを成功させるには何が必要ですか?

相互運用性

何よりもまず、Pass Managerプロトコルを構築して、ユーザーがニーズに最適なPass Managerを自由に選択できるようにする必要があります。これは、ベンダーのロックインを防ぎ、セキュリティとユーザーエクスペリエンスの両方の革新を促進するために必要な自由市場を作成するため、重要です。この方法では、許容可能なセキュリティで最高のユーザーエクスペリエンスを獲得します。

この選択の自由を提供するには、サインアップ、ログイン、および承認のための標準プロトコルが必要になります。特に、認可は興味深い課題です。なぜなら、それは、理解可能で、監査可能で、証明可能で、移植可能な方法でユーザーへの認可の要求を記述するための標準の定義を必要とするからです。

移植性

次に、移植性のためにPass Managerプロトコルを構築する必要があります。意味:1)任意のプラットフォームで実行されるあらゆる種類のアプリケーションまたはサービスのサポート、2)ネットワーク接続の制限または非接続のサポート、3)複数のデバイスのサポート、4)クロスデバイス通信のサポート。

ユーザーは、デスクトップコンピューター、ラップトップコンピューター、電話、タブレット、スマートウォッチ、およびUSBキーを持っています。そのため、複数のデバイス間でパスアクセスを発行および取り消しするためのシンプルでシームレスなエクスペリエンスが重要です。ユーザーは、POSシステム、信頼できない公共のコンピューター、自動販売機、キオスクとも対話します。そのため、デバイスを相互に信頼する必要なく、ネットワーク接続の有無にかかわらず、あるデバイスから別のデバイスと対話する機能が必要です。

これらの要件は、Pass Managerプロトコルをトランスポートに依存しないように定義することで満たすことができます。つまり、プロトコルは、実装システムが流fluentに話すことができなければならない名詞と動詞の定義に焦点を合わせ、それらが話されるトランスポートが異なるようにする必要があることを意味します。トランスポートの例には、カスタムプロトコルURL、Appleユニバーサルリンク、Androidインテント、サーバーリクエスト、QRコード、Bluetooth、NFC、およびJavaScript APIが含まれます。この柔軟性により、Pass Managerは真にポータブルになります。

使いやすさ

ユーザーは、データベースバックエンドまたはブロックチェーンシステムでWebサービスを使用しているかどうかの意味を考慮する必要はありません。ブロックチェーンの場合、使用しているアプリケーションがどのブロックチェーンプラットフォームまたはネットワーク上に構築されているかを知る必要はありません。ユースケースのみを考慮する必要があります。のようなもの…

「私はATMから資金を引き出しています。」

「メールにログインしています。」

「ソーシャルメディアでの投稿が好きです。」

「チップを自動販売機から購入しています。」

「ダンからブライアンに100個のトークンを転送しています。」

決して…

「EOSIOプラットフォーム上に構築されたTelosブロックチェーン上に構築されたexample.com dappで、blockchain11アカウントに対して承認されたR1キーでトランザクションに署名しています。」

安全性

パスワードと公開鍵システムの両方の現在の実装は、さまざまな理由で安全ではありません。パスマネージャーは、もっとうまくやらなければなりません。

集中化されたクレデンシャルのハニーポットに対する攻撃からユーザーを保護するために、秘密のクレデンシャルデータは、いかなる形でも集中インフラストラクチャに保存されるべきではありません(ハッシュとソルトでは不十分です)。フィッシング、マルウェア、および中間者攻撃によって資格情報が盗まれるのを防ぐために、ユーザーは実際に資格情報が何であるかを決して知ってはならず、サービスに手動または自動で入力することはできません。悪意のあるパスを追加するようにだまされないようにユーザーを保護するために、ユーザーは自分でパスを追加または削除できないようにする必要があります。代わりに、信頼できるパスマネージャーは、ユーザーが新しいサービスにアクセスしたり、新しいデバイスを取得したことに応じて、ユーザーの代わりにこれを自動的に処理する必要があります。

未来はパスマネージャーにとって広く開かれています

この記事では、ユーザーアカウントをセキュリティで保護するための最新の方法に関するセキュリティと使いやすさの問題に対処するために解決すべき問題を示しました。これらの問題を解決する手段として、パスワードとデジタルパスマネージャーを置き換えるパスの概念を紹介しました。 Pass Managerプロトコルが成功するために必要な属性について説明しましたが、プロトコルを明示的に定義していません。進取の気性のある開発者は、パスワードとキーベースのセキュリティシステムの両方を悩ます問題を解決し、その目標を達成する1つの方法としてPassのメタファーを検討することをお勧めします。

免責事項:Block.oneは、EOSIOコミュニティのメンバーとして自発的に貢献し、ソフトウェアまたは関連アプリケーションの全体的なパフォーマンスを保証する責任を負いません。ここに記載されているリリース、関連するGitHubリリース、EOSIOソフトウェア、または明示または黙示を問わず、保証または商品性、特定の適合性を含むがこれらに限定されない関連ドキュメントに関する表明、保証、保証または約束を行いません目的と非侵害。いかなる場合においても、ソフトウェア、文書、またはソフトウェアでの使用またはその他の取引に起因する、またはそれらに関連する契約、不法行為、その他の行為にかかわらず、請求、損害またはその他の責任について責任を負いません。ドキュメンテーション。テスト結果やパフォーマンスの数値は参考値であり、すべての条件下でのパフォーマンスを反映するものではありません。サードパーティまたはサードパーティの製品、リソース、サービスへの言及は、Block.oneによる承認または推奨ではありません。これらのリソースの使用または依存について、当社は一切責任を負わず、一切の責任と責任を放棄します。サードパーティのリソースはいつでも更新、変更、または終了される可能性があるため、ここに記載されている情報は古くなったり不正確になったりする場合があります。第三者へのソフトウェア、商品またはサービスの提供に関連してこのソフトウェアを使用または提供する人は、これらのライセンス条件、免責事項、および責任の除外について第三者に助言するものとします。 Block.one、EOSIO、EOSIO Labs、EOS、7面体および関連するロゴは、Block.oneの商標です。ここで参照されているその他の商標は、それぞれの所有者の財産です。ここに記載されている声明は、Block.oneのビジョンを表したものであり、何の保証もありません。また、Block.oneの独自の裁量により、あらゆる側面が変更される場合があります。 EOSIOの開発、期待されるパフォーマンス、将来の機能、または当社のビジネス戦略、計画、見通し、開発、および目標に関する記述など、歴史的事実の記述以外の、本書の記述を含むこれらの「将来の見通しに関する記述」。これらの記述は単なる予測であり、将来の出来事に関するBlock.oneの現在の信念と期待を反映しています。それらは仮定に基づいており、リスク、不確実性、およびいつでも変化する可能性があります。急速に変化する環境で事業を展開しています。新しいリスクは時々発生します。これらのリスクと不確実性を考えると、これらの将来の見通しに関する記述に依存しないよう注意してください。実際の結果、パフォーマンス、またはイベントは、将来の見通しに関する記述で予測されたものと大きく異なる場合があります。実際の結果、パフォーマンス、またはイベントが将来の見通しに関する記述と大きく異なる可能性がある要因には、以下が含まれますが、これらに限定されません。資本、資金調達および人材の継続的な利用可能性;製品の受け入れ;新しい製品または技術の商業的成功。コンペ;政府の規制と法律。および一般的な経済、市場またはビジネス条件。すべての声明は、最初の投稿の日付の時点でのみ有効であり、Block.oneは、新しい情報、その後の出来事、またはその他の結果として、声明を更新または変更する義務を負わず、その義務を明示的に否認します。本書のいかなる内容も、一般的または特定の状況または実装に関して、技術的、財務的、投資、法的またはその他の助言を構成するものではありません。このドキュメントに含まれているものを実装または利用する前に、適切な分野の専門家に相談してください。