Zenn
🍣

ARM(PSA Certified) Platform Security Model 内容理解 [1]　1.1章まで

に公開
Arm
組み込み開発
Private Service Access
trustzone
cortexm
idea

前書き

最新のCortex-Mアーキテクチャには、TrustZoneと呼ばれるsecurity関連の機能が追加されているが、実際のところ、これが何なのか理解できていない人が多いのではないでしょうか。
私もその一人です。

本記事では、TrustZoneの設計コンセプトである大本の資料になる「Platform Security Model」という資料を勉強がてら読み込み、理解した内容をここにまとめます。ほとんど翻訳しただけで、ちょっと自分の思うことをコメント追記してます。

なお、当方は何か専門的な教育を受けたものではないため、本資料について、何ら責任をとれませんので参考程度にお願いします。

Platform Security Model の位置づけ

近年の組み込み開発ではInternet of Things(IoT)などと呼ばれるようにネットワーク接続は当然となった。いまやIoT製品は活の必需品と呼べるものにまで普及した。
しかし、生活に密接に結びつくようになったIoT製品はひとたび悪意のある攻撃者から攻撃を受けたとき、個人情報が流出するだけでなく物的・経済的損失を発生させる恐れがある。
IoT製品のこれらセキュリティの考えというのは、これまで定まった考えというのはなかった。

IoT製品がより生活に溶け込むためには、これら攻撃から守られた製品を開発していく必要があり、これを効率よく、そして確実に実装されていくためのアーキテクチャと安全性の認証を Platform Security Architecture(PSA) ならびに PSA Certified 呼ぶ。

本題のPlatform Security Model (PSM) はARMが提唱するPSAの基盤となるドキュメントで、IoTに限らず組み込み製品がセキュリティを保持するために、「セキュリティの本質」やそれを満たすための基本的な構成要素や製品ライフサイクルなどを定義したドキュメントである。PSAはPSMをルートドキュメントとして具体的に実装されたArchitectureであると考える。

本文

1. Platform Security Model 概要

本ドキュメント(PSM)は

  • 脅威モデル (threat models)
  • セキュリティ分析 (security analysys)
  • セキュリティ要件仕様 (security requirement specifications)
  • API

などをアーキテクチャに依存しないようにまとめられたドキュメントの一つである。
本ドキュメントとオープンソースのリファレンス実装とテストスイートと組み合わせることで、適切なレベルのセキュリティで一貫した設計が可能になります。

本ドキュメントを用いたフレームワークは、これまでの業界全体（チップ設計、ソフトウェアベンダー、デバイス開発、クラウド、ネットワークインフラ）の経験をもとに構築されている。ネットワーク接続されたデバイスを焦点に充てていますが、多くの側面では、非ネットワーク接続のデバイスにも当てはまります。
PSMでは、ソリューションのアーキテクチャ(ARM CortexやTrustZoneなどを)を前提としていません。
リソース制約のあるMCUからリソースの豊富なMPUであっても説明されている内容が満たせることを想定しています。

このセキュリティモデルは、ほかのプラットフォームセキュリティ仕様の最上位ドキュメントになり、用語の定義、高レベルのロバスト性のルール、並びにモデルの定義をします。

実際の製品は、実装のロバスト性の尺度を提供するために、PSA certifiedを受けることができます。

1.1 10のセキュリティゴール

