개인 키를 어디에 저장합니까?

소프트웨어의 일부를 암호화하고 싶다고 가정 해 봅시다. 예를 들어, 데이터베이스 등의 자격 증명은 해당 값을 어딘가에 저장해야하지만 일반 텍스트로 저장하면 공격자가 무단 액세스를 쉽게 얻을 수 있습니다.

그러나 일반 텍스트를 암호화하면 키를 어디에 저장합니까? 어떤 수준의 난독 화에 관계없이 소프트웨어가 액세스 할 수있는 모든 것을 결정된 공격자가 액세스 할 수 있습니다.

• 키가 파일 시스템의 보안 모델에 의해 보호된다고 가정하십시오. 그러나 (악의적 인) 수퍼 유저 또는 그러한 충실도를 제공하지 않는 플랫폼은 어떻습니까?
• 또는 키는 소프트웨어 바이너리로 하드 코딩되지만 항상 디 컴파일 될 수 있으며 오픈 소스 소프트웨어 또는 해석 된 코드는 어떻습니까?
• 키가 생성되면 그러한 알고리즘은 결정적이어야하고 (아마도) 동일한 문제가 시드에 적용됩니다.
• 기타

암호화는 체인에서 가장 약한 링크만큼이나 강력하며 이것은 꽤 느슨한 것 같습니다! 그것이 작업에 적합한 도구라고 가정하면 (어머니) 어떻게 그러한 정보를 강력하게 보호 할 수 있습니까?

작업에 적합한 도구와 관련하여 : 아마도 서비스 액세스 (DB, 인증 서버 등)의 경우 아마도 서비스 수준, 일부 서비스 수준의 경우이 계층에서 액세스를 제한합니다. 감사 등을 할 수 있으므로 일반 텍스트로 자격 증명을 갖는 것은 그렇게 걱정하지 않습니다.

그러나 나에게는 그것이 여전히 부적절 해 보입니다.

우선, 나는 자신을 보안 전문가라고 말하지는 않지만이 질문에 대답 해야하는 입장에 있습니다. 내가 알게 된 것은 조금 놀랐습니다 . 완전히 안전한 시스템은 없습니다 . 글쎄, 완전히 안전한 시스템은 서버가 모두 꺼져있는 시스템 일 것입니다 :)

당시 나와 함께 일한 누군가 가 침입자 에게 막대 를 올리는 관점에서 안전한 시스템을 설계하는 것을 설명했습니다 . 따라서 각 보안 계층은 공격의 기회를 줄입니다.

예를 들어 개인 키를 완벽하게 보호 할 수 있어도 시스템은 완전히 안전 하지 않습니다 . 그러나 보안 알고리즘을 올바르게 사용하고 패치를 최신 상태로 유지하면 막대가 높아집니다. 그러나, 강력하고 충분한 시간이 주어진 슈퍼 컴퓨터는 암호화를 깨뜨릴 수 있습니다. 나는이 모든 것이 이해된다고 확신하므로 질문을 다시받을 것입니다.

질문은 분명하므로 먼저 각 요점을 해결하려고 노력할 것입니다.

키가 파일 시스템의 보안 모델에 의해 보호된다고 가정하십시오. 그러나 (악의적 인) 수퍼 유저 또는 그러한 충실도를 제공하지 않는 플랫폼은 어떻습니까?

예, Windows 키 저장소 또는 암호로 암호화 된 TLS 개인 키 와 같은 것을 사용하면 개인 키에 대한 암호 (또는 액세스)가있는 사용자에게 노출됩니다. 그러나 나는 당신이 그 기준을 높이는 데 동의 할 것이라고 생각합니다. 파일 시스템 ACL (적절하게 구현 된 경우)은 상당히 우수한 보호 수준을 제공합니다. 그리고 수퍼 유저를 개인적으로 조사하고 알 수있는 위치에 있습니다.

또는 키는 소프트웨어 바이너리로 하드 코딩되지만 항상 디 컴파일 될 수 있으며 오픈 소스 소프트웨어 또는 해석 된 코드는 어떻습니까?

예, 바이너리로 하드 코드 된 키를 보았습니다. 다시, 이것은 바를 약간 올립니다. 이 시스템을 공격하는 사람 (Java 인 경우)은 Java가 바이트 코드 등을 생성한다는 것을 이해해야하며 디 컴파일 방법을 이해해야합니다. 기계 코드에 직접 쓰는 언어를 사용하는 경우 이로 인해 막대가 약간 높아지는 것을 알 수 있습니다. 이상적인 보안 솔루션은 아니지만 일정 수준의 보호 기능을 제공 할 수 있습니다.

키가 생성되면 그러한 알고리즘은 결정적이어야하고 (아마도) 동일한 문제가 시드에 적용됩니다.

예, 본질적으로 알고리즘은 개인 키를 만들기위한 개인 키 정보가됩니다. 따라서 이제 보호해야합니다.

