中世史に学ぶ、組み込みシステムのセキュリティモデル：SYSTEM DESIGN JOURNAL（2/6 ページ）

セキュリティの確保は重要ですが、リソースや利便性との兼ね合いも求められます。組み込みシステムのセキュリティ確保について、中世の城の防衛策を例に考察します。

[Ron Wilson，（Editor-in-chief,Altera）,MONOist]

　システム攻撃の基本形は別人になりすますことです。攻撃者は、データの読み書き、コードの実行、またはシステム更新の権限を持つユーザーのふりをします。そのような攻撃を阻止するには、認証 （通常はパスワードや証明書による身元の証明）を相手に求める必要があります。

　しかし、トランザクションをモニタしていれば、誰でも簡単にパスワードをコピーできます。多くの場合、システムはパターンを変えてパスワードを暗号化し、暗号化されたパスワードさえ盗んで再利用するようないわゆる介入者攻撃を防止します。

　これでもまだ不十分です。介入者は、価値が高いデータを閲覧するだけで盗んだり、システムに送信されるコードやデータを破壊させたりできます。そのため、多くのアプリケーションでトランザクション全体を暗号化することが重要です。多くの場合、このレベルのセキュリティはTLS（Transport Layer Security：SSLの後継機能）やIPsecによりインターネット上で提供されます。原理的には、鍵が盗まれない限り、これらのプロトコルによってトランザクションの内容の読み取りや改ざんが防止されます。しかし、この2つには大きな違いがあります。

　よく使用されるhttps（セキュア接続）の基本であるTLS は、TCP上のレイヤー4で動作するので、Webブラウザなどのアプリケーションに実装できます。大してレイヤー3で動作するIPsecはOSのカーネルでサポートする必要があるため、TLSほど普及していません。

　IPsecがTLSよりセキュアであることはほぼ間違いありませんが、今日では主に企業のVPNに使用されているだけです。さらに強力なイーサネットトラフィックの3つ目の暗号化手段であるMACsecは、パケット全体を暗号化して介入者に送信元、送信先、フォーマット、または内容を知られないようにしますが、はイーサネットインタフェースのハードウェアを大幅に変更する必要があるため、まだ普及していません。

公開暗号鍵

　認証と暗号化のいずれにも、そもそも「誰にも盗まれず、相手へ暗号鍵をどのように渡すか」という論理的な問題があります。この一般的な答えは公開鍵暗号です。残念ながら計算量の多いこのプロセスは、いずれも大きな乱数から導き出した鍵のペアを使用します。1つは誰とでも共有できる公開鍵であり、もう1つは所有者が秘密にしなければならない秘密鍵です。

　認証する場合、サーバは秘密鍵を使用して証明書（またはそのハッシュ）を暗号化し、暗号化したメッセージをクライアントに送信できます。その後、どのクライアントも対応する公開鍵でメッセージを復号し、サーバが秘密鍵の実際の所有者であることを確認できます。復号で有効な証明書またはハッシュが生成されたら、対応する秘密鍵でデータが暗号化されていたことになります。信頼性を高める証明書の所有権を記録したレジストリに関する、さらなる詳細があります。残念ながら、証明書の登録維持に注意を払うサーバオペレータはあまりいないため、クライアントはメッセージを復号できるだけで満足することがほとんどです。

　トラフィック自体のセキュリティのプロセスはちょうど逆です。メッセージを公開鍵で暗号化するのは誰でもできますが、復号できるのは対応する秘密鍵の持ち主だけです。この非対称アプローチにより、サーバとクライアントの間で暗号化されていない秘密鍵を何らかの方法で最初に渡すことなく、情報を渡すことができます。