以下10つのコアとなるセキュリティゴールは、セキュリティを確保し信頼を確立するための必要な基本機能を、高レベルの抽象的な方法として示しています。
これらの抽象化された目標は、エンドユーザーが接続するデバイス・ハードウェアコンポーネント・ソフトウェアコンポーネント・サービスなどに適用することができます。
なおお、「デバイス」という用語はセキュリティと信頼性が確保されなければならないすべてのエンティティを表すために使用することができます。

  1. デバイスは一意に識別可能であること (Devices are uniquely identifiable)
    特定のデバイスインスタンスとやり取りするには、そのインスタンスを一意に識別できる必要があります。
    デバイスIDを証明する手段として、そのIDは証明可能であり、その証明は検証可能である必要があります(See Goal 3)。
  1. デバイスはセキュリティライフサイクルをサポートすること (Devices support a security lifecycle)
    セキュリティライフサイクルにおけるデバイスのセキュリティの状態は、ソフトウェアのバージョン、実行時、ハードウェア構成、デバッグポートの状態、製品のライフサイクルの段階によって異なります。製品ライフサイクルの段階には、開発・導入・返品・サポート終了などが含まれます。それぞれのセキュリティの状態は、デバイスのセキュリティの特性を定義する必要があります。セキュリティの状態は証明可能なものであり(Goal 3)、バインドされたデータへのアクセスに影響を与える可能性があります(Goal 9)。
  1. デバイスは安全に信頼性を証明できる (Devices are securely attestable)
    デバイスの信頼性を確立する必要があります。そのためには、デバイスのID(Goal 1)とセキュリティの状態(Goal 2)が証明可能でその証明を検証可能である必要があります。この有効性を確保するには、デバイスIDと構成証明データがデバイスガバナンス体制に組み込まれている必要があります。
  1. デバイスは許可されたソフトウェアのみが実行できることを保証すること (Devices ensure that only authorized software can be executed)
    セキュアブートとセキュアロード処理はデバイス上で許可されたソフトウェアのみが実行されるようにするために不可欠な機能です。許可されていないソフトウェアの実行はそのようなソフトウェアがデバイスのセキュリティを侵害しない場合にのみ許可されます。
  1. デバイスはセキュアアップデートをサポートすること (Devices support secure update)
    デバイスのソフトウェア、認証情報、構成の変更が可能なハードウェア構成、セキュリティ問題の解決や機能アップデートの提供のために、アップデート可能であること。
    更新には認証が必要である。
  2. デバイスは不正なロールバック防止すること (Devices prevent unauthorized rollback of updates)
    Goal 5のアップデートに伴い、過去の脆弱性を含む以前のバージョンへのロールバックを防止すること。　
    ただし、復旧を目的とした承認済みのロールバックは許可される場合があります。
  3. デバイスは分離機能をサポートすること (Devices support isolation)
    信頼できるサービスを、信頼性の低いサービスや信頼できないサービスから分離することは、そのサービスの整合性を守るために不可欠であるため、これらが不可侵になるように分離する機能が必要です。
    分離する協会は、例えばデバイス上のサービス間、あるいはデバイス上のサービスとインターネット接続環境間など、あるサービスがほかのサービスに影響を与えることを防ぐことを目的としています。
  4. デバイスは分離された境界を越えた相互作用をサポートすること (Devices support intaraction over isolation boundaries)
    分離されたサービスが目的を果たすためには、分離された境界を越えた相互作用が必要です。このような相互作用は相互作用するサービスやデバイスに危害を及ぼしてはなりません。そのためには、好感されるでーたの検証が必要となる。また、好感されるデータの機密性と完全性を確保することも必要となる場合があります。
  5. デバイスは機密データをそのデバイス固有の要素に一意的に紐づけて保持することができること(Devices support unique binding of sensitive data to a device)
    ユーザやサービスの認証情報、秘密鍵などの機密データは、デバイス外部への漏洩を防ぐためにデバイスにバインドする必要があります。また所有者以外への漏洩を防ぐためにもこのようなデータをバインドする必要がある場合があります。本質的に安全なストレージ、または機密性と整合性が保証されたストレージを使用できます。バインドが暗号化と鍵に依存している場合（Goal 10）、鍵は機密データであるため、デバイスまたはデータ所有者にバインドする必要があります。また、デバッグ中にアクセスを拒否するなど、データをセキュリティ状態にバインドする必要がある場合もあります
  1. デバイスは、他の目的をサポートするために必要な、信頼できるサービスと暗号化操作の最小限のセットをサポートすること (Devices support a minimal set of trusted services and cryptographic operations that are necessary for the device to support the other goals)　
    信頼できるサービスには、ここまでのGoalをサポートするために使用されるバインドされた機密情報（秘密鍵など）を使用する可能性のある暗号化サービスが含まれ、信頼されたサービスは、分析されることを可能にし、血管の可能性を提言するために、可能な限り小規模に抑える必要があります。

以上のGoalは各具体的な製品のために設計されたプラットフォームセキュリティ仕様上で具体化され反映されます。
すべての機能を実装することが推奨されますが、デバイスのセキュリティを確保するためにサポートされる機能は対象となるアプリケーションドメインとコスト、適用される脅威モデル、適用される国家規格、エコシステム事業者、認証スキームなどによって決まります。


参考: https://www.ecsec.jp/relays/download/43/235/25/214/?file=/files/libs/214/202206171659122271.pdf

Discussion