안녕하세요, 포케누시입니다! (자신 소개는 여기입니다🐈⬛)
모든 여러분, 구글도 최근 대응 방안을 발표했던 웹사이트 인증서 관련 뉴스는 아시나요? 사이트의 신원을 보장하기 위해 사용된 비밀 키가 쉽게 추측할 수 있는 숫자로 만들어져 있다는 문제입니다.
스마트폰이나 PC 의 운영체제, 평소 사용하는 브라우저가 최신 버전으로 업데이트되었는지 확인해 보셨나요? 업데이트를 미루고 계신 분이라면 이번 기회에 꼭 확인해 보세요.
이 사이트에서는 이번 문제와 관련된 인증서가 현재 사용 중인 브라우저가 수용하는지 확인할 수 있습니다. 「이 브라우저로 연결 테스트」를 클릭한 후, 모두 녹색 체크가 표시되는지 확인해 보세요.
브라우저의 체크 사이트 (일본어)
빨간 표시가 표시되는 경우, OS 나 브라우저 업데이트 후 재부팅하고 다시 확인해 보시기 바랍니다. 평소 여러 개의 브라우저를 사용하시는 분은 각각 시도해 보시는 것이 좋습니다.
이번에는 이 뉴스에서 어떤 일이 발생했는지, 그리고 AI 에 업무를 맡길 때에도 관련되는 이유를 설명합니다.
목차
- 평범한 웹 이용을 지탱하는 핵심 요소에 어떤 변화가 있었는지
- 웹사이트를 열 수 있는 주체가 사람만은 아니게 되었습니다.
- 이번에 구현한 허가 후 키 무효화 샘플입니다.
- 실행 측이 책임지는 전후의 차이
- 수취하기 전에 무효 여부를 확인한 경우
- 승인받은 후 효력이 소멸할 경우
- 원본 허가 기록과 실행 결과를 매핑합니다.
- 필요한 기록의 확인과 재평가
- VATE 가 지향하는 것
평범한 웹 이용을 지탱하는 핵심 요소에 어떤 변화가 있었는지
평소에는 아무 생각 없이 웹사이트를 열거나 앱을 통해 통신을 하더라도, 그 뒤에는 다양한 확인 절차와 암호화 기제가 작동하고 있습니다. 문에 잠금 장치를 걸듯 통신 내용을 보호하는 기제도 있고, 통신 상대방이 본인이 맞는지 확인하는 기제도 있습니다.
이번에 문제가 된 것은 후자에 사용되는 키입니다. 웹사이트에는 신분증과 같은 역할을 하는 '인증서'가 있습니다. 해당 인증서를 발행하는 인증 기관은 자신만 사용할 수 있는 비밀 키로 서명을 통해 인증서가 본물인지 확인할 수 있도록 하고 있습니다.
이 비밀키에는 본래 현실적인 시간으로는 추측할 수 있을 만큼 많은 후보에서 선택된 숫자를 사용해야 하지만, eMudhra라는 회사가 운영하는 일부 인증기관에서는 매우 작은 숫자만 사용되었습니다.
그 중 하나인 숫자 '4'입니다. 보안 연구자 스콧 헬메는 공개된 인증서에서 실제 키를 추출해 그 결과를 공개했습니다.
스콧 헬메의 검증 (영어)
이 키를 타인이 사용할 수 있게 하면, 인증 기관이 발급한 것처럼 보이는 위조 인증서를 만들 수 있습니다. 이러한 위조 인증서를 수용하는 소프트웨어에서는 통신 중간에 끼어들어 공격을 수행하고, 실제 사이트가 아닌 가짜 사이트로 위장할 수 있습니다. 사용자가 진짜 사이트라고 믿고 접속했을 때 로그인 정보나 개인 정보를 입력하게 만들어 심각한 보안 위험을 초래할 수 있습니다.
따라서 브라우저나 OS 제공사는 문제가 있는 키나 인증서를 신뢰하지 않도록 대응을 강화하고 있습니다. 구글 또한 10 월 20 일의 보고서에서 크롬과 안드로이드에 대한 대응 방안을 설명했습니다.
구글의 1 차 보고서 (영어판)
Webサイトを開くのは、人だけではなくなった
今は、ChatGPTやGemini、Claudeに調べ物を頼むと、AIが代わりにWebサイトを調べてくれますよね。情報を読むだけでなく、ブラウザを操作して、仕事を進めてくれるAIエージェントもあります。
このときも、AIは外部のサイトやサービスへ接続しています。接続先が本物かを確かめる仕組みに問題があれば、AIも偽の相手に接続してしまう可能性があります。その先で入力や送信まで任せていれば、情報を誤った相手へ渡す危険にもつながります。
AIに任せる仕事が増えるほど、誰を信頼して、どこまで操作を許すかが重要になります。そして今回のように、信頼していた鍵に後から問題が見つかることもあります。
僕は今、AIエージェントの操作に関するプロトコル「VATE」を開発しています。操作を受け入れる側が、何を根拠に許可・制限・拒否したかを記録し、その後の実行結果と結び付けるための仕様案です。
今回のニュースを受けて、VATEでも、信頼の前提が途中で変わる場面を実装して確かめることにしました。扱ったのは、一度許可したAIの操作で、その後に実行環境の鍵が失効したらどうするか、という問題です。
このサンプルを加えたv0.6.0を、10月25日（日本時間）に公開しました。
ここまで読んだ方には、まずOSやブラウザの更新と、冒頭のチェックを確認していただければと思います。今回のように、普段使っている仕組みの根幹に関わる問題も起きています。ニュースやSNSでセキュリティの話題を見かけたら、いつもより少し意識して、利用しているサービスの公式案内と対処方法まで確認しておくとよいと思います。
ここから先は、今回の実装についての技術的な説明です。難しいと感じたら、読み飛ばしてもらって大丈夫です。AIエージェントやサービスを開発している方は、ぜひ続けて読んでみてください。
今回実装した、許可後の鍵失効サンプル
サンプル名は post-admission-revocation-sample です。VATEで出した元の許可（allow）を残し、その後の鍵の状態、実行側の引き受け判断、実際の結果を対応付けます。
対象にしたのは、エージェントの実行環境を示す鍵です。鍵の状態を署名して知らせる発行者を一つ、操作を引き受ける実行サービスを一つ用意しています。操作は demo.create_file_set、二つのテキストファイルを作る処理です。試験用の鍵と固定した時計を使い、一つのローカル環境で検証します。
実行要求のたびに、実行側は指定されたローカルの状態ファイルを読み直します。前の要求で有効だったことや、変更通知を受け取ったことだけで、この確認を済ませた扱いにはしません。
その上で、二つの署名を検証します。一つは状態発行者による鍵の状態の署名。もう一つは、実行環境による実行要求の証明です。後者には、宛先、操作、入力データ、元の許可、試行ID、一度限りの識別値（nonce）、有効期間を結び付けています。別の操作や宛先に証明を流用させないためです。
署名を確かめた後、データベースの書き込みロックを取得し、その時点の checked_at で有効期間を確認します。署名の検証やロック待ちに時間がかかった場合も、待つ前の時刻の判定を使い続けないようにしています。
実行側が引き受ける前と後の違い
ここで分けているのが、VATEの判定で「操作を許可したこと」と、実行側が「仕事を引き受けたこと」です。許可の記録を受け取っても、そのままファイルを作り始めるのではなく、実行側が鍵の状態などを確認してから、処理を引き受けるかを決めます。
鍵の状態更新と引き受け判断は、同じSQLiteデータベースで管理します。失効と引き受けのどちらが先に確定したかで、新たな引き受けを認めるかが決まります。
失効のタイミングを変えた二つのケースで、結果を比較しました。
引き受ける前に、失効を確認した場合
操作を許可した後、実行側が引き受ける前に、鍵の失効を確認します。この場合は引き受けを拒否し、作られたファイルは0件でした。
最初の許可記録は残ります。その上で、「後の状態確認によって、実行側は引き受けなかった」という別の結果が記録されます。
引き受けた後で、失効した場合
もう一つは、鍵が有効な状態で実行側が仕事を引き受け、その後、ファイルを作る前に鍵が失効するケースです。
このサンプルでは、引き受けた処理は続き、二つのファイルが作られました。 後から失効したことだけで、引き受け済みの操作を取り消す仕組みにはしていません。
失効したという情報と、仕事が止まったという事実は別です。引き受けた仕事をどこまで止められるかは、実行するサービス側で決め、実装する必要があります。
また、データベースでの引き受け確定と、二つのファイルへの書き込みは別々の処理です。引き受けが確定しても、ファイルの作成まで一括で成功することを保証するものではありません。この違いは、途中で処理が止まった場合の扱いにも関わります。
元の許可記録と実行結果を対応付ける
このサンプルでは、実行を止めたかどうかだけでなく、許可から結果までの経緯を確認できるようにしています。
後から分かった状態に合わせて最初の許可記録を書き換えると、当時どのような判断をしたのかが見えなくなります。また、失効したことを理由に「実行されなかった」と扱うと、実際に作られたファイルと記録が食い違います。
そこで、元の許可記録を残したまま、後の鍵の状態、引き受けの判断、実行側が観測した結果を結び付けるようにしています。
書き出した記録は、別の読み取り用プログラム（reader）でも検査できます。確認する側が独立に指定した鍵や操作の情報と、対象の保存先を識別する情報を使い、署名、元の入力、イベントの順序、結果の対応を照合します。受け取った記録に書いてある鍵を、そのまま信頼の根拠にする構成にはしていません。
なお、このサンプルの元の allow は、同梱のVATEモジュールで再計算して確かめる無署名の記録です。後から付く鍵の状態や実行要求の署名が、元の allow 自体の署名になるわけではありません。
結果には、主に次の三つの状態を使います。
- not_accepted：引き受けておらず、実行結果やファイルも観測されていない。
- effect_observed：引き受け記録、対応する完了記録、期待する二つのファイルがそろっている。
- unknown：上のどちらとも確定できない。
一つ目のファイルを作った後で、意図的に処理を中断させるケースも試しました。ファイル1件は確認できても、操作全体の完了記録はありません。そこで、作られた一件の記録を残し、全体の結果は unknown としています。全部成功したことにも、何も起きなかったことにもせず、確認できた範囲を残すためです。
応答を受け取れなかった場合の復旧では、query で保存済みの状態を確認します。結果が分からないからと同じ処理をもう一度走らせることはしません。二重実行を避けながら、分かることを増やす経路です。
readerが確認するのは、実行側が書き出した観測記録の整合性です。reader自身が実行先のファイルを直接観測したり、悪意のある実行側が履歴を隠していないことまで証明したりするものではありません。離れたサービスへの失効情報の伝達や、引き受け後の取消処理も、今回のローカルサンプルには含めていません。
詳しい入力・署名・判定順序は、公開しているサンプルの契約文書にまとめています。
必要な記録の確認と再評価
v0.6.0では、鍵失効のサンプルに加えて、記録を受け取る側の仕組みも進めました。必要な記録を点検する Required Record Review と、原本や評価履歴を保存する Recipient Inbox です。
受け取った資料だけを確認していると、そもそも届いていない記録が、確認の対象から抜けてしまうことがあります。
例えば、ある操作について実行結果の記録が必要なのに、それが提出されていない。届いた他の資料に問題がなかったとしても、それだけでは、その操作を確認し終えたことにはなりません。
今回の仕組みでは、受け取る側が、対象の操作と必要な記録を先に決めます。その条件と照らし合わせることで、「必要な記録が欠けている」という状態も評価に残せます。
後から資料が届いた場合には、保存した原本を使って再評価できます。以前の評価も残るので、最初は何が分からず、その後どの資料や条件で判断が変わったのかを追えるようになります。
鍵が失効することと、足りなかった資料が届くことでは、起こっている変化は違います。それでも、以前の判断と、その後に分かったことをつなげて確かめるという課題は共通しています。
今回、鍵失効のサンプルで確認した経路は、実行側のデータベースと記録の書き出しまでです。このサンプルからRecipient Inboxへ記録を取り込む処理は、まだ含めていません。
VATEで目指していること
AIに仕事を任せる場面では、自分が使うエージェントと、仕事を受けるサービスが、同じ会社の仕組みとは限りません。確認に使う鍵も、判断の条件も、それぞれ異なります。
そのとき、一方のサービスが「許可しました」「完了しました」と表示するだけでは、別の当事者が経緯を確かめる材料として足りない場面があります。
僕がVATEで目指しているのは、操作を認めた根拠と実際の結果を、異なるシステムの間でも確認できる共通の規則と記録の形式です。前回の開発記で書いた、サービスや組織をまたぐ代理行動の構想にもつながっています。
支払い、データの更新、ファイルの受け渡しでは、実行する処理や確認すべき条件が異なります。それぞれの用途で検証しながら、他の開発者も参照し、利用できる形にしていきたいと考えています。
v0.6.0は、議論と検証のための公開ドラフトです。今回は、許可後に条件が変わる場面を動かし、元の判断から実際の結果まで、記録をたどれる形にしました。
実際に動かして確認したい方は、GitHubのv0.6.0リリースからソースと手順を取得できます。今回の版は、後から同じ内容を参照できるようZenodoにも保存しています。
それではまた、ポケットから🐈⬛
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 검수
원문 보기 | 출처: note.com