セキュリティ実装で重みが増す"LSI全体アーキテクチャ設計"―― LSI設計の次のチャレンジを探る
●セキュリティ対策をむやみに集めるな！
セキュリティが怖いのは，セキュリティ処理系ばかりに目を奪われていると，ささいな盲点を見逃して事故が起きる点です．筆者の知る例として，以下のようなケースがありました．
「セキュリティ・アルゴリズムを慎重に検討し，秘密鍵が漏れないよう十分に気をつけてLSI設計やチップ製造を行い，市場投入した．ところが，オンチップCPU上のOSが有名なバッファ・オーバフロー攻撃を受け，暗号をほどいた後の平文を盗られてしまった」
いくら秘密鍵がばれなくても，平文がばれては元も子もありません．「何を間抜けな失敗をやっているんだ？」と思われるかもしれませんが，いざ自分がセキュリティ回路の設計担当になってみると，同様な失敗をしない困難さを痛感させられます．技術者が集まって設計レビューを行っても，議論が細部や重箱の隅に集中しがちで，一歩引いて全体をふかんしたり，客観視したりする態度になりにくいのです．
また，ちまたのセキュリティ対策を調べて寄せ集めたとしても，それで安心できるわけではありません（図5）．セキュリティ・ホールがないという保証にはなりませんし，1カ所でもセキュリティ・ホールがあれば，全体がダメになるからです．普遍的な設計マニュアルのようなものは存在しないので，本当に大丈夫かを疑いつつ，ブートから定常状態までのLSI内部の動き，LSIアーキテクチャとデータや鍵の流れ方，パッケージ方式や外部インターフェース仕様，設計・製造体制などを熟考していくしかありません．
図5 全体セキュリティ ≠ 部分セキュリティの総和
ものづくりではしばしば言われるように，セキュリティでも「全体視点」が重要です．ただしセキュリティにおいては，「設計最適化が進まない」という量的問題ではなく，「セキュリティが破られる」という定性的結果に直結してしまう点が厳しいところです．
●対策は無制限には施せない
回路設計者がぶつかる壁はまだあります．いくらセキュリティ・ホールの存在が許されないとは言え，セキュリティ対策を無制限には投入できないことです．さまざまなセキュリティ上の問題点に対処していくと，LSIはどんどん複雑化・肥大化する方向に向かい（それがかえって新しいセキュリティ・ホールを生むこともある），設計・製造コストとのトレードオフの問題に必ず突き当たります．
例えば先ほどの例で，セキュリティ回路担当者がいくら「外部フラッシュ・メモリに鍵を置くとアタックされるから，オンチップNV（不揮発）RAMを搭載してほしい．それが可能なプロセス・ルールやファブを選定してほしい」と要請したところで，チップ価格が高騰したり社外交渉が煩雑になったりするのなら却下されるでしょう．もちろん設計プロジェクト・マネージャに「もしセキュリティが破られたら大変だから」というたぐいの説明はするのですが，「そのアタックを受ける現実的可能性はどれくらいあり，どれだけの損害になるのか？ コスト増に見合うのか？」と問われると，誰もが納得できる形で答えるのは容易ではありません（直接的損害だけでなく，信用・ブランドの失墜などもあり，数値化しにくい）．
多数のセキュリティ事故が報道されていても「自分たちの作るLSIはそのような事故には会わない」と思ってしまうためか，セキュリティが軽視されて"おまけ"扱いになる場合が珍しくありません．一方で，一度痛い目に会うと，今度は過剰な対策に走りがちでもあります．セキュリティ対策は必ずどこかで打ち切らないといけないのですが，線引きの明確な基準はなく，最後は政治的判断になってしまいます．
●LSI全体のセキュリティとコストを両立させる方法論は未成熟
また，世の中に公開されているセキュリティ対策を使おうとすると，製品開発に支障をきたす場合もあります．少々極端ですが，そのような例を図6に示します．有名なサイドチャネル攻撃（例えば，処理中の電力波形を多数集めて秘密鍵を推定する）に対する対策の一例として，非同期回路を使用する方法や特殊なカスタム・セルを使用する方法が研究されています．しかし，システムLSI設計者であれば誰しもが思うとおり，その方法を採用するのは厳しいでしょう．無理に設計フローやファブを変えれば，どれだけの追加コストが発生するか分かりません．そもそも，暗号IPコア単体で完璧なガードをしなくても，秘密鍵を頻繁に変えるよう上位設計を行えば，セキュリティは犠牲になりません．
図6 必要なセキュリティを適切なコストで実現したいが...
この例に限らず，セキュリティの個別シーズ技術の研究開発はとても活発なのですが，以下のようなLSI全体設計の立場からのニーズについては，残念ながらあまり対応できていないのが実情です．
- LSI全体としてセキュリティが保たれているかを検証したい
- 複数部品・複数設計レイヤにまたがる形で必要なセキュリティ機能を実装し，不要なコストの増加を抑えたい
- 現在および将来のLSIの設計スタイルや設計環境に適合した形でセキュリティを実装したい
- 市場投入後に万一セキュリティが破られた場合，それっきりにならないようにしたい
以上はLSIに限った話ではなく，機器やシステムに置き換えても成立する課題です．LSI実装におけるその他の課題を，図7にまとめます．
図7 セキュリティのLSI実装における他の重要課題
特に，上記の4．については，将来，情報通信システムのようなインフラ系で使うLSIを開発する際に，きわめて重要な要件となりそうです．
なお，暗号モジュール実装の安全性については，NIST FIPS 140-2/3，ISO/IEC 19790:2006, 24759:2008などの評価基準があります（図8）．また，形式検証を使ってセキュリティ・アルゴリズムの安全性を証明する研究などもあります．しかし，新しい攻撃法や新しいセキュリティ概念が登場するスピードが速く，どうしても後追い気味になってしまいます．
図8 セキュリティ規格は必要だが，十分ではない
