コメントありがとうございます。

ボード、デスク、ルームシリーズのデバイス上のファイルシステムは、Linuxハードディスク暗号化の標準であるLinux統合キーセットアップ（LUKS）を使用して暗号化されます。 ファイルシステムの暗号化キーは、NVRAMまたはNOR-Flashに保存されます。 工場出荷時の状態にリセットすると、キーは上書きされて元に戻すことができず、ディスク上の内容が読み取れなくなります。 これにより、工場出荷時の状態にリセットすることは、米国国防総省5220.22MおよびNIST 800-88r1に準拠した安全なデータ削除および消去方法になります。

工場出荷時設定へのリセット中：

• 通話記録は削除されます

• パスフレーズはデフォルトにリセットされます

• すべてのデバイスパラメータがデフォルト値にリセットされます

• デバイスにアップロードされたすべてのファイルが削除されます

• 以前の（非アクティブな）ソフトウェアイメージは削除されます

• オプションキーは影響を受けません

工場出荷時設定へのリセットは元に戻せません。 始める前に、そうすることが必要であることを確認してください。

ニスト 800-88r1

NIST規格の800-88r1では、次の3つのレベルの消毒が規定されています。

• 清潔：非侵襲的な回復技術から身を守ってください

• パージ：データ復旧を不可能にしてください

• 破壊：データの回復を不可能にし、将来使用されないようにします

規格のセクション2.6では、暗号消去（CE）の使用方法と、それをどのように適用してパージレベルを満たすことができるかについて説明しています。

セクション2.6.1と2.6.2には、CEを考慮すべき（しない）場合の条件がリストされています。

• 機密データを先にサニタイズせずにデバイスに保存した後に暗号化が有効になった場合は、CEを使用してメディアをパージしないでください。

• 機密データが暗号化の前にサニタイズされずにデバイスに保存されたかどうかがわからない場合は、CEを使用しないでください。

• CE向けのすべてのデータ（データおよび仮想コピーを含む）がメディアに保存される前に暗号化されている場合は、CEの使用を検討してください。

• 暗号化キーが保存されているメディア上の場所（ターゲットデータの暗号化キーまたは関連するラッピングキー）がわかっていて、適切なメディア固有のサニタイズ技術を使用してそれらの領域をサニタイズし、キーが保存されているメディア上の実際の場所を特定できる場合は、CEの使用を検討してください。

• ターゲットデータの暗号化に使用される暗号化キーのコピーがすべてサニタイズされていることがわかっている場合は、CEの使用を検討してください。

• ターゲットデータの暗号化キー自体が1つ以上のラッピングキーで暗号化されていて、対応するラッピングキーをサニタイズできると確信している場合は、CEの使用を検討してください。

• CE操作を実行するためにデバイスから提供されるコマンドをユーザーが明確に識別して使用できると確信できる場合は、CEの使用を検討してください。

RoomOSでは、顧客データに使用される暗号化されたファイルシステムは、機密データを作成する前の初期段階で、初期起動時に設定および暗号化されます。 キーは上記のようにeeprom（古いソフトウェア）またはSoCのトラストゾーンメカニズムを使用して保存され、安全にサニタイズできます。

鍵はバックアップされず、鍵のエスクローメカニズムもありません。

これらすべてを念頭に置いて、CiscoはRoomOSの工場出荷時設定へのリセットメカニズムがNIST 800-88r1のパージレベルに準拠していると主張しています。

顧客データの暗号化

ディスク暗号化

デバイスは大容量記憶装置にフラッシュデバイスを使用しますが、安全な削除は保証できません。 そのため、デバイス上のすべての顧客データは暗号化されたファイルシステムに保存され、工場出荷時のデフォルトにリセットすると、暗号化キーのみが削除され、顧客データにアクセスできなくなります。

これを容易にするために、メインフラッシュに適切なサイズのファイルを作成し、標準のLinuxツールcryptsetupを使用してループバックデバイスを作成します。 このデバイスでは、標準のext4ファイルシステムを作成します。 暗号化キーを保存する場所の詳細は、次のセクションにあります。

ループデバイスは、キーサイズが512ビットのLUKS1とaes-xts-plain64暗号を使用して作成されます。

 $ cryptsetup status /dev/mapper/config
 /dev/mapper/config is active and is in use.
 type: LUKS1
 cipher: aes-xts-plain64
 keysize: 512 bits
 key location: dm-crypt
 device: /dev/loop5
 loop: /mnt/base/image1/rwfs/config.img
 sector size: 512
 offset: 4096 sectors
 size: 61440 sectors
 mode: read/write

デバイスの通常の動作中、cryptsetupは、マウントされる前にファイルシステムを復号化するために使用されます。 暗号化キーが削除されると、ループデバイスをセットアップしてファイルシステムをマウントできなくなります。

私たちが使用する暗号化キーは、/dev/urandomから20バイト読み込んで、sha1sumを実行してASCII表現を取得することです。 キーは、工場出荷時設定にリセットした後の最初の起動時に生成され、新たに工場出荷時設定にリセットされるまで変更されません。

データ暗号化キー保護

デバイスでは2つの異なる暗号化キーを使用しています。 1つはAndroidコンテナ内の/dataパーティション用（Microsoft MTRとZoom用）、もう1つは他のファイルシステム用（顧客設定、壁紙、通話記録、履歴ログなどに使用）。

Androidの/dataパーティションでは、秘密鍵は常にNvidia TrustZone境界内に安全に保存されているか、SoCの組み込み暗号化メカニズムを使用して暗号化されています。Room Navigator

ce-11.25.xまでは、もう片方のキーはEEPROMに保存されます。 EEPROMは、通常のどのチャネルからでもアクセスできませんが、デバイスから（フラッシュディスクと一緒に）強制的に取り外して、実際に内容を解読することはできます。

ce-11.26.xから、通常のファイルシステム暗号化キーをARM TrustZone [0] に基づくNvidiaトラステッド実行環境（TEE）に移行します。これにより、キーをNvidia SoCから抽出できなくなります。 セキュアブートプロセスを回避する唯一の（既知の）方法は、Nvidia SoC全体を交換してキーを削除することなので、キーの抽出は、CEコードの脆弱性を発見して、キーを取得するための十分な権限を持つルートシェルを取得することに限定されます。

Room Navigator移行は後のバージョンになるからです。