画像系SoC(LSI)開発のコンサルティング案件の中で、Arm Trusted Firmware-A (以下TF-A)を読み解くことをここ半年ぐらい続けている。また、既存組込みシステム向けセキュリティ・モジュール検討手段としてセキュアマイコンとセキュアエレメントも面白い。
今日は、Arm Trusted Firmware-Aについて書いてみる。
はじめに
私の仕事としては、元々は、RISC-Vベース上のセキュリティアーキテクチャ(特にKeystone) の調査案件だったのだが、その後、Arm TrustZone-A(Arm社が提供するセキュリティHWアーキテクチャ) → OP-TEE(TrustZone向けセキュリティフレームワーク) → Secure Boot(セキュアなSoC起動) → Trusted Firmware-A(Arm社が提唱するセキュアなCortex-A SoCのSW実装指南書。以下「TF-A」と記述。) と少しずつ対象分野が具体化してきている。
本blogでは、Arm TrustZoneをキーワードにセキュリティを構築する際に、知っておいた方が良い項目を紹介してみる。
Secure Boot
SoC(LSI)のセキュリティ起動なんて、SoCのLinux上でアプリケーションを構築している方々には当たり前のことなのだが、TrustZoneで実現したいセキュリティ機能、性能、信頼性を言った途端に、SoCの全てにおいて実現したいセキュリティレベルに全てを合わせなければならなくなって、技術レベル、知識レベルがドンを上がって来ているのが実状。それがいわゆるSecure Bootと呼ばれる機構。
Secureじゃない普通のBootは、SoCがPower On Resetで立ち上がった際に、SoCがつながれているQuad SPI Flash Memory (以下 QSPI-Flash)に書かれたArm Binary Codeを順に読み出し、自身のメモリにある程度取り込んでから実行する仕組みだ。
近年、ハッカー達がネットワークに飽き足らず、ハードウェア端子やICピンにプローブを宛ててデータを解析する(QSPI-Flashの内容を抜き出す)様になり、ハードウェア提供者はその操作を阻止する必要性が出てきた。 とにかく最近のセキュリティ侵害は、組込み機器メーカに取っては頭の痛い話となっている。
平和的なChipを作ることに慣れてしまっている日本の技術者だが、現実としては、「日本の開発会社でまともな(世界で対抗できる) Cortex-Aシリーズのセキュリティコードを設計出来る人が居るの？」って感じ。
Arm TrustZoneセキュリティアーキテクチャを支えるTF-A
Arm社はセキュリティ機構のTrustZoneを提供しているが、SWとしてのセキュリティ実装はコンセプトは提唱するけど実装自体は関わっていない様で、現状は、Armのセキュリティで最も経験値が高いのはスマートフォン用SoCを作っている(使っている？)人達の様で、彼らのセキュリティに関連する情報はArm社にもあまり届いていないように思える。
TrustZoneはハードウェアとしてのセキュリティアーキテクチャで、本来はそのアーキテクチャ上でセキュアなプログラムを稼動させる訳であるが、Arm社はそのセキュアなプログラムを稼動させるベースのプログラムをTrusted Firmware-A (TF-A) として公開している。
TF-Aのドキュメントを読んでいくとArm社が培った(顧客からクレームを受けた)SoC開発ノウハウが相当ふんだんにまき散らされていて、日本の半導体開発会社では経験できなかった事がたくさん書かれていた。
さすがに教科書ほどまとまっては無いけど、中堅どころの半導体ロジック開発者が読めば、一気に5年ぐらいのノウハウを短時間に得ることができるだろうと思う。そのノウハウを知らないで、これからのSoCのセキュリティを語るのは相当危険に思える。
Armのドキュメントは、コンセプトを説明した “Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A” が基本で、TF-Aの実装の詳細を書き殴った TF-A Document も一読をお勧めします。
まとめ
ここでは、Arm TrustZone, TF-A の話題を書いたが、実際にはTrustZoneで稼動するTrusted OS やTrusted Applicationで「どんなセキュアなアプリをどのように動かすか？」が一番大事なポイントだ。但し、そこに行き着く迄に、多くの面倒くさい技術を積み上げないといけないというのが近年のSoCの難しいところだと思っている。