Linux 5.4.31 커널을 실행하는 IoT 게이트웨이가 있습니다. 이러한 게이트웨이는 각각 고유한 암호화 키가 있는 수천 대의 모바일 장치를 관리해야 합니다. 장치가 범위 내에 들어올 때 (보안 채널을 통해) 서버에서 장치의 키를 가져와서 장치가 범위 내에 있는 동안 암호 해독에 사용하고 장치가 나갈 때 메모리에서 키를 제거하는 것이 아이디어입니다. 수신된 데이터를 기반으로 특정 작업을 수행해야 하기 때문에 복호화는 게이트웨이에서 수행되어야 합니다.
우리는 키에 액세스할 때마다 키를 해독할 필요가 없기 때문에 암호화되지 않은 키를 RAM에 저장하려고 합니다. 우리는 다음과 같은 가정을 가지고 있습니다:
- 게이트웨이에 물리적으로 접근할 수 없습니다.
- 서비스는 루트가 아닌 사용자로 실행됩니다.
- 공격자는 루트가 아닌 사용자(중요한 경우 서비스 사용자와는 다름)로 게이트웨이에 액세스할 수 있습니다.
- 공격자는 버퍼 오버플로 공격을 수행할 수 있습니다.
이러한 가정 하에서 공격자가 RAM의 암호화 키에 액세스하기 위해 사용할 수 있는 옵션은 무엇입니까?
- (스택이 아닌 C의 static 키워드를 통해) 정적으로 할당된 메모리에 키를 저장합니다.
- 우리는 동적으로 할당된 메모리에 키를 저장합니다(리소스가 제한되어 있으므로 일회성 할당일 수 있음).
또한 루트가 아닌 사용자에게 프로세스 RAM에 대한 액세스를 방지하기 위해 스왑 메모리, 코어 덤프, 패키지 설치, gdb 사용 등에 대한 액세스를 허용하지 않는 등 어떤 제한 사항을 적용해야 합니까?
참고: 공격자가 루트 액세스 권한을 갖고 있는 경우 서버 액세스에 사용되는 개인 키를 사용하여 모든 키에 액세스할 수 있으므로 이 문제에 대해서는 이 시나리오를 고려하지 않습니다.
답변1
더 나은 답변을 얻을 수도 있습니다정보보안 SE.
관련 메모리 범위를 잠가서 키가 스왑에 기록되지 않도록 해야 합니다(참조:mlock
); 키에 메모리 풀을 할당하면 더 쉽습니다.
또한 루트가 아닌 사용자에게 프로세스 RAM에 대한 액세스를 방지하기 위해 스왑 메모리, 코어 덤프, 패키지 설치, gdb 사용 등에 대한 액세스를 허용하지 않는 등 어떤 제한 사항을 적용해야 합니까?
루트가 아닌 사용자는 어쨌든 스왑 영역에 액세스할 수 없습니다. 메모리의 키를 잠그면 문제를 완전히 피할 수 있습니다. 루트가 아닌 사용자는 자신의 프로세스에서 생성된 것 이외의 코어 덤프에 액세스할 수도 없습니다.ptrace
다른 사용자의 프로세스(즉, gdb
다른 프로세스의 메모리를 보기 위해 실행할 수 없음을 의미)
CPU가 필요한 기능을 제공하는 경우 사용을 고려할 수 있습니다.pkeys
추가 보호를 위해. 또 다른 가능성은 키 처리를 커널에 전적으로 위임하는 것입니다.이 keyrings
페이지더 알아보기.