自己紹介

　2023年新卒入社の磯谷彰宏です。博物館や資料館に行くのが好きです。好きなアーティストはVermeerです。大学では情報セキュリティ研究室に所属してました。分析を妨害する手法について考えたり規則や認識の穴を探したりしながら生活をしてました、というと性格悪いように見えますね。予期しない方法で非直感的な結果を得るというのが面白くてセキュリティの勉強をしてました。

　今回は卒業研究の内容を簡単に説明します。出所不明のうわさに振り回される人を減らしたい。

課題

一度に複数に発信するマルチキャストで、発信元や文書の完全性を楽に確認するにはどうしたらいいでしょうか。会社で例えると、平社員がボスのふりして社員にデタラメに伝達したら困りますよね。別に元々立場の上下を反映する仕組みではないのですが説明のために「ボス」は主に発信する側、「社員」は主に受信する側として用います。

マルチキャストの難しさ

1対多の通信でハイブリッド暗号方式のような方法を利用すると、送信者の共通鍵を沢山の受信者で共有することになり、中にはその共通鍵を利用してその送信者のふりする受信者がいるかもしれません。以下HMACは、ハッシュ関数と共通鍵を用いたメッセージの完全性を検証する仕組み、またそのコードを指します。

イメージ

ボス「HMACの共通鍵を公開鍵暗号で送ります。社員其々の公開鍵で暗号化したから各自確認するように。」

社員たち「了解しました。HMACはこの鍵で検証します。」

悪い社員「私はボスです。これから我が社は〇〇プロジェクトを進めます。(共通鍵を用いて、ボスの正しいHMACが生成できる)」

社員たち「HMAC計算したら正しい値になるし正しいメッセージなのだろう。ボスはこれから〇〇プロジェクトを推進するらしい。」

ボス(え、〇〇プロジェクトなんてするつもりないんだけど)

　実際のネットワークでも参加者全員が信用できるとは限らず、信用できるデバイスも悪意ある第三者に操られているかもしれないので、マルチキャストを使うならどうにかメッセージの発信元や文書の完全性を担保する別の仕組みが必要になります。

解決策

　解決策の一つとして、共通鍵と暗号学的ハッシュ関数と少しの電子署名と時刻同期を用いて公開鍵暗号方式と同様の性質を満たすTESLAプロトコルがPerrigらによって提案されました。EVメーカーではありません。基本的な発想は、送信者がHMACを送信して暫くしてからそのHMACに対応する鍵を送信することで、受信者はその鍵を新たなHMACの生成には使えずに既にあるHMACの検証にのみ使えるようにするというものです。それを一方向にだけ計算できる鍵の列を用いて継続的に実施します。事前に計算した分の鍵を使い切って新しい鍵の列に切り替えるごとに電子署名を用います。　

イメージ

ずらす時間は実際には数十ms~1000msくらいですが、ずらす時間を長くして説明します。

ボス「来月からAしますよ。(HMAC添付)」

ボス?「来月からBしますよ。(HMAC添付)」

社員たち「メッセージ二つ、ボスを称する人から来たわ」

~~~数時間経過~~~

ボス「業績よかったから臨時ボーナス出します。(HMAC添付) あと、先程のメッセージに添付したHMACはこちらの鍵で確認してください。」

社員たち「鍵は正しいようだしHMACを正しく検証できたから『Aします』の方はボスの発言だ。でもBは無理だったからこっちは偽物じゃん! 臨時ボーナスが本当だと良いなあ。数時間後に確認してから喜ぼうか。」

結び

 私は卒論で、鍵の列の切り替わりの部分を工夫することで電子署名の計算を不要にする改善案を提示しました。C言語での実行時エラーに悩まされてもう少しどうにかならんかと思ったのをきっかけにRustを勉強していたので、簡易な必要計算量シミュレータをRustで書いて、性能評価をしました。ちょっと良くなりそうな感じでした。エンジニアとして、楽に良い結果を得る方法を色々考えたいものです。

参考文献
Adrian Perrig,2002, The TESLA Broadcast Authentication Protocol https://people.eecs.berkeley.edu/~tygar/papers/TESLA_broadcast_authentication_protocol.pdf