따라서 보안 정책, 키 관리 와 관련된 핵심 문제를 파악했다고 생각합니다 . 보안 시스템을 제공하려면 핵심 관리 정책을 마련해야합니다. 그리고 그것은 꽤 광범위한 주제 입니다.

문제는 시스템 (및 개인 키)이 얼마나 안전해야합니까? 시스템에서 막대를 얼마나 높이 올려야합니까?

이제, 기꺼이 지불한다면, 거기에 해결책을 제시하는 사람들이 있습니다. 우리는 HSM (Hardware Security Module)을 사용했습니다 . 기본적으로 하드웨어 키가 포함 된 변조 방지 서버입니다. 그런 다음이 키를 사용하여 암호화에 사용되는 다른 키를 만들 수 있습니다. 여기서 아이디어는 (올바르게 구성된 경우) 키 가 HSM을 떠나지 않는다는 것 입니다. HSM 은 많은 비용이 듭니다 . 그러나 일부 비즈니스에서는 신용 카드 데이터를 보호하면 위반 비용이 훨씬 높습니다. 균형이 있습니다.

많은 HSM은 기능 유지 관리 및 관리에서 키 카드를 사용합니다. 키를 변경하려면 쿼럼 키 카드 (5/9는 실제로 서버에)를 넣어야합니다. 따라서 이것은 수퍼 유저 쿼럼이 충돌하는 경우에만 위반을 허용함으로써 막대를 상당히 높입니다.

HSM과 유사한 기능을 제공하는 소프트웨어 솔루션이있을 수 있지만 그 기능이 무엇인지 모르겠습니다.

나는 이것이 질문에 대답하는 데 도움이되는 방법이라는 것을 알고 있지만 이것이 도움이되기를 바랍니다.

당신이 원하는 것은 할 수 없습니다.

키가 파일 시스템의 보안 모델에 의해 보호된다고 가정하십시오. 그러나 (악의적 인) 수퍼 유저 또는 그러한 충실도를 제공하지 않는 플랫폼은 어떻습니까?

당신은 기본적으로 악의적 인 사람들로부터 보호를 원합니다. 모델에서는 어느 시점에서 누군가 키에 액세스 할 수 있습니다. 그 사람이 악의적 인 경우 어떻게해야합니까? 악의적 인 경우 어떻게해야합니까? 키가 전혀없는 경우를 제외하고는 상태에 따른 문제를 해결할 수 없습니다.

따라서 데이터베이스 자격 증명이 아닌 다른 인증 메커니즘으로는 작동하지 않습니다. 그러나 무엇이든 어떤 시점에서 누군가 데이터에 액세스해야하며 누군가 악의적 일 수 있습니다.

이것은 실제로 생성 된 것과 동일한 수준에서 해결할 수없는 문제 중 하나입니다. 우리는 몇 가지 기본 철학으로 돌아가서 해결책을 찾기 위해 계단식을 따라야합니다.

첫 번째 철학은 "고객을 절대 믿지 말라"는 것과 밀접한 관련이 있습니다. "만약 당신이 정말로 비밀을 지키고 싶다면 아무에게도 말하지 마십시오!"

간단한 예로 데이터베이스 자격 증명이 있습니다. 분명히 클라이언트가 임의의 인터넷 낯선 사람에게 액세스 할 수 있기를 원하므로 일종의 신원 / 확인 / 로그인 시스템이 필요합니다. 그러나 이것을 숨기는 핵심 전제는 문제입니다. 만약 사용자 자신이 비밀을 가지고 있어야하지만, 그 비밀이 무엇인지 알기를 원하지 않는다면, 당신이 할 수있는 일은 그것을 숨기거나 그들이 열기 어렵게 만드는 것입니다. " 비밀 패키지 ". 그러나 그들은 여전히 ​​알아낼 수 있으므로 백업 계획을 세우는 것이 좋습니다!

가장 쉬운 해결책은 "하지 마십시오"입니다. 사용자 자신의 계정 자격 증명을 사용하여 소프트웨어의 데이터베이스에 대한 클라이언트 수준 액세스를 허용하십시오. 클라이언트가 악의적 일 경우 최악의 시나리오는 클라이언트가 자신의 데이터를 망칠 수 있다는 것입니다. 그게 다야. 데이터베이스와 시스템에는 이제 최대 한 명의 고객 만 포함하여 해당 클라이언트의 정크 항목이 포함되어 있어야합니다.

배포 된 소프트웨어 만 무언가를 수행하기를 원하지만 전 세계의 모든 사람이 동일한 작업을 연결하고 수행 할 수는 없지만 특정한 비밀을 숨기고있는 유일한 유스 케이스가 있습니다. 두통이나 시스템 활동을 줄입니다. 숨겨진 정보가 상식이되면 최악의 성가심에서 게임을 깨뜨리지 않는 것이 좋습니다.

