피드백을 보내 주셔서 감사합니다.

보드, 데스크, 룸 시리즈 장치의 파일 시스템은 리눅스 하드 디스크 암호화의 표준인 리눅스 통합 키 설정 (LUKS) 으로 암호화돼요. 파일 시스템 암호화 키는 NVRAM이나 Nor-플래시에 저장돼요. 팩토리 리셋 중에는 키가 덮어써지고 복구할 수 없어서 디스크에 있는 어떤 것도 읽을 수 없게 돼요. 따라서 팩토리 리셋은 미국 국방부 5220.22M 및 NIST 800-88r1 준수에 따라 데이터를 삭제하고 제거하는 안전한 방법이에요.

팩토리 리셋 도중:

• 통화 기록이 삭제돼요.

• 암호가 기본값으로 초기화돼요

• 모든 장치 매개변수가 기본값으로 재설정돼요

• 기기에 업로드된 모든 파일이 삭제돼요.

• 이전 (비활성) 소프트웨어 이미지가 삭제돼요

• 옵션 키는 영향을 받지 않아요.

팩토리 리셋은 취소할 수 없어요. 시작하기 전에 꼭 필요한지 확인해 주세요.

NIST 800-88r1

NIST 표준 800-88r1에는 세 가지 수준의 위생 처리가 명시되어 있어요.

• 클린: 비침습적 복구 기법으로부터 보호하세요

• 제거: 데이터 복구를 불가능하게 만드세요

• 파기: 데이터 복구를 불가능하게 만들고 나중에 사용하지 못하게 하세요

표준 섹션 2.6에서 암호화 삭제 (CE) 의 사용과 삭제 수준을 충족하기 위해 적용하는 방법에 대해 설명해요.

섹션 2.6.1과 2.6.2에는 CE를 고려하지 말아야 할 시기에 대한 조건이 나열되어 있어요.

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

• 민감한 데이터가 암호화 전에 삭제되지 않고 장치에 저장되었는지 알 수 없으면 CE 사용하지 마세요.

• CE를 위한 모든 데이터를 미디어에 저장하기 전에 암호화할 때 CE 사용을 고려하세요 (데이터도 그렇고 가상화된 복사본 포함).

• 암호화 키가 저장되는 미디어 상의 위치 (대상 데이터의 암호화 키든 관련 래핑 키든) 를 알고 적절한 미디어별 삭제 기술을 사용하여 해당 영역을 살균하여 키가 저장된 미디어의 실제 위치를 확인할 수 있으면 CE 사용을 고려해 보세요.

• 대상 데이터를 암호화하는 데 사용되는 암호화 키의 모든 사본이 삭제된다는 것을 알게 되면 CE 사용을 고려해보세요.

• 대상 데이터의 암호화 키 자체가 하나 이상의 래핑 키로 암호화되어 있으면 CE 사용을 고려해보세요. 해당 래핑 키를 삭제할 수 있다고 확신해요.

• CE 작업을 수행하기 위해 장치에서 제공하는 명령을 사용자가 명확하게 식별하고 사용할 수 있다고 확신할 때 CE 사용을 고려해 보세요.

RoomOS에서는 고객 데이터에 사용되는 암호화된 파일 시스템이 중요한 데이터가 생성되기 전에 초기 부팅 초기에 설정되고 암호화돼요. 키는 위에서 설명한 대로 eeprom (구형 소프트웨어) 에 저장되거나 SoC의 신뢰 영역 메커니즘을 사용하여 저장되고 안전하게 삭제될 수 있어요.

키는 백업되지 않고 키 에스크로 메커니즘도 없어요.

이 모든 걸 염두에 두고 시스코는 RoomOS의 팩토리 리셋 메커니즘이 NIST 800-88r1의 퍼지 레벨을 준수한다고 주장해요.

고객 데이터 암호화

디스크 암호화예요.

장치들은 대용량 저장을 위해 플래시 장치를 사용하는데, 보안 삭제를 보장하기는 불가능해요. 따라서 장치의 모든 고객 데이터가 암호화된 파일 시스템에 저장되고 공장 기본값으로 재설정하면 암호화 키만 삭제되어 고객 데이터에 액세스할 수 없게 돼요.

이를 용이하게 하기 위해 메인 플래시에 적당한 크기의 파일을 만들고 표준 리눅스 도구인 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 표현을 구해요. 키는 팩토리 리셋 후 첫 부팅 시 생성되고 새 팩토리 리셋이 수행될 때까지는 변경되지 않아요.

데이터 암호화 키 보호

우리 기기에서는 서로 다른 암호화 키를 두 개 사용해요. 하나는 안드로이드 컨테이너 내부의 /data 파티션 (마이크로소프트 MTR 및 줌용) 이고 다른 파일 시스템 (고객 구성, 배경화면, 통화 기록, 기록 로그 등에 사용) 용이에요.

안드로이드 /data 파티션의 경우, 개인 키는 항상 Nvidia TrustZone 경계 내에 안전하게 저장되거나 SoC의 내장 암호화 메커니즘으로 암호화돼요. Room Navigator

ce-11.25.x까지 포함해서 다른 키는 EEPROM에 저장돼요. 일반 채널을 통해 오는 사용자는 EEPROM에 접근할 수 없지만 실제로 내용을 해독하기 위해 장치에서 (플래시 디스크와 함께) 강제로 제거하면 돼요.

ce-11.26.x부터 일반 파일 시스템 암호화 키를 ARM TrustZone [0] 기반의 엔비디아 신뢰 실행 환경 (TEE) 으로 옮기고 있어서 Nvidia SoC에서 키를 추출할 수 없어요. 보안 부팅 프로세스를 우회하는 유일한 (알려진) 방법은 전체 Nvidia SoC를 교체하여 키를 제거하는 것이므로 키 추출은 CE 코드의 취약점을 찾아 키를 얻을 수 있는 충분한 권한을 가진 루트 셸을 얻는 것으로 제한될 거예요.

왜냐하면 Room Navigator 마이그레이션은 이후 버전에서 할 거예요.