Board、Desk、および Room シリーズ デバイス上のファイル システムは、Linux Unified Key Setup (LUKS) を使用して暗号化されます。これは、Linux ハード ディスク暗号化の標準です。 ファイルシステムの暗号キーは、NVRAM または NOR フラッシュのどちらかに保存されます。 工場出荷時の状態にリセットすると、キーは上書きされ、回復できません。ディスク上の何かを読み取り不能にします。 これにより、工場出荷時設定へのリセットは、米国 DOD 5220.22M および NIST 800-88r1 に準拠したデータの削除と消去の安全な方法になります。

工場出荷時の状態にリセットした場合：

• 通話履歴が削除されます。

• パスフレーズがデフォルト設定にリセットされます。

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

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

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

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

工場出荷時の初期設定へのリセット操作を元に戻すことはできません。 開始する前に、これを行う必要がある事を確認してください。

NIST 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 ビットで、暗号が aes-xts-plain64 である LUKS1 を使用して作成されます。

 $ cryptsetup status /dev/mapper/config /dev/mapper/config はアクティブで使用中です。タイプ: LUKS1 暗号: aes-xts-plain64 キーサイズ: 512 ビット キーの場所: dm-crypt デバイス: /dev/loop5 ループ: /mnt/base/image1/rwfs/config.img セクターサイズ: 512 オフセット: 4096 セクター サイズ: 61440 セクター モード: 読み取り/書き込み

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

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

データ暗号化キーの保護

当社のデバイスでは 2 つの異なる暗号化キーを使用しています。 1 つは Android コンテナ内の /data パーティション用 (Microsoft MTR および Zoom 用)、もう 1 つは他のファイル システム用 (顧客構成、壁紙、通話ログ、履歴ログなどに使用)。

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

ce-11.25.x までは、その他のキーは EEPROM に保存されます。 EEPROM は通常のチャネルからアクセスするユーザからはアクセスできませんが、デバイスから (フラッシュ ディスクとともに) 強制的に削除して、実際に内容を復号化することができます。

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

Room Navigator の場合、移行は後のバージョンで行われます。