제가 설정하고 싶은 서비스의 디자인에 관한 질문입니다.
설명하다
내 의도는 서버에 연결하고 일부 기능을 제공하는 클라이언트 상자를 제공하는 것입니다.
클라이언트 상자는 복사를 방지하려는 일부 파일(보안 키 또는 실행 파일과 같은 정보)이 포함된 임베디드 시스템을 포함하는 OLinuXino 또는 Raspberry-Pi와 같은 소형 컴퓨터입니다.
서버는 서비스의 중앙화된 부분입니다.
보호되는 파일 크기: 1kB ~ 500kB.
클라이언트 상자에는 읽기 전용이고 tmpfs로 설정되는 Debian(wheezy) 시스템이 포함됩니다(그림 참조).여기).
어떻게 보호하고 싶나요?
시스템에는 호기심이 많은 눈으로부터 숨기고 싶은 일부 구성 및 실행 파일이 포함되어 있습니다. 따라서 고도로 암호화됩니다.
클라이언트 상자가 서버에 연결되고 역방향 SSH 터널(서버에서 클라이언트로)을 열므로 서버는 일부 인증 후에 (서버 측 키를 사용하여) 파일의 암호를 해독할 수 있습니다. 해독된 파일은 클라이언트가 종료될 때까지 클라이언트의 RAM에 남아 있습니다.
이 클라이언트 상자는 헤드리스(화면 없음, 키보드 없음)이고 완전히 자동화되지만 사용자가 무슨 일이 일어나는지 보기 위해 화면이나 키보드를 연결하려고 시도하지 않을지 확신할 수 없습니다.
그래서 서버가 클라이언트에 키보드나 화면이 연결되어 있지 않은지 확인하기를 원합니다. 따라서 (서버에서 클라이언트로 ssh 원격 호출을 통해) 일부 명령을 호출합니다.
- 일련 번호, MAC 주소, 특정 파일 체크섬 및 기타 시스템 관련 정보를 확인하여 클라이언트 상자가 손상되지 않았는지(또한 전체 파일 시스템이 다른 시스템에 복사되지 않았는지) 확인하십시오.
- 키보드가 연결되어 있는지 감지하고 결국 차단합니다.
- 열려 있는 모든 사용자 세션을 닫습니다.
- 새로운 연결(키보드, 새 세션, 장치)을 차단합니다.
- 화면이 연결되어 있는지 감지하고 출력이 표시되지 않도록 합니다.
그 후, 서버는 RAM에 있는 파일을 원격으로 해독합니다.
내 첫 번째 질문: 이것이 내 파일을 숨기는 안전한 방법이라고 생각하시나요? 내가 놓친 게 무엇입니까?
내 두 번째 질문: 위 목록의 항목 1, 2, 3에 대해서는 이 방법을 찾을 것이라고 확신합니다. 하지만 항목 4와 5에 대해서는 확실하지 않습니다. 의견 있으십니까? 아니면 단순히 불가능하다고 생각하시나요?
어떤 제안이라도 환영합니다(예: "하지 마세요. 바보 같군요." 또는 "해 보세요. 효과가 있을 것입니다.")!
답변1
멈출 수 없는 것들이 있는 것 같아요.
귀하의 집에서는 클라이언트의 플래시 드라이브에 2개의 파티션을 사용했습니다. 첫 번째는 부팅에 사용되며 최소한의 C 프로그램을 로드합니다. 이 최소 C 프로그램은 서버에 접속하여 두 번째 파티션에 대한 디코딩 키를 얻습니다. 이 전체 프로세스는 initrd에서 실행됩니다.
성공적으로 디코딩되면 시스템의 두 번째 실제 파티션을 사용할 수 있습니다.
가장 중요한 것은 보안을 손상시킬 수 있는 커널 및 사용자 공간 소프트웨어에서 모든 것을 제거하는 것입니다.
(유사하지만 보안에 초점을 맞춘 관점에서 security.stackexchange.com에서 비슷한 질문을 할 수도 있습니다.)
답변2
라고 말씀하시면 더 좋은 답변을 받으실 수 있을 것입니다무엇대신에 정확히 당신이 하고 싶은 일을어떻게당신은 이것을 하고 싶어합니다. 즉, 다음과 같습니다:초콜렛 바나나를 내려놓고 유럽 통화 시스템에서 벗어나세요.
핵심요약, DR 요약
질문: 효과가 있을까요?
대답: 그렇습니다.
Q: 이게 말이 되나요?
A: 유감스럽게도 매우 구체적인 가정이 있습니다.
보안은 보장하기 어렵습니다.보안SE일반적인 방법의 경우.
긴 버전
누군가 화면이나 키보드를 통해 상자를 방해하는 것을 원하지 않으면 해당 커널 모듈을 비활성화하거나 더 나은 방법은 커넥터의 납땜을 제거하는 것입니다(진심입니다). 반면에 무언가를 표시할 수 있는 프로그램이 컴퓨터에서 실행되지 않는 경우 화면에 연결하면 어떤 영향이 있을지 잘 모르겠습니다.
그러나 여기서 중요한 문제는 신뢰입니다. 내가 이해한 바에 따르면 중요한 데이터(암호화된 E 및 임시 일반 텍스트 P)는 클라이언트에 보관하고 키 K는 서버에 보관하기를 원합니다. E를 P로 해독하려면 어느 시점에서 동일한 시스템에 K와 E가 있어야 합니다. 이는 서버가 충돌하는 첫 순간입니다. 서버는 클라이언트를 충분히 신뢰하지 않으므로 몇 가지 검사를 실행합니다. - 어떻게 할 수 있습니까? 테스트 결과가 위조되지 않을 것이라고 보장합니까? 누군가 키보드를 클라이언트 장치에 연결하는 것이 너무 걱정된다면, 그렇지 않습니까?JTAG그것을 보고 거기에서 무슨 일이 일어나고 있는지 보시겠습니까? 누군가가 클라이언트를 복사하고 분석한 다음 테스트 결과를 스푸핑하면서 자신의 시스템과 교체했다면 어떻게 될까요?
두 번째(내 관점에서 볼 때 더 중요한) 질문은 암호화되지 않은 데이터를 어떻게 처리하며 "서버"에서 이를 수행할 수 없는 이유는 무엇입니까? 여기서 중요한 점은: 서버를 충분히 신뢰하지 않는 경우일시적으로 보류하다RAM의 데이터(여기서는 서버에서 암호 해독을 요청하는 클라이언트에 대해 논의함), 왜 그렇게 신뢰합니까?영구 저장데이터를 암호화하는 키는 어디에 있나요? 일반 텍스트를 RAM에 넣을 만큼 신뢰하지 못한다면 키 데이터를 동일한 메모리에 로드하고 네트워크 인터페이스를 통해 보내는 것이 합리적일까요?
SSH 채널을 통해 편집기의 데이터를 사용하기로 결정했다면 어떻게 해야 합니까? 분명 일반 텍스트가 포함된 SSH 연결 데이터를 누군가가 스누핑하고 있지 않다는 것을 어떻게 알 수 있나요?
내 조언은 다음과 같은 매우 엄격한 프로토콜(자체 암호화를 적용하는 것은 일반적으로 재앙이므로 이미 시행 중인 프로토콜이 바람직함)을 포함하는 솔루션을 찾으라는 것입니다.
양측의 신원을 확인한 후
클라이언트가 서버에 암호 해독 키를 요청하도록 권한을 부여합니다.
인증 서버는 클라이언트에게 암호 해독 키를 제공합니다.
채널의 한쪽에서 실행된 모든 명령은 다른 쪽에서 직접 실행되는 것이 금지됩니다. 즉, 다음이 없으면:
user@server$ ssh client -c "decrypt -k key < encrypted > plaintext"왜?
일반적으로 누군가가 원격으로 임의의 명령을 실행하도록 허용하고 싶지는 않습니다. 특별한 바이너리를 설정하고 원격 사용자가 그 중 하나를 선택하도록 하는 것이 훨씬 더 나을 것입니다.사전 정의된명령(일종의 제한된 쉘과 비슷하지만 더 제한적임). 액세스 토큰이 손상된 경우 공격자는 여러 가지 작업만 수행할 수 있습니다. 귀하의 경우 이는 결국 데이터를 훔치는 것을 의미할 수 있지만 시스템을 트로이 목마로 바꾸는 것을 방지할 수 있습니다. 예를 들어
sshd(적어도 OpenSSH 제품군에서) 인증 단계는 다음과 같이 정확하게 작동합니다. 수신 데몬은 모든("루트" 읽기) 권한을 즉시 제거하고 권한이 없는 프로세스에 의해 처리됨으로 인증을 전달하는 하위 프로세스를 생성합니다. 그 특권적인 작전. 양육은 매우 제한된 API를 통해 수행됩니다. 이렇게 하면 귀하가 제공하는 모든 입력으로 인해 인증이 약간 진행되거나 시스템이 중단될 수 있습니다.특권이 없는이를 통해 애플리케이션은 원격 루트 공격의 가능성을 제거합니다.
가장 문제가 되는 것은 첫 번째이다. 그림완전한 생산 관리그리고txt도움이 될 수도 있지만 궁극적으로는 여전히 누군가를 신뢰해야 합니다. 칩 및 펌웨어 제조업체는 신뢰할 수 있습니까?확실하지 않다예상했던 대로.