Thick Client 애플리케이션에서 API 비밀 키 보호

Question

애플리케이션 내에서 API 호출에 대한 해시를 계산하는 데 사용되는 비밀 키가 있습니다..NET 애플리케이션에서는 Reflector와 같은 프로그램을 사용하여 어셈블리에서 정보를 가져와 이러한 키를 포함하는 것이 매우 쉽습니다.

어셈블리를 난독화하는 것이 이러한 키를 보호하는 좋은 방법입니까?

Answer 1

아마 없을 것입니다.

암호화 및 Windows의 기본 제공 정보 숨김 메커니즘 (예 : DPAPI 및 ACL 제한 레지스트리 키에 키 저장)을 살펴 봅니다.애플리케이션과 동일한 시스템을 유지하는 데 필요한 보안을 위해 얻을 수있는 것만 큼 좋습니다.

기계에 물리적으로 앉아있는 누군가가 귀하의 정보를 얻는 것을 막을 방법을 찾고 있다면 잊어 버리십시오.누군가가 결정되고 사용자가 제어 할 수없는 컴퓨터에 제한없이 액세스 할 수있는 경우 데이터가 모든 상황에서 보호된다는 것을 100 % 확신 할 수있는 방법은 없습니다.단호한 사람이 원하면 얻을 수 있습니다.

Answer 2

난 그렇게 생각하지 않을 것입니다. 난독화(적어도 제가 이해하는 바에 따르면)는 코드를 이해하기 어렵게 만들기 위해 메소드 이름을 어지럽힐 뿐이기 때문입니다(불가능하지는 않습니다).이것은 실제 키의 데이터를 변경하지 않습니다(어딘가에 상수에 저장되어 있는 것으로 추측됩니다).

보기 좀 더 어렵게 만들고 싶다면 일반 텍스트(ROT-13 등)에 대해 간단한 암호를 실행하여 최소한 코드 자체에 일반 텍스트로 저장되지 않도록 할 수 있습니다.하지만 그렇다고 해서 결단력 있는 해커가 귀하의 키에 액세스하는 것을 막지는 못할 것입니다.더 강력한 암호화 방법은 해당 키를 코드에 저장해야 하고 이를 보호할 방법이 없기 때문에 도움이 되지 않습니다.

제가 생각할 수 있는 유일한 보안 방법은 어떻게든 애플리케이션 외부에 키를 보관한 다음 키에 대한 액세스를 제한하는 것입니다.예를 들어 키를 별도의 파일에 보관한 다음 OS 수준 사용자 기반 제한으로 파일을 보호할 수 있습니다.아마도 효과가 있을 것입니다.데이터베이스 연결에서도 동일한 작업을 수행할 수 있습니다(다시 말하지만, 인증되지 않은 사용자를 데이터베이스에 접근하지 못하도록 사용자 기반 액세스 제한을 사용함).

내 앱에 이 작업을 수행하는 아이디어를 생각해 봤지만 구현한 적은 없습니다.

Answer 3

DannySmurf는 응용 프로그램을 실행하는 사람에게서 키를 숨길 수 없다는 것이 맞습니다.애플리케이션이 키에 접근 할 수 있다면 그 사람도 접근 할 수 있습니다.

그러나 정확히 무엇을 이루고자하십니까?

무엇 이냐에 따라 단순히 사용자의 컴퓨터에 비밀 "비밀"을 유지하는 데 의존하지 않고 목표를 달성하는 방법이 종종 있습니다.

Answer 4

여기에서 경기 후반 ...

어셈블리 / 어셈블리 구성에 키를 저장하는 방법은 근본적으로 안전하지 않습니다. 결정된 사용자가 액세스 권한을 갖게되므로이를 저장할 수있는 철칙 한 방법은 없습니다. 나는 당신이 지구상에서 가장 / 가장 비싼 난독 화 제품을 사용하는지 상관하지 않습니다. PDAPI를 사용하여 데이터를 보호하더라도 상관 없습니다. 로컬 OS 보호 키 저장소를 사용하더라도 상관 없습니다 (이것이 더 좋습니다). 모든 사람이 동일한 핵심 문제를 겪고 있으므로 이상적인 것은 없습니다. 사용자가 키에 액세스 할 수 있으며 며칠, 몇 주, 어쩌면 몇 달, 몇 년 동안 변경되지 않고 그대로 유지됩니다.

훨씬 더 안전한 접근 방식은 시도 된 진정한 PKI로 API 호출을 보호하는 것입니다. 그러나 API 호출이 수다 스러우면 성능 오버 헤드가 분명하지만 대부분의 애플리케이션에서 이는 문제가되지 않습니다.

