- - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235352%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235352%2F&hashtags=ZDNET) - - 印刷する - - メールで送る - テキスト - HTML - 電子書籍 - PDF - - ダウンロード - テキスト - 電子書籍 - PDF - - クリップした記事をMyページから読むことができます 　筆者が最近、パスキーに関する記事を多く執筆しているのには、明確な理由がある。世界を代表するテクノロジー企業は近年、数十億人規模のユーザーに対して、ウェブサイトやアプリ、サービスへのサインイン時に、従来のパスワードではなくパスキーを使用するよう促す取り組みに、これまで以上に力を注いでいるからである。 ## パスワードとパスキー 　パスキーは、一般的に「パスワードレス技術」と呼ばれている。従来のパスワードが認証プロセスで機能するためには、ウェブサイトやアプリ、サービス、すなわち「Relying Party（依拠当事者）」が、エンドユーザーのID管理システムにそのパスワードを記録しておく必要がある。ログイン時にユーザーがパスワードを送信すると、依拠当事者はそのパスワードが記録されているものと一致するかどうかを照合することで、本人確認する仕組みである。 　記録されたパスワードが暗号化されているかどうかにかかわらず、認証のプロセス自体は変わらない。つまり、パスワードを用いる場合、ログインを確立する前に、ユーザーは自身の秘密情報を依拠当事者と共有しなければならない。そして、その後もログインのたびに、同じ秘密情報を再び依拠当事者に送信する必要がある。サイバーセキュリティの分野では、パスワードは共有秘密情報として扱われており、誰と共有するかに関係なく、共有された秘密情報は常に高いリスクを伴うものと考えられている。 　かつて大規模かつ深刻な被害をもたらした多くのデータ侵害は、悪意のある攻撃者にパスワードを発見されなければ、そもそも発生しなかった可能性がある。 　対照的に、パスキーも秘密情報を含んでいるが、その情報が依拠当事者と共有されることは一切ない。パスキーはZero Knowledge Authentication（ZKA）の一種であり、この仕組みにおいて依拠当事者はユーザーの秘密情報を全く知ることがない。ユーザーが依拠当事者にサインインする際には、秘密情報そのものを渡すのではなく、その情報を所持していることを証明するだけでよい。 　パスキーの根底にある重要な考え方は、正当な依拠当事者と秘密情報を共有する必要がなければ、フィッシングやスミッシングといった悪意ある攻撃者と誤って秘密情報を共有してしまうことも決して起こらない、という点にある。しかし現実には、多くの人は「ログインするには秘密のパスワードを共有しなければならない」と強く思い込むように、長年にわたって刷り込まれてきた。そのため、パスキーのように秘密情報を共有せずに認証を成立させる仕組みが、どのように機能するのかを直感的に理解するのは、依然として難しいのが現状である。 　では、これは一体どのようにして可能なのだろうか。結局のところ、直感に反するように思える。そして、なぜパスワードよりもはるかに安全なのだろうか。 ## 公開鍵暗号がパスキーの基盤である 　パスキーの仕組みを理解するには、まず公開鍵暗号の基本を押さえておくことが重要である。これは、物理的な鍵が特定の錠にだけ合うように設計されているのと同様に、公開鍵暗号でも2つのデジタル鍵（すなわち公開鍵と秘密鍵）が存在し、それぞれが一対一に対応し、かつ唯一無二の関係にあるという考え方に基づいている。 　公開鍵／秘密鍵ペアが特別である理由は何か。例えば、筆者が所有する秘密鍵に対応する公開鍵をユーザーに渡したとしよう。ユーザーは、その公開鍵を使って筆者宛にメッセージを暗号化できる。そして、その暗号化されたメッセージを筆者に送った場合、筆者が対応する秘密鍵を唯一保持している限り、そのメッセージを復号できるのは筆者だけである。 　公開鍵は、暗号化されたメッセージを復号したり、秘密鍵を導き出したりするためには使用できない。この点こそが、公開鍵暗号技術の根幹を成している。つまり、筆者は自身の公開鍵を、希望するだけ多くの人々に自由に配布可能であり、受け取った人は誰でも、その公開鍵を使って筆者宛に暗号化されたメッセージを送信できる。一方で、筆者が対応する秘密鍵を唯一保持している限り、筆者だけが送られてきたメッセージを復号できる。 　また、筆者は自分の秘密鍵を使ってメッセージにデジタル署名を施せる。これは、そのメッセージを受け取った相手が、対応する公開鍵を使って、そのメッセージが本当に筆者から送られたものであるかどうかを確認できるという仕組みだ。この仕組みは、パスキーにおけるZKAの重要な要素であり、秘密の内容を依拠当事者に明かすことなく、筆者がその秘密鍵を保持していることを証明する手段となっている。 　パスキーとは異なり、パスワードを依拠当事者に対するログイン認証情報として機能させるためには、ユーザーはその秘密のパスワードを依拠当事者と共有するというリスクを負わなければならない（この点については前述の通りである）。しかし、パスキーの場合には、そのようなリスクを一切負う必要がない。 ## 誰もが知っておくべき4つのパスキーワークフロー 　ほとんどのユーザーにとって、留意すべきパスキー関連のプロセス（ワークフロー）は4つある。 1. パスキー機能を提供する依拠当事者の間では、ユーザーがその機能をどのように見つけ、利用するかについての統一された基準が存在していない。そのため、依拠当事者ごとにユーザー体験が異なるだけでなく、同じ機能を指すのに異なる用語が使われることもある 2. パスキーの登録手続きとは、任意の依拠当事者に対して、ウェブサイトやアプリへのサインインに使用するための1つ以上のパスキーを設定するプロセスを指す 3. パスキーベースの認証手続きは、パスキーが依拠当事者に登録された後に行われるものであり、ユーザーがその依拠当事者に対してログインする際に、登録済みのパスキーを用いて認証する方法である 4. パスキー削除プロセスは、不要になったパスキーを整理・削除するための手続きになる - - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235352%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235352%2F&hashtags=ZDNET) ## ZDNET Japan クイックポール 所属する組織のデータ活用状況はどの段階にありますか？ ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。 ITビジネス全般については、 [CNET Japan](https://japan.cnet.com/) をご覧ください。