IEEE 1735の要件を満たす（そしてそれを超える！）方法

先月、Workdayのシニアリクルーターを名乗る人物から採用メールを受け取りました。

洗練されていて、パーソナライズされていて、誤字脱字もなく、件名には私の名前が入っているので、あらゆるメールフィルターを回避できます。

返信しませんでした。送信者のドメインを確認しました: `採用情報 - workday.co`.

いいえworkday.com`. DNSレコードはメールが`を経由してルーティングされていることを示していましたemx.mail.ru`. 生の SMTP ヘッダーは、発信元が ` であることを確認しました。send35.i.mail.ru [89.221.237.130]、ロシアのリレー、モスクワ時間午前1時23分。DKIMセレクタ：`mailru`。DMARCポリシー：`p=NONE`。Cloudflareプロキシ、すべてのレコードのTTLはゼロ。配信して消えるように設計された専用インフラストラクチャ。

その文章は恐らくAIによって生成されたものだろう。なぜなら、私のプロフィールを実際に読んだ採用担当者なら、そこから何か名前を挙げるはずだからだ。しかし実際には、LinkedInの4つのデータポイント（名前、役職、業界、所在地）がプロンプトテンプレートに入力され、数千人ものターゲットに同時に適用された。パーソナライゼーションこそが攻撃対象であり、そのインフラストラクチャこそがそれを物語っている。

多くの場合、システムは実際の攻撃者を想定して設計されていません。LinkedInのプロフィールは、人間の採用担当者が手動でアプローチして閲覧することを想定して作られました。しかし現在、攻撃者はAIを使って公開データを武器となる信頼へと変換し、自動化されたパイプラインを大規模に実行しています。システムが想定する攻撃者と実際に悪用する攻撃者との間のこのギャップは、ソーシャルプラットフォームに限ったことではありません。これは、あらゆる分野のセキュリティシステムにおける決定的な失敗モードです。

このことから、私はIEEE P1735（電子設計知的財産の暗号化と管理に関する推奨実施基準）によって確立された前例について考えさせられました。これは、半導体サプライチェーンにおけるVerilog/VHDLのHDLコードなどのハードウェア設計IPを保護するために開発された標準規格です。

2017年、Chotaray、Nahiyan、Shrimpton、Forte、およびTehranpoorは「Standardizing Bad Cryptographic Practice」を発表し、IEEE 1735-2014を解体した。2021年のSpeith、Schweins、Ender、Fyrbiack、May、およびPaarによる論文では、Intel、Cadence、Siemens、Latticeなどの本番環境における実装から完全な秘密鍵復元が可能であることが実証された。

標準規格では、RSA鍵転送方式を用いたAES-CBCが採用されていた。暗号化方式自体が弱点だったのではなく、むしろ脅威モデルに問題があったと言えるだろう。P1735では、EDAツールが信頼できるものとして指定されていた。攻撃者は、保護されたファイルを静止状態で読み取ろうとする受動的なIPユーザーとしてモデル化されていた。実行環境を制御し、ツールに細工された暗号文を入力し、エラー出力を体系的に読み取ることができる攻撃者はモデル化されていなかった。

標準ではデータブロックに認証なしのAES-CBCが義務付けられており、EDAツールが処理中に記述的な構文エラーを返すことが明示的に推奨されていたため、ツール自体が復号オラクルになっていました。標準のユーザビリティガイダンス「品質エラーメッセージは保護されたIPの品質を反映します」が攻撃ベクトルでした。（推奨事項はCWE 209 - エラーメッセージを通じた情報漏洩を考慮していなかったことに注意してください）。2021年の論文はさらに踏み込んで、EDAツールの実装内に既に展開されているRSAベースのホワイトボックス暗号化方式を発見しました。これは、業界が独自にMan-At-The-End（MATE）の脅威を認識し、その解決策としてWBCを採用したものの、実行環境内に既に侵入している攻撃者から実装を保護するために必要なランタイム整合性レイヤーが欠けていた証拠です。

研究者たちの結論は明確だった。現代のハードウェア設計プロセスを考慮すると、IEEE 1735の脆弱性は暗号化ソリューションだけでは修正できない。それ以外の前提に基づく保護策は、モデル化されていない境界で失敗する。

AI採用メールとIEEE 1735には共通する根本原因がある。それは、保護対策が誤った攻撃者と誤った環境に対して評価されていたことだ。IEEE 1735は受動的な読み取りを想定していたが、実際の攻撃者は実行環境を操作していた。 

 LinkedInのプロフィールは、人間が手動で情報収集を行うことを前提としているが、実際の攻撃者は自動化されたパイプラインを実行する。つまり、情報を収集し、分類し、生成し、大規模に配信するのだ。LLMはEDAツールであり、人間の受信箱はオラクルであり、抽出された平文はHDLではなく信頼の源泉となる。

これは、今日のアプリケーションセキュリティ調達において最も多く見られる失敗パターンである。

セキュリティソリューションの選定において、これは何を意味するのか

開発者が一般公開ソフトウェア向けのセキュリティ製品を評価する際、コンプライアンスの網羅性、統合の複雑さ、パフォーマンスのオーバーヘッドなどを確認します。しかし、通常、以下のような質問は省略されます。  
（１）この保護は攻撃者が何をできないと想定しているのか、  
（２）攻撃者がAI支援ツール、実行環境への完全なアクセス権、無制限のクエリ予算を持っている場合でも、仮定は依然として正しいでしょうか？ 
 
適切な脅威モデル、つまりMan-At-The-EndまたはMan-In-The-Clientを考慮しない保護アーキテクチャでは、攻撃者は デバイス ソフトウェアは、 IEEE 1735年。暗号学 多分 音。境界の仮定はそうではありません。実行環境内に既にいる攻撃者は、 その保護策が想定していた通りに機能せず、通常は重大な問題を引き起こす。  
 
それでも半導体業界がたどり着いた答えは、敵対的な実行環境内で鍵を保護するホワイトボックス暗号と、アクティブな計測を検出して対応するためのランタイム整合性検証を組み合わせたものである。これは、 at モバイルアプリケーション層。コンプライアンスのチェックボックスとしてではなく、脅威への直接的な対応として。 基準を満たしていなかった。 
 
1993年、ロス・アンダーソンは「暗号システムが失敗する理由」の中で次のように主張した。　 セキュリティ上の欠陥は、暗号的な問題に起因することはほとんどない。 実証 数学的には成り立つが、脅威モデルは (NAIST) と 攻撃者、そのアクセス権限、そしてその環境に関する前提が間違っている。アンダーソンの経歴は、こうした前提が技術的には準拠しているものの、運用上は欠陥のあるシステムにつながることを示している。 IEEE 1735や、LinkedInのプロフィールをターゲットにしたAI採用パイプラインは、その一例である。 
 
公開配布されるアプリケーションのセキュリティソリューションを承認する前に、次の質問を自問自答してください。攻撃者が実行できないことを考慮し、ソフトウェアによる保護機能はありますか？ 
 
回答が書き留められていない場合、脅威モデルは作成されていないことになる。 
 
ヨーヨーの場合あなたはあなたの IEEE 1735または その他のホワイトボックス暗号グラフィックのニーズ アンとドレイ、 お問い合わせ こちら: https://digital.ai/why-digital-ai/contact/

参考情報

アンダーソン、RJ（1994）。暗号システムが失敗する理由  
https://doi.org/10.1145/188280.188291 
 
Chhotaray 他、「不適切な暗号化手法の標準化」 https://doi.org/10.1145/3133956.3134040 
 
Speith 他、「知的財産を保護するための間違った方法」  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html