성능이 우려되는 경우 비대칭 PKI를 통해 Diffie-Hellman을 사용하여 AES와 같은 암호와 함께 사용할 공유 비밀 대칭 키를 설정할 수 있습니다. 이 경우 "공유"는 모든 클라이언트 / 사용자가 아닌 클라이언트와 서버간에 공유됨을 의미합니다. 하드 코딩 / 베이킹 된 키가 없습니다. 어디서나.

키는 일시적이고, 사용자가 프로그램을 실행할 때마다 재생성됩니다. 또는 정말로 편집증이있는 경우 타임 아웃되어 재생이 필요할 수 있습니다.

계산 된 공유 비밀 대칭 키 자체는 SecureString의 메모리에만 저장됩니다. 추출하기 어렵고 추출하더라도 매우 짧은 시간 동안 만 유용하며 특정 클라이언트 (예 : 해당 세션) 간의 통신에만 유용합니다. 즉, 누군가 자신의 로컬 키를 해킹하더라도 로컬 통신을 방해하는 데만 유용합니다. 코드 / 구성을 통해 모든 사용자가 공유하는 기본 키와 달리 다른 사용자에게 영향을주는 데이 지식을 사용할 수 없습니다.

또한 전체 키 자체는 네트워크를 통해 전달되지 않습니다. 클라이언트 Alice와 서버 Bob이 독립적으로 계산합니다. 이를 수행하기 위해 전달하는 정보는 이론적으로 제 3 자 Charlie가 가로 챌 수 있으므로 공유 된 비밀 키를 독립적으로 계산할 수 있습니다. 그렇기 때문에 Alice와 Bob 사이의 키 생성을 보호하기 위해 비대칭 PKI를 사용하는 것입니다.

이러한 시스템에서 키 생성은 종종 인증 및 세션 생성과 결합됩니다. PKI를 통해 "로그인"하고 "세션"을 만들고, 완료되면 클라이언트와 서버 모두 해당 세션의 모든 후속 통신에 대해 더 빠른 암호화에 사용할 수있는 대칭 키를 독립적으로 갖게됩니다. 대규모 서버의 경우 모든 작업에 대해 TLS를 사용하는 것보다 해독시 컴퓨팅주기를 절약하는 것이 중요합니다.

하지만 잠깐 : 아직 안전하지 않습니다. 메시지 읽기만 차단했습니다.

중간자 (man-in-the-middle) 조작을 방지하려면 메시지 다이제스트 메커니즘을 사용해야합니다. 아무도 전송되는 데이터를 읽을 수는 없지만 MD가 없으면 수정을 방해 할 수 없습니다. 따라서 암호화하기 전에 메시지를 해시 한 다음 메시지와 함께 해시를 보냅니다. 그런 다음 서버는 해독시 페이로드를 다시 해시하고 메시지의 일부인 해시와 일치하는지 확인합니다. 메시지가 전송 중에 수정 된 경우 수정되지 않으며 전체 메시지가 삭제 / 무시됩니다.

방어해야하는 마지막 메커니즘은 리플레이 공격입니다. 이 시점에서 사람들이 데이터를 읽거나 데이터를 수정하는 것을 막았지만 단순히 다시 보내는 것을 막지는 않았습니다. 이것이 애플리케이션에 문제인 경우 프로토콜은 데이터를 제공해야하며 클라이언트와 서버 모두 재생을 감지 할 수있는 충분한 상태 정보를 가지고 있어야합니다. 이것은 암호화 된 페이로드의 일부인 카운터처럼 간단한 것일 수 있습니다. UDP와 같은 전송을 사용하는 경우 proba

bly는 이미 중복 된 패킷을 처리하는 메커니즘을 가지고 있으므로 이미 재생 공격을 처리 할 수 있습니다.

분명해야 할 것은이 문제를 바로 잡는 것이 쉽지 않다는 것입니다.따라서 절대 불가능하지 않는 한 PKI를 사용하십시오.

이 접근 방식은 더 높은 확장 성을 달성하기 위해 각 플레이어에게 가능한 한 적은 컴퓨팅을 사용하는 동시에 해킹 / 탐구의 보안을 제공하는 것이 매우 바람직한 게임 산업에서 많이 사용됩니다.

결론적으로 이것이 정말로 우려되는 일이라면 API 키를 안전하게 저장하는 대신에 그렇게하지 마십시오.대신 앱에서이 API를 사용하는 방식을 변경하십시오 (당연히 양쪽을 모두 제어 할 수 있다고 가정).PKI를 사용하거나 PKI가 너무 느릴 경우 PKI 공유 대칭 하이브리드를 사용합니다 (요즘 거의 문제가되지 않음).그러면 보안 문제가되는 내용이 저장되지 않습니다.