좁은 사용 사례 중 하나에 속하면 난독 화에 관한 것입니다. 그것은 당신이 퍼즐을 만드는 사람을 제외하고는 Code Golf와 매우 흡사합니다. 그게 전부입니다-퍼즐. 사람들은 퍼즐 풀기를 좋아하기 때문에 누군가 알아낼 때 다시 확인하는 것이 좋습니다.

그러나 전 세계 대부분의 경우 사용자 로부터 비밀을 지키지 않아도 걱정하지 않는 것이 가장 좋습니다 . 대신 모범 사례는 사용자를 비밀로 유지하고, 사용자 이름과 암호 등을 보호하고, 비밀이 유출되거나 악용 될 경우 발생할 수있는 단점을 제한하는 것입니다.

진정한 "키 관리"암호화 / 보안 컨텍스트에서 "개인 키 저장 위치"의 대답은 "다른 곳"입니다. 암호화는 지점 간 보호이며 공개-개인 키 암호화는 시간과 공간을 통해 전송되는 정보를 보호하도록 설계되었습니다. 개인 키는 본질적으로 취약하며이를 보호하는 것은 실제로 암호화가 겹치는 문제가 아니라 액세스를 완전히 차단합니다. 또한 시스템이 시스템에 액세스해야하는 경우 시스템 자체가 보안되어야하며 클라이언트 시스템에서 시스템을 수행 할 수 없습니다. 그들은 항상 VM을 실행하고, RAM을 덤프하고, 네트워크 트래픽을 스니핑하고, 프록시 또는 가상 NIC를 설치하고, 실행 파일을 디 컴파일 할 수 있습니다.

이제 비밀을 저장해야하는 것이 실제로 소프트웨어 자체의 사용을 제어하는 ​​데 기반한 DRM과 같은 작업을 수행해야하는 경우 이는 전적으로 다른 상황 입니다.

TLDR : 사용자로부터 비밀을 유지하지 말고 사용자와 비밀을 유지하십시오.

현재 사용중인 시스템 중 하나가 이런 식으로 작동합니다.

• 인증 서비스의 로그인 양식으로 시작합니다. 그것은 내가 주장하는 사람인지 확인하기 위해 이중 인증을 사용합니다.
• 보호 된 서비스에 액세스하는 데 사용할 수있는 임시 SSL 인증서를받습니다. 서비스는 승인 한 인증서를 추적합니다.
• 교환은이 인증서에 의해 도청으로부터 암호화됩니다. 균열을 시도하면 만료되기 때문에별로 유용하지 않습니다.
• 인증서가 몇 시간 안에 빨리 만료되지만 너무 빠르지 않으므로 모든 상호 작용에 암호를 제공 할 필요가 없습니다.
• 다른 쪽에서 인증서를 즉시 취소 할 수 있습니다.

물론 보호 된 서비스는 내가 접근 할 수없는 곳에서 실행됩니다. 내 컴퓨터에서 다른 계정 (및 컨테이너)에서 실행될 수 있지만 수퍼 유저 권한이 있으며 제한을 우회하려고 할 수 있습니다.

기본적으로 악의적 인 수퍼 유저 인 경우 모든 베팅이 해제됩니다. 또한 위협 모델에 악의적 인 수퍼 유저 가 있다고 가정 해야합니다 .

따라서 보호 된 서비스를 클라이언트 액세스 가능 시스템과 격리해야합니다. 보호 된 서비스를 네트워크를 통해서만 액세스 할 수있는 시스템으로 이동하십시오. 보호 된 서비스가 실행되는 나머지 실제 시스템에 도달하지 못하게하는 가상 시스템에 클라이언트를 배치하십시오.

보호 된 서비스가 그러한 조치를 명령 할만큼 귀중하지 않은 경우, OS가 제공하는 암호화 된 키 저장소를 사용하십시오. Windows, Linux 및 OSX 모두 키링 구현을 갖습니다.

내 마음에, 이것을 완전히 안전하게 유지하는 유일한 방법은 암호를 사용하여 키 / 암호를 암호화하여 잠금을 해제하는 것입니다. 이런 식으로 암호를 시작하거나 사용할 때마다 암호를 제공해야합니다. 너무 유용하지 않습니다.

다른 방법으로는 보안 시스템이 자체 데이터베이스 계정이 될 수 있습니다. 확장 성이 좋지 않다 ...

시스템의 각 사용자가 자신의 DB 계정을 가지고 있고 해당 계정이 사전에 만들어 져서 응용 프로그램이 사용자를 대신하여 DB에서 계정을 만들 수있는 권한이없는 경우에도 매우 가깝습니다. 좋은 해결책도 아니므로 구성 파일에 대한 읽기 액세스가 매우 제한되어 있고 슈퍼 사용자를 신뢰해야한다고 생각합니다.