보드, 데스크 및 룸 시리즈 디바이스의 파일 시스템은 Linux 하드 디스크 암호화의 표준인 LUKS(Linux Unified Key Setup)를 사용하여 암호화됩니다. 파일 시스템 암호화 키는 NVRAM 또는 플래시에 저장됩니다. 팩토리 설정 중에는 키를 덮어쓰고 복구할 수 없으므로 디스크의 아무 내용도 읽을 수 없습니다. 따라서 공장 초기화는 US DOD 5220.22M 및 NIST 800-88r1에 따라 데이터를 삭제하고 제거하는 안전한 방법입니다.

팩토리 설정 중:

• 통화 로그가 삭제됩니다.

• 암호가 기본값으로 재설정됩니다.

• 모든 디바이스 매개 변수가 기본값으로 재설정됩니다.

• 디바이스에 업로드된 모든 파일이 삭제됩니다.

• 이전(비활성) 소프트웨어 이미지가 삭제됩니다.

• 옵션 키는 영향을 받지 않습니다.

팩토리 설정은 실행 취소할 수 없습니다. 시작하기 전에 팩토리 설정이 반드시 필요한지 확인하십시오.

NIST 800-88R1

NIST 표준 800-88r1 은 세 가지 수준의 삭제를 지정합니다.

• 청결한: 비침습적인 회복 기술로부터 보호

• 제거 : 데이터 복구를 불가능하게 만듭니다.

• 파괴 : 데이터 복구를 불가능하게하고 향후 사용을 방지합니다.

표준의 섹션 2.6에서는 CE(Cryptographic Erase)의 사용과 Purge 수준을 충족하기 위해 적용할 수 있는 방법에 대해 설명합니다.

섹션 2.6.1 및 2.6.2에는 CE를 고려하지 말아야 하는 경우에 대한 조건이 나열되어 있습니다.

• 먼저 삭제하지 않고 중요한 데이터를 장치에 저장한 후 암호화가 활성화된 경우 CE를 사용하여 미디어를 제거하지 마세요.

• 암호화 전에 삭제하지 않고 중요한 데이터가 디바이스에 저장되었는지 여부를 알 수 없는 경우 CE를 사용하지 마세요.

• CE를 위한 모든 데이터가 미디어에 저장하기 전에 암호화되는 경우 CE를 사용하는 것이 좋습니다(데이터 및 가상화된 복사본 포함).

• 암호화 키가 저장되는 미디어의 위치(대상 데이터의 암호화 키 또는 연결된 래핑 키)를 알고 적절한 미디어별 삭제 기술을 사용하여 해당 영역을 삭제하여 키가 저장된 미디어의 실제 위치를 확인할 수 있는 경우 CE를 사용하는 것이 좋습니다.

• 대상 데이터를 암호화하는 데 사용되는 암호화 키의 모든 복사본이 삭제된다는 것을 알 수 있는 경우 CE를 사용하는 것이 좋습니다.

• 대상 데이터의 암호화 키 자체가 하나 이상의 래핑 키로 암호화되고 해당 래핑 키를 삭제할 수 있다고 확신하는 경우 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 가 활성 상태이며 사용 중입니다. 유형: LUKS1 암호: aes-xts-plain64 키 크기: 512비트 키 위치: dm-crypt 장치: /dev/loop5 루프: /mnt/base/image1/rwfs/config.img 섹터 크기: 512 오프셋: 4096 섹터 크기: 61440 섹터 모드: 읽기/쓰기

장치를 정기적으로 조작하는 동안 cryptsetup은 파일 시스템이 마운트되기 전에 파일 시스템의 암호를 해독하는 데 사용됩니다. 암호화 키가 삭제되면 더 이상 루프 장치를 설정하고 파일 시스템을 마운트할 수 없습니다.

우리가 사용하는 암호화 키는 ASCII 표현을 얻기 위해 sha1sum을 실행하는 /dev/urandom 에서 20바이트를 읽는 것입니다. 키는 공장 초기화 후 첫 번째 부팅 시 생성되며 새 공장 초기화가 수행될 때까지 변경되지 않습니다.

데이터 암호화 키 보호

우리는 장치에서 두 개의 다른 암호화 키를 사용합니다. 하나는 Android 컨테이너 내의 /data 파티션용(Microsoft MTR 및 Zoom용)용이고 다른 하나는 기타 파일 시스템용(고객 구성, 월페이퍼, 통화 기록, 기록 로그 등에 사용됨)용입니다.

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의 경우 마이그레이션은 이후 버전에서 수행됩니다.