ハードウェアに起因する脆弱性

　ハードウェアの脆弱性でよく知られたものについて、少し触れておこうと思う。Kasperskyのブログで掲載された解説の一部を以下に列挙する。

• 1.DDR DRAM

　DDRメモリにおいて、特定のセルに高頻度なデータ書き換えを行うと、隣接した同じ行（Row）のセルデータが不安定になるという現象を利用した攻撃「Row Hammer」が存在する。隣接する保護されたセルのビットが反転してアクセス権が獲得されてしまうというもので、電子的な特性に基づいた攻撃であり防ぎようがないのが実情だ。しかし、DDR4やパリティチェックに対応したモジュールを採用することで（コスト増になるが）この問題に対処できる。

• 2.USBインタフェース

　「BadUSB」という名前を与えられているこの問題は、USBの仕様上の脆弱性を突いたもので、USBコントローラー（多くの場合ARMコアで動作していると思われるが、それは重要ではない）のファームウェアを更新する仕組みを利用（悪用）して任意のコードに書き換えることができるというもので、書き換え自体を防ぐことはできない。

　この問題はPCだけでなく、充電器経由でiPhoneにマルウェアを感染させることができることも実証済みである。しかし、対策は可能であり、BadUSBを検知しブロックする機能を搭載したセキュリティ製品も市販されている。

• 3.Thunderboltインタフェース

　Thunderboltインタフェースに関しては、マスターブートレコードに感染する「bootkit」と呼ばれる種類のマルウェアの一種「Thunderstike」が知られ、USBインタフェース同様だがより根が深い。

　この脆弱性を利用することで、ファームウェアを変更される恐れがあり、OS Xのアーキテクチャとも強い関連があるため根治できないともいわれる。ThunderboltがほぼApple製品にしか採用されていないこともあって、いまのところAppleによる対策を待つしかない。

組み込み開発者は「どこまで」留意して開発するべきか

　これらはソフトウェアだけでは完全には防ぎきることができないセキュリティ上の問題で、恐らく他にもあるだろう。第1回で触れたジープ「グランドチェロキー」のハッキングに使われたのは、MCUのファームウェアに潜んでいたバグだった。

　組み込み開発者は要求仕様を満たす機能を実装するだけではなく、同時にハードウェアの脆弱性も把握し、いかに回避するか、あるいはより安全なプラットフォームを選択するための情報を収集し、経験を積んでいかなければならない時代になっている。

　ハードウェアだけではなく、通信の知識も身につけたい。例えばデバイスとサービスの間でのやりとりをTwitterなどのメッセージングサービスを使ってつなぐことがあるが、通信を暗号化する必要がある際には、HTTPSだけではなく、MQTTのような軽量なプロトコルを利用することもできる。

　また、MQTTでは暗号化の必要があればTLS/SSLを利用することができる。性能とセキュリティは多くの場合に相反するが、MQTTを利用しながら通信内容を保護したい際にTLSを使うとハードウェアリソースの要求が高くなるため、組み込みシステムではお勧めできない実装になることがある。

　同様な問題であるが、証明書を使った仕組みはオーバーヘッドが大きく通信量も増加することになり、頻繁に通信しなければならないようなシステムが増えていくと通信インフラにどの程度の負荷がかかるのかを厳密に管理するのは困難になる。

　一方で3G／LTEのSIMを利用して通信量を回線ごと、あるいは複数回線をまとめて管理制御可能な仕組みも登場している。これは通信の安全性を担保するための証明書や端末の特定や管理の仕組みが確立されているため、セキュリティを担保しやすいということになる。とはいえ、デバイスが正常に動作しているかどうか確認するには回線の管理だけでは不十分であるので、よく考える必要がある。