임베디드 장치의 메모리에 보안 키 저장


10

데이터를 송수신하는 내장 장치에서 암호 텍스트 모드 (암호화 모드)로 저장하고 있습니다. 이제 키를 저장하는 가장 좋은 방법은 무엇입니까 (ARM CORTEX M 시리즈 MCU를 사용했습니다)?

1-SRAM 메모리 및 각 부팅 순서에 키를 저장하면 키를 내장 MCU에 주입하여 SRAM 메모리에 저장합니다. 그것은 내가 생각하는 가장 좋은 방법입니다. MCU 감지 침투 (탬퍼 센서 또는 ...)는 SRAM을 빠르게 지우고 스스로 재설정 할 수 있습니다. 단점 : 공격자가 변조 및 장치 액세스를 통과하면 SRAM 메모리가 얼마나 안전합니까 (코드 마이닝). MCU에서이 메모리에 대한 보안 기능을 찾을 수 없습니다.

키를 2 개 생성하고 프로그래밍 MCU의 플래시 메모리에 저장합니다. 코드 마이닝을 방지하고 내부 AES 엔진 및 RNG (임의 숫자 생성) 엔진을 지원하는 MCU 플래시 메모리의 CRP (코드 읽기 보호) 지원 랜덤 키를 생성하고 플래시 메모리를 암호화하고 해당 랜덤 키를 OTP ( 1 회 프로그램 가능 메모리-128 비트 암호화 메모리), 코드 실행시 RNG 키로 플래시 메모리를 디코딩하고 초기 키 및 코드에 액세스합니다. 단점 : 비 휘발성 메모리에 저장된 키, 탬퍼는 쓸모없고 공격자는 키를 채굴하는 데 많은 시간이 있습니다.

EEPROM 메모리에 3- 저장된 키, 위의 접근 방식 2의 조합, 비 휘발성 메모리에 저장된 키.

LPC18S57FBD208 (1MB 플래시 메모리, 180MHZ, 136KB SRAM, 16KB EEPROM 및 TFT LCD 컨트롤러가있는 7 인치 TFT LCD 및 AES 128 비트 암호화 엔진을 구동해야하는 Cortex m3)을 고려하면 더 나은 제안이 있습니까?

답변:


18

이러한 옵션은 모두 매우 안전하지 않기 때문에 다른 옵션보다 낫거나 나쁜 것은 없습니다. 옵션 4를 사용하겠습니다.

  1. SRAM은 키를 보관하기에 가장 안전한 장소이지만 외부에서 키를 주입해서는 안됩니다. 부팅하는 동안 항상 프로세서 내에서 생성되어야합니다. 다른 작업을 수행하면 나머지는 즉시 무효화됩니다. 자동으로 안전하지 않습니다.

  2. 비 휘발성 메모리에 키를 저장하지 마십시오. EEPROM 또는 플래시 메모리가 읽히지 않도록 보호하는 것은 중요하지 않습니다. 이 코드 읽기 보호 퓨즈는 쉽게 반전됩니다. 공격자는 제거해야합니다 (실리콘 다이 내부에 노출되도록 검은 에폭시 포장을 제거하거나 화학적으로 에칭). 이 시점에서, 이들은 비 휘발성 메모리 셀인 다이 부분 (이 섹션은 매우 규칙적이며 개별 메모리 셀은 크기가 매우 작지만 더 큰 구조 일 수 있음)과 작은 부분을 덮을 수 있습니다. UV에 불투명 한 부분은 해당 부분에 가려져 있습니다. 그런 다음 공격자는 5-10 분 동안 칩에 UV 광선을 비추고 CRP 퓨즈를 포함한 모든 퓨즈를 재설정 할 수 있습니다. 이제 표준 프로그래머가 OTP 메모리를 읽을 수 있습니다.

또는 그들이 자금을 잘 모으면 (예를 들어, 열쇠를 누군가에게 1000 달러 이상 가져가는 등), 여러 유형의 전자 현미경으로 메모리 셀을 직접 읽을 수 있습니다.

보안을 유지하려면 숨기지 말고 키를 지워야합니다.

  1. 아니요, 위와 같은 이유로 말입니다.

이제 옵션 4로 넘어갑니다.

  1. 암호화 만 사용하십시오. 키 분배는 해결 된 문제입니다. 따라서 즉시 사용 가능한 솔루션을 사용하십시오. 칩은 RNG를 사용해야하며, 충분한 엔트로피를 공급할 수 있도록 다양한 기타 사항을 고려해야하며, 부트 로더는 필요한 비밀 키를 생성하는 프로그램으로 직접 부팅해야합니다. 레지스터와 SRAM으로 직접 이동하여 지울 때까지 유지됩니다.

