リアル仮想通貨ファン

[13:02:55] ふぅ
[13:04:44] 誰もいないか…
[13:05:07] ま、いっか…
[13:05:18] これから出かけないとだし
[14:38:24] error
[14:38:44] ただいま
[14:38:51] おでかけ思念体かわいいｗ
[20:44:04] なおがいる
[20:44:14] これは夢…か…
[20:45:05] きのせいか
[21:51:26] 相変わらずだなぁ…
[21:52:43] Passkey ね
[21:53:03] bitFlyer が Passkey に対応していないてん、もうずっと文句言っているんだけどな
[21:53:44] X でも加納氏のポストや、bitFlyer 公式のポストに対して言及する形で文句を言っているんだが無視されるｗ
[21:54:24] あれは公開鍵暗号法を用いているので基本的には情報が回っているとかいう話じゃない
[21:54:52] 暗号資産のハードウェアウォレットなんかが、BT や NFC で Passkey にもなるよ
[21:55:15] Passkey と一口に言っても方式がいくつかあるので
[21:55:49] ハードウェアウォレットなどを用いる方式と、Google や Apple のキーリングを用いるプラットフォーム型のパスキーでは微妙に実装が異なる
[21:56:31] パスキーは、認証のたびに暗号署名を使って認証しているんよね
[21:57:31] 特に、Apple 製の端末には SecureEnclave が FaceID / TouchID などの生体認証デバ​イスがあり
[21:58:00] それらが連携して、OS すら制御できない領域で暗号署名を作り出すセキュリティサンドボックスがある
[21:58:23] まぁ、ようするにハードウェアウォレットみたいなものが端末に内蔵されていると考えて良い
[21:59:04] そのハードウェアウォレットのロックを解除するためには、OS やアプリケーションからのコマンドではなんともできない独立した環境で署名され
[21:59:23] 生体認証の可否によって、暗号署名が作出される
[22:00:00] だから、FIDO の規格でも明示的にフォールバ​ック手段として必ず PIN を使うこととされている
[22:00:25] だから、顔認証も指紋認証も通らなくても PIN の入力でもって署名はできる
[22:01:00] ただ、PIN の入力に関してはディスプレイに表示する必要性と、タッチスクリーンの読み取りを必要とし
[22:01:10] 通常であれば、OS の管轄
[22:01:28] ディスプレイドライバや、タッチスクリーンドライバに不正なコードを仕込めば
[22:01:38] PIN が抜かれる可能性を否定できない
[22:02:02] だから、通常 SecureEnclave がこの際 OS からタッチスクリーンの制御を奪い
[22:02:31] 特殊なモードに移行し、OS からもドライバからも情報が抜かれないように PIN の認証を行っていると考えられる
[22:03:14] Windows にも同様の機構が、Intel の第８世代移行のCPUには搭載されているが
[22:03:30] 実際に有効にされているかどうかは、端末による
[22:03:46] GPS データは偽造できるんだよね
[22:05:02] いや、そのコードが動作できないようにするためのセキュリティ機構が SecureEnclave で
[22:05:18] SecureEnclave は CPU の介入を受けない
[22:05:31] 認証は、完全に OS からもアプリケーションからも独立して行われるので
[22:05:52] 不正なマルウェアに感染しても認証を突破できないとされている
[22:06:45] CPU のマイクロコードを書き換えても突破できない
[22:07:10] AppleID だけ分かってもだめだし
[22:07:45] Android にも同様のセキュリティ機構はありますね
[22:08:50] いや、できない
[22:09:06] SecureEnclave などのセキュアエレメントチップは、内部で秘密鍵を生成し
[22:09:13] 公開鍵だけしか取り出せず
[22:09:24] 署名はすべて、そのセキュリティサブシステム内で行われ
[22:09:32] PIN の入力や生体認証により保護されている
[22:09:42] したがって、実在する人物によるインタラクションをなくして
[22:09:46] 署名を行うことはできない
[22:10:32] Amazon でパスキーを使う場合、Amazon には公開鍵が登録されているのね
[22:10:58] そうして、Amazon は認証するときにランダムな nonce と言われる値をユーザーに送って
[22:11:33] できない
[22:12:24] ユーザーの端末上の SecureEnclave 内に閉じ込められている秘密鍵を用いて、そのセキュリティ機構の内部で顔認証や指紋認証をしたうえで正規の人間だとわかれば、秘密鍵を用いて nonce に署名して Amazon にわたす
[22:12:51] うどんこさんの話にもコメントしたいけど
[22:13:15] 日本のみちびきという衛生には、GPS 信号偽装対策として署名が入っている情報をおくるチャネルがあって
[22:13:22] スマホは対応していないけど
[22:14:01] 政府の署名付きの GPS 位置座標を提示することでそこに実際にそこにいたことを部分的には証明加納
[22:14:42] ただし、政府の署名付きの GPS 座標を受け取った誰かが何らかの手段でデータを配信しその座標を他のユーザーも自身の GPS 端末の情報だと偽ってアプリに報告することは妨げることができない
[22:15:19] そもそも、その署名付きの GPS 座標を受信するには特別な装備が必要なので
[22:15:29] 民間でこれを活用するのは難しいと思われる
[22:15:57] ポケベルとかの世代は、3G よりも前の 2G 以前の信号で
[22:16:17] これはすでに暗号突破されていて脆弱
[22:16:42] まぁ、でもうどんこさんが言いたいことは分かるよ
[22:16:49] 実際、そういう研究をしているひとはいて
[22:17:26] 客観的に明らかな形で不正のできない GPS 位置座標と、そこに実在する人物がいたという存在証明を作る方法については
[22:17:54] 無理ではないと思うよ
[22:18:18] 話を戻して、rarara さんの質問に答えると
[22:18:44] スマホの画面ロックを設定しなくても Passkey は都度顔認証やPINによる認証があるので大丈夫
[22:19:19] あと、はなしがややこしくなるのであえて言ってないのだけど
[22:20:05] Google パスワードマネージャーや、Apple のキーリングなどを用いて Passkey というのは同期されているのよね
[22:20:45] これには、KeyEncryptionKey という、これまた SecureEnclave 内で生成される鍵により保護される仕組みがあり、E2E エンドツーエンド暗号が施されているので
[22:20:57] Google や Apple がこの鍵を解読はできないとされている
[22:21:40] パスキーとパスワードマネージャーを使うのは違う
[22:22:05] なぜ、Passkey が認証の際にサービス提供者から送られてくるランダムな nonce に署名しているのかを考えれば分かる
[22:22:28] 署名が盗まれたら、何度でもリプレイ攻撃ができてしまうのではまずいでしょ
[22:22:35] パスワードは一度漏洩したら
[22:22:40] 何度でもログイン仕放題
[22:22:57] それが、自分自身かもうひとりのあなたかは客観的に明らかにするのが難しい
[22:23:37] そう、ハードウェアの所有と生体情報やPINなどの記憶の連続性により
[22:23:47] 自己同一性を保障し、個人を認証
[22:24:17] root 権限を奪取してフルバ​ックアップをとっても、SecureEnclave の内容はバッ​クアップされません
[22:24:30] ただし、正規の手続きで Apple 端末同士を移行する場合
[22:24:51] 名前わすれたけど、あのパーティクルをカメラで読み取って端末のデータを移行する場合
[22:25:03] ２つの端末の間で信頼できる暗号通信チャネルを用いて
[22:25:13] 機密情報を移行することはできるし
[22:25:52] 同様の移行手順を Google 等も提供しているとは思うよ
[22:26:25] 鍵はクラウドにはない
[22:26:33] SecureEnclave 内にのみあり
[22:26:50] AppleID とは暗号署名を通じて信頼の輪を構成していて
[22:27:07] 信頼できる端末間では、機密情報を交換することができ
[22:27:13] それが、Apple のキーチェーンであり
[22:27:34] 信頼できる物理端末すべてを破壊したら
[22:27:45] Apple であったとしても、復元できない
[22:27:54] そうその理解であってる
[22:28:09] ただ、厳密な話をすると
[22:28:21] 持ってる
[22:28:23] SecureEnclave にあるのはマスターキーだけで
[22:29:06] Google パスワードマネージャーや、Apple のキーチェーンに保管されてア​カウントに紐づけられるタイプの Passkey は
[22:29:28] 秘密鍵を、SecureEnclave のマスターキーで暗号化した形ではあるけどクラウドに持ってる
[22:29:48] まぁ、うどんこさんのいうことはもっとも
[22:30:04] Passkey を過信するのはよくない
[22:30:33] マスターキーはCPU（より正確にはSecureEnclave）内だね
[22:30:44] 一部のキーは暗号化されてクラウドにあるというのもまた事実
[22:31:13] その暗号化された秘密鍵のマスターキーがSecureEnclave内にある
[22:31:33] ただ、このSecureEnclaveに関してはブラックボックスとなっているので
[22:31:45] 米国政府やAppleが本当に介入できないかは分からない
[22:32:16] まぁ、Passkey を使っておけば
[22:32:23] パスワードによる認証よりははるかに安全
[22:32:42] Google Authenticator などを使うよりも利便性も高く、セキュアであるのは間違いない
[22:32:53] それはそう
[22:33:23] でも、先程も述べたように Apple のキーチェーンや、Google パスワードマネージャーを通して信頼の輪を構築した信頼できる端末には鍵が同期されている
[22:33:46] エンドツーエンドで暗号化が施された安全な通信経路を用いて、生の秘密鍵を露出することなく
[22:34:23] このチャットは暗号資産の交換所だから、いまさら説明するまでもないとは思うけど
[22:35:03] 公開鍵暗号法は、秘密鍵からは公開鍵を導出できるがその逆は現実的に不可能
[22:35:22] 秘密鍵で暗号化したデータは、公開鍵を用いて復号可能で
[22:35:37] 公開鍵を用いて暗号化したデータは秘密鍵を用いて解読可能
[22:35:57] 秘密鍵を露出しないという前提において
[22:36:19] 任意の nonce を秘密鍵を用いて暗号化すれば、公開鍵を用いて検証は容易
[22:36:23] これが認証の仕組み
[22:36:40] スマホを壊すといろいろ面倒にはなるだろうね
[22:37:07] パスキー自体はスマホだけではないよ
[22:37:16] macOS にも SecurEnclave 搭載されていて
[22:37:20] TouchID がついている
[22:37:30] PC でもできるし
[22:37:54] 先ほども述べたように Passkey の端末は USB 接続で使える物理キーもあるし
[22:38:04] Bluetooth や NFC でも Passkey できる
[22:38:19] 実際、iOS では SecureEnclave あるからそっち使った方が楽だけど
[22:38:29] NFC でタッチするだけで物理キーを使って認証できるよ
[22:38:40] 物理キーを破壊したら同じことではあるけど
[22:38:54] 一部の暗号資産ウォレットには、この鍵をニーモニックフレーズから導出する方式がある
[22:39:36] ICカードキーもセキュアエレメント搭載していることが多いね
[22:39:41] その意味では同じような理屈
[22:40:11] いや、それは違う
[22:40:19] Suica は Felica 規格で
[22:40:33] NFC Type-F だけど
[22:40:49] 一般的には、IC カードの IDm を用いて識別しているだけであれは認証とは言えない
[22:40:56] IDm は簡単に偽造できる
[22:41:05] コピーが簡単につくれる
[22:41:23] だから、セキュアエレメントを持っていてその内部で署名できる必要がある
[22:41:57] また、PIN や生体認証でユーザーの意思をユーザーインタラクションとして明示的に示さなければ
[22:42:16] カードを盗まれたら、カードの所有という一要素での認証になるので多要素認証の要件を満たさない
[22:42:54] これくらいは、暗号資産やっている人は当然しっているよねｗ
[22:45:46] 銀行のトークンも、セキュアエレメント搭載のOTPだね
[22:45:56] ただ、あれはユーザーのインタラクションを要求しないんだよね
[22:46:08] PINの入力も、生体認証もない
[22:46:25] だから、あれ自体多要素認証の一つの要素にはなるけど単独では使えない
[22:46:55] Amazon にログインするときに、パスキーを求められる場合 FaceID みたいな顔認証が立ち上がるよ
[22:47:18] 多要素認証自体は、Passkey も多要素認証だしセキュリティの常識だよ
[22:47:46] 端末の所有がひとつの要素を構成していて、PINを知っているという記憶の連続性や、顔認証や指紋認証などの生体認証も一つの要素
[22:48:14] rarara さんが懸念しているのは通信経路上に、中間者がいる場合のことを想定しているのだろうけど
[22:48:28] その心配はいらない、なぜなら認証方式が公開鍵暗号法に基づいているからで
[22:48:59] また、そうでなくても現在ではほぼすべての Web サイトは SSL/TLS によるエンドツーエンドの暗号化された信頼できるチャネル内で通信していて
[22:49:18] 少なくとも、Amazon と rarara さんの端末の間の通信に介入することはできない
[22:49:36] ただし、rarara さんの端末に不正なルート証明書が組み込まれている場合はその限りではないけど
[22:49:45] 仮に経路上に中間者がいたとしても
[22:49:56] Passkey による署名はワンタイムのものであり
[22:50:08] これを不正に再利用して、リプレイ攻撃をすることはできない
[22:50:38] また、Passkey による署名をなくしてユーザーの意思に反して不正な署名を作出するのは計算量の観点から言って現実的ではない
[22:50:46] そんな計算パワーがあるなら、BTC マイニングしたほうが儲かる
[22:51:42] 突っつくというか、認証を要求するときは WebAuthn という W3C が定めた WEB 標準の手続きに従って JavaScript の API を通じて要求する
[22:52:15] 顔認証→Passkeyによる秘密鍵を用いた暗号署名の一連の流れは、全て SecureEnclave によって行われ
[22:52:20] OS に介入する余地はない
[22:52:38] ただし、SecureEnclave のファームウェアに悪意あるコードが混入する可能性は完全には否定できないが
[22:52:51] この SecureEnclave 自体、Apple による署名されたコードしか動作しないようになっている
[22:53:47] Apple が政府に強力してバ​ックドアを作る可能性とか、政府による陰謀論なら明確な証拠はないが可能性を完全否定できない
[22:54:17] いずれにしても、完璧なセキュリティというのは存在しない
[22:54:27] セキュリティと利便性はトレードオフであることが常だけど
[22:54:39] Passkey に限っていえば、利便性もセキュリティも向上できるので
[22:55:04] これが仮に完璧でないとしても、パスワード認証やその他の認証手段よりは遥かにセキュア
[22:55:27] Amazon には最初に SecureEnclave の公開鍵を登録しないと当然ログインできないね
[22:56:21] ピコピコなるというか、通常であれば Passkey の認証として FaceID や TouchID などの生体認証画面が表示されるので
[22:56:34] 実質的にはユーザー体験的には、指紋認証でログインしているみたいな感じ
[22:57:37] そういうこと
[22:58:12] ランダムな nonce に署名でき、事前に登録した公開鍵で復号できる署名を作出可能なのは秘密鍵を知るものだけだから
[22:58:31] そう、それも秘密鍵がユーザー自身も知らないところで管理されていて
[22:58:48] 暗号資産のニーモニックフレーズのように管理に厳重な注意を払う必要がなく
[22:58:55] ハードウェアを破壊しないように気をつけるだけｗ
[22:59:03] 電話番号ではない
[22:59:22] JavaScript を通じて WebAuthn という WEB 標準のインターフェイスで
[22:59:52] 私は、抽象的な説明でお茶を濁すのが嫌いだから難しい説明になっているけど
[22:59:56] そこまで難しくはないよ
[23:00:08] いや、Amazon を監視しているとかはないｗ
[23:01:04] 公開鍵暗号法を理解しているならすごい簡単な話ではあるんだけどね
[23:01:33] nonce というランダムな値を送ってこれに署名してみてって言ってくる
[23:02:27] すると、ユーザーに変わってブラウザ（ユーザーエージェント）が SecurEnclave に働きかえて生体認証画面が表示され、生体認証が成功した場合に自動的に SecureEnclave 内で秘密鍵を用いて署名をしたデータが得られる
[23:03:06] これをブラウザが Amazon に提出すると、Amazon は事前に登録された公開鍵を用いてこれを検証（暗号解読）すると、事前に与えた nonce と一致するということを持って認証ができる
[23:03:23] ランダムな nonce を用いるのは、リプレイ攻撃を防ぐためだ
[23:04:06] 連絡の仕方というか、ホームページ作ったことあるひとなら分かるんだけどね
[23:04:13] window.alert("こんにちわ");
[23:04:28] って表示すると、「こんにちわ」ってダイアログが開くでしょ
[23:04:54] その容量で、実際には違うけど window.authenticateByPasskey(nonce);
[23:05:04] みたいにしたら、認証用の画面が開くと思えば良い
[23:05:27] nonce は SecureEnclave に対して送る
[23:05:37] 署名する対象は何でもいいんだけどね
[23:05:48] ただ、第三者に推測されてはいけないのでランダムにするだけ
[23:06:06] 秘密鍵で暗号化したデータは公開鍵でのみ暗号解読ができるの
[23:06:16] Amazon は秘密鍵は持っていないけど、公開鍵を持っている
[23:06:29] 通信経路が暗号化されていなくても大丈夫なんだけどね
[23:06:44] なぜなら、nonce に対する署名は秘密鍵で暗号化されているので
[23:06:52] 公開鍵を用いて解読することはできるけど
[23:06:59] そう
[23:07:09] 毎回違うというのは、nonce がランダムだから
[23:07:22] 連絡する手段も何もないよ
[23:07:33] 識別するための ID は別になんでもいい
[23:08:15] 通信経路という意味での連絡手段なら HTTP プロトコルを用いたインターネット回線だけど
[23:08:23] ID として電話番号が使用される例はあるかもね
[23:08:32] ID としてメールアドレスを採用するサービスが多いけど
[23:08:38] メールアドレスでさえなくてもいい
[23:08:46] ID が何かは重要ではない
[23:12:14] 二段階認証のメールで送られてきたりはしません
[23:12:25] 画面を通じてというのは語弊があるけど
[23:12:38] ブラウザの API を通じて直接認証要求が伝えられます
[23:12:56] つまり、Amazon がブラウザを通じて SecureEnclave で認証するように API を投げる
[23:13:24] ログインフォームに ID を入力して、Passkey で認証みたいなボタンを押したら
[23:13:31] 生体認証が表示されてログイン完了
[23:13:33] みたいな感じ
[23:13:45] 実際に使ってみるのが手っ取り早いね、Yahoo とかも対応しているし
[23:14:14] 常にではなく、ログインボタンを押した瞬間に
[23:14:22] その一連のやりとりが一瞬で
[23:16:03] ブラウザは常に、API を通じて認証できる状態にあるよ
[23:16:08] ブラウザアプリが起動している限り
[23:16:18] ただ、常に Amazon などのサービスサイトと通信しているわけではない
[23:16:25] ログインボタンを押したその一瞬だけ
[23:16:57] というか認証するだけだから、署名を提出すればよいだけだし
[23:17:03] そんなに高頻度で通信する必要がない
[23:17:26] 一度認証が通ったら、セッションが確立されて
[23:17:37] これはセッションキーと呼ばれるけど、Cookie などを用いて保持される
[23:17:48] これは、ID/Password による認証後のフローと同じ
[23:18:09] Passkey が変えているのは、ID/Password による認証のその部分だけ
[23:18:24] セッションキーが盗まれたらセッションハイジャックに合う可能性はあるし
[23:18:35] だから、Passkey それ自体が暗号化された通信チャネルを必要しないとしても
[23:18:41] SSL/TLS による暗号化は必須だ
[23:20:25] あまりこういう抽象的な表現は好きじゃないんだけどね
[23:20:37] ランダムに生成された絵を Amazon が送ってくるじゃない
[23:21:02] それに、rarara さんだけが持っている実印を押印して
[23:21:18] 提出するみたいな感じ
[23:21:58] スマホが監視しているとかではなく
[23:22:05] 対話的に手順を踏んでいる感じ
[23:22:50] 連絡手段は HTTP プロトコルを通じたインターネット回線だってｗ
[23:23:22] スマホでホームページを開いているなら、Wi-Fi や 5G などの回線を通じてということになる
[23:24:10] ログインページを開いて、パスキーでログインボタンを押すと署名するためのランダムな nonce が Amazon からダウンロードされる
[23:25:02] PC でログインする場合は普通は PC 内の SecureElement で署名するよ
[23:25:13] ただ、その時 Google ア​カウントを用いるなら
[23:25:30] その端末は事前に、スマホと同じ信頼できる端末として信頼の輪の中に入っている必要がある
[23:26:01] その上で、SecureElement により生成される秘密鍵を用いて KeyEncryptionKey を用いて鍵は安全に同期される
[23:26:15] したがって、スマホも PC も実質的に同じキーでログインできる
[23:26:36] ただ、一部例外的にブラウザの実装で QR コードを用いて Passkey の認証をスマホで行うようにすることはできる
[23:26:51] カメラで QR コードを読み取って、スマホの SecureElement で認証
[23:27:32] 同期されるキーは暗号化されているので、Google さえ知り得ない
[23:27:49] ２つのデバ​イスにまったく同じ秘密鍵が入っているように振る舞うけども
[23:28:09] 生の秘密鍵はいっさい露出しない
[23:28:23] SecureEnclave の外に生の鍵がでることはない
[23:28:40] まぁ、これには注意書きが必要だけど
[23:28:44] 特に Windows の場合
[23:28:59] Intel の第８世代未満のCPUではこの前提が崩れる可能性はある
[23:29:06] TPM が搭載されていないから
[23:29:13] あるいはオプションであったから
[23:29:34] Windows11 がプリインストールされたPCであるならばこの問題はないと考えても良い
[23:29:44] なぜなら、Windows11 のセキュリティ要件だから
[23:30:41] rarara さんは二要素認証が何らかの別の通信チャネルを用いてなされるものと思い込んでいるようだけど
[23:30:52] 二要素認証ってそういう意味ではないんだよ
[23:31:17] 物理的な所有とPINによる認証という意味なら、ATM におけるキャッシュカードの認証も多要素認証だし
[23:31:57] だから、スマホやPCなどのSecureElement搭載端末の所有がすでに認証の１要素になっていて
[23:32:08] PIN や生体認証で二要素を構成する
[23:32:26] だから、パスワードを入力しなくても生体認証だけでログインできるみたいな感覚にはなるけど
[23:32:34] パスワード認証よりセキュアなんだ
[23:33:08] PCは、PCでスマホと同じ Google ア​カウントを用いていれば
[23:33:14] Google パスワードマネージャーを通じて
[23:33:21] 信頼の輪が構成されるから
[23:33:33] SecureElement 間で秘密鍵を同期しているに等しい
[23:33:49] だから、PC もスマホも rarara さんの所有する端末という事前の信頼に基づいて
[23:34:05] PC なら PC の SecureElement で
[23:34:18] スマホならスマホの SecureElement で認証する
[23:34:34] 例外的に QR コードを用いて、PC での二要素認証をスマホですることもできなくはない
[23:34:55] スマホが鍵ではない
[23:35:13] Google パスワードマネージャーにパスキーが暗号化されてある
[23:35:34] というか、実質的には鍵を露出せずに鍵を同期している
[23:35:55] いや、PC にセキュアエレメントを搭載していれば
[23:36:03] 危ういということはないんだよ
[23:36:29] まぁ、でも Passkey はすこしややこしいね
[23:36:42] Google パスワードマネージャーで同期するか、Apple のキーチェーンで同期するか
[23:36:55] はたまた、同期せずに文字通り SecureElement 内にだけ鍵をとどめておくか
[23:37:00] ユーザーは選択可能だから
[23:37:10] Google も　Apple も信頼ならんというなら
[23:37:32] 同期せずに、端末の SecureElement だけを信じることはできる
[23:38:23] 事前にパスワード認証や、ユーザー登録の際に提出した公開鍵に対応する秘密鍵の正当な持ち主ということを証明できるけど
[23:38:36] 本物の KITAC さんですというのは自分自身にしか分からんねｗ
[23:38:46] 自己同一性を客観的に明らかに証明することは難しい
[23:39:30] S​MS認証は、端末の契約者した人しか受け取れないはずの電話回線を通じたメッセージだから
[23:39:49] SIMスワップや、最近流行っている偽基地局を用いた電波妨害を通じて
[23:40:08] 5G/4G を無効化したうえで、2G GS​M の下位互換性を通じて 
[23:40:16] ニセのメッセージを送りつけることはできる
[23:40:34] だから、S​MS認証は安全とは言い切れなくなって
[23:40:37] Googleはやめたね
[23:42:08] 私は、なにも悪いことはしていないよｗ
[23:42:54] Passkey の普及には私が思っている以上にハードルは高いのかもしれない
[23:43:50] まぁ、スマホのサポートしている人が言ってたけど端末購入してから一度も電源切ったことがなくて顔認証や指紋認証で普段ロック解除しているからPIN知らんって人もいるらしいし
[23:44:03] 便利になったらなってで、別の問題に遭遇する可能性はあるよね
[23:44:34] 最近では、そういった人に対してサポートしてられないからってそういう状況に遭遇したら誓約書を書かせてからでないと再起動を実行しないらしい
[23:44:49] 再起動したら最後、二度と入れなくなる可能性があるｗ
[23:45:08] そうだね
[23:45:51] sha256 のようなハッシュ関数を用いていて
[23:46:32] 正確にはバ​イト列だけど、人間に視認可能なように Base32 などの視認可能な文字にエンコードされていると思うので文字列といって差し支えないかと
[23:47:35] KITAC さんはたぶん大丈夫そうだね
[23:48:37] 私があまりに専門的な説明してしまったために、rarara さんが混乱していないかが心配だ
[23:50:01] 少しややこしくしてしまったかな
[23:50:24] ハッシュ関数を使うのは、任意の長さの文字やバ​イト列をハッシュ関数に通すと
[23:50:39] 擬似ランダムな 256bit 固定長のデータが得られる
[23:51:03] この 256bit のデータに対して、秘密鍵を用いて暗号化をすると
[23:51:22] 公開鍵を知っている Amazon はこれを解読できる
[23:51:32] これはハッシュ関数を通した値だけど
[23:51:42] 既知のハッシュ関数でこれは Amazon も SHA256 だと知っているから
[23:51:52] SHA256(nonce) を計算した結果と
[23:52:01] 公開鍵により復号したデータが一致すれば認証完了
[23:52:48] SHA256 を使うのは、署名対象のデータの大きさによらず常に長さが 256bit になるから
[23:53:06] nonce だけは渡すけど、そうだね
[23:53:14] nonce に署名してくれって言うだけ
[23:53:28] 暗号通貨の場合はトランザクションに署名するけどね
[23:53:48] トランザクションのデータは大きさが可変なのでハッシュ関数に通して常に 256bit になるようにする
[23:54:11] トランザクションを秘密鍵で暗号化しても、公開鍵を用いてトランザクションを復元できるけど
[23:54:18] データサイズが大きいと比較がめんどい
[23:54:39] 256bit 固定長だと、比較検証が予測可能な時間内に収まる
[23:54:54] 通信に要する帯域の節約にもなるしね
[23:55:46] 秘密鍵は SecureElement で事前に生成されたもので毎回つくるわけではないけど
[23:55:49] 流れはその通り
[23:55:56] nonceが毎回異なるので
[23:56:05] 署名結果も毎回異なる
[23:56:09] だから、リプレイ攻撃を防げる
[23:56:32] なので、ハッシュ関数自体はあまり重要ではないね
[23:56:42] Amazon と、端末側が同じアルゴリズムを使用していればいい
[23:57:48] セキュリティ意識が高まるのはいいことだ
[23:58:01] しかし、bitFlyer は早急に Passkey に対応しろよなｗ
[23:59:58] おやすみなさい