그러나 CPU를 제외하고는 비밀 키가 무엇인지 전혀 모른다는 문제가 있습니다. 문제 없습니다 : 공개 키 암호화를 사용하십시오. OTP 메모리에 저장 한 것은 공개 키입니다. 이 키는 누구나 읽을 수 있으며 스택 교환에 게시 할 수 있으며 5 피트 높이의 문자로 유조선 측면에 페인트 할 수 있습니다. 공개 키 암호화의 놀라운 점은 비대칭이라는 것입니다. 무언가를 암호화하는 키는 해독 할 수 없으며 개인 키가 필요합니다. 반대로, 공개 키로 암호화 된 것을 해독하는 키는 무언가를 암호화하는 데 사용될 수 없습니다. 따라서 CPU는 비밀 키를 생성하고 저장된 공개 키를 사용하여 비밀 키를 암호화 한 다음 USB 또는 RS232 또는 원하는대로 전송합니다. 비밀 키를 읽으려면 개인 키가 필요합니다. 칩에 저장, 전송 또는 전혀 관여 할 필요가 없습니다. 비밀 키가 개인 키 (칩 외부의 다른 곳)로 해독되면 설정됩니다. 앞에서 언급했듯이 공개 키를 제외한 다른 것을 저장하지 않고 칩 내에서 완전히 생성 된 안전하게 전송 된 비밀 키가 있습니다.

이 프로세스를 공식적으로 키 협상이라고하며 모든 것이 사용합니다. 오늘 여러 번 사용했습니다. 처리 할 수있는 많은 리소스와 라이브러리가 있습니다. 아무 것도 키를 '주입'하지 마십시오.

마지막으로 언급 할 사항 : AES 키는 전원 공급 장치에 앉아 전류 소모의 미세한 변화와 CPU의 비트 플립으로 인한 변화 사이의 타이밍을 측정하는 사이드 채널 공격을 사용하여 쉽게 복구 할 수 있기 때문에 문제가됩니다. 레지스터로. 이는 AES (또는 사용 가능한 매우 작은 암호화 알고리즘 중 하나)가 어떻게 작동하는지에 대한 지식과 결합하여 키를 복구하는 것이 상대적으로 쉽고 저렴합니다. 키를 읽을 수는 없지만 키 공간을 255 개의 가능한 키와 같이 엄청나게 작은 것으로 좁힐 수 있습니다. 이 칩은 상류이기 때문에이를 감지 할 수 없습니다.

이것은 '보안'암호화 프로세서에서 AES-256 암호화 부트 로더를 물리 쳤으며 그렇게 어렵지는 않습니다. 내가 아는 한,이 공격에 대한 진정한 하드웨어 대응책은 없습니다. 그러나 암호화 알고리즘 자체이며 비트를 뒤집기 위해 CPU가 필요한 방식으로 인해이 취약점이 발생합니다. 사이드 채널 저항 또는 사이드 채널 증명 알고리즘을 개발해야 할 것으로 생각합니다.

따라서 현재로서는 임베디드 장치에 키를 안전하게 저장하거나 임시 키를 사용하는 방법에 대한 진정한 해답은 다음과 같습니다 .

그러나 적어도 옵션 4의 키 협상을 사용하여 매번 새 키를 생성하는 경우 사이드 채널 공격은 사용중인 채널의 키만 손상시킬 수 있으며 데이터를 암호화하는 동안 전원을 모니터링해야하는 시간이있는 경우에만 가능합니다 . 내부적으로 생성 된 새 키를 자주 협상하는 경우 유용한 보안이 제공 될 수 있습니다.

키를 생성하고 가능한 한 짧은 시간 동안 저장하십시오.


감사의 말을 전하는 Metacollin에게 감사드립니다. 그러나 내 프로젝트는 많은 독자 (mcu 포함)와 많은 대상 MCU로 구성되어 있으며 각 독자는 모든 대상을 읽을 수 있어야하며 모든 대상은 모든 독자가 읽을 수 있어야합니다. 이 중 데이터 전송을위한 고유 키에 동의해야한다고 생각합니다. 귀하의 답변에 따라 LPC18S57 보안 피질 m3과 STM32F429 일반 피질 m4 및 심지어 LPC1788 일반 피질 m3 (저렴한 선택) 사이에는 큰 차이가 없다고 생각합니다. 이것은 내가 할 수있는 한 안전합니다.
Mahmoud Hosseinipour

2
"AES 키를 쉽게 복구 할 수있다"는 진술은 적어도 의심 스럽다. 현재 소비량을 기준으로 프로세서에서 발생하는 작업을 찾는 기술의 원리를 이해합니다. 그러나 CPU가 작업하는 유일한 것은 암호화 및 암호 해독이라고 가정합니다. 그러나 대부분의 응용 프로그램에는 동시에 여러 작업에서 작동하는 CPU가 1 개뿐입니다. 한 블록 동안 AES 암호화에는 수십 또는 수백 개의 인터럽트가 발생하여 현재 피크를 기반으로 키를 찾을 수 없습니다.
bakcsa83

2
키를 플래시에 저장하지 않으면 키를 생성하는 코드도 마찬가지입니다. 연산 코드를 어셈블러로 변환하면 코드가 아무리 복잡해도 키가 있습니다.
Lundin

The wonderful thing about private key cryptography is that it is asymmetric. 귀하의 게시물 에서이 사실을 알고 있음에도 불구하고 다른 독자들에게 위의 인용문에서 s / private / public을 언급 할 것입니다.
Radian

방법 4를 사용하여 두 장치간에 채널을 보호 할 수는 있지만 공유 비밀 형식이 없으면 통신중인 장치의 진위를 보장 할 수 없습니다. 사용 사례에 인증이 필요한 경우 단일 공유 암호를 플래시에 저장하는 것보다 키 교환을 사용하는 것이 좋습니다. 더 나은 보안이 필요한 경우 암호화 칩을 사용해야합니다.
Greg
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.