현재 클라이언트와 서버간에 데이터를 전송하는 시스템을 개발 중이며 사용하려는 암호화의 장점이 무엇인지 궁금합니다.RSA의 장점 AES 키 암호화
개인/공개 RSA 키 쌍이 있고 각 클라이언트에 공개 키를 넘겨 주겠다고 생각했습니다 (개인 키는 서버에만 남김). 각 클라이언트는 자신의 AES 키를 생성하고 RSA가이를 암호화합니다. 그런 다음 AES가 데이터를 암호화하고 암호화 된 데이터와 암호화 된 AES 키를 서버로 보냅니다. 그런 다음 서버는 개인 키를 사용하여 AES 키를 해독 한 다음 AES 키를 사용하여 데이터를 해독합니다.
누락 된 보안 결함이 있습니까? 더 좋은 방법이 있습니까?
정확히 정확히 SSL/TLS의 작동 방식입니다 (핸드 쉐이크 섹션 참조). 더 강하게 만드는 유일한 방법은 매번 동일한 키를 사용하는 대신 각 연결에 대해 AES 키를 생성하는 것입니다. 또한 중간자 및 다른 스푸핑 공격을 피하기 위해 앞뒤로 이동하는 메시지에 디지털 서명을 할 수 있습니다.
일반적으로 좋은 암호 시스템을 만드는 것은 매우 어렵습니다. 가능한 경우 기존 (신뢰할 수있는) 응용 프로그램을 항상 지원해야합니다. 이 경우 자체 시스템을 만드는 대신 HTTPS를 사용하여 메시지를 보내는 것이 좋습니다.
+1은 항상 자신이 설계 한 것 이상의 전문가가 설계 한 기존 보안 제품군을 사용합니다. –
+1 정확하게 사용할 디자인. –
추가 할 것은 단시간의 비밀만을 위해 1024 비트 RSA를 사용하는 것입니다. 짧은 키 길이는 절대 사용하지 말고 중요한 가치를 가진 것들을 위해 2048 비트를 사용하는 것입니다. –
공격자가 공개 키를 "실제"공개 키로 대체 한 경우의 취약점이 있습니다. 그렇다면 그들은 "중간자 (man-in-the-middle)"로서 트래픽을 가로 챌 수있을 것입니다.
S/MIME, PGP 및 TLS와 같은 프로토콜은 사용자가 제안한 것처럼 RSA 암호화를 사용하여 키를 전송합니다. 그러나 사용하는 공개 키는 신뢰할 수있는 기관에서 서명 한 인증서에 있습니다.
이러한 신뢰할 수있는 기관의 무결성을 신중하게 보호해야합니다. 예를 들어 변조 방지 하드웨어 토큰에 불에 타거나 암호를 사용하여 MAC을 계산할 수 있습니다.
사용중인 언어 및 플랫폼에 대한 자세한 정보를 제공해야합니다. 그래야만 이미 존재하는 라이브러리에 대한 세부 권장 사항을 제공 할 수 있습니다. 암호화 원시를 직접 사용하는 것은 쉽지 않고 정확하게 수행하기 어렵습니다. 암호화를 사용하면 보안이 손상 될 수 있기 때문에 "딱 맞지 않습니다"한 번만 수행해야합니다.
그렇지 않으면 DH 교환을 통해 세션 비밀이 설정되지 않은 경우 개인 RSA 키 (어딘가에 저장해야 함)에 대한 액세스 권한을 얻는 상대방이 클라이언트와 서버간에 전송 된 모든 트래픽을 해독 할 수 있습니다.
이 DH 교환을 통해 설정된 인 경우 프로토콜의 인증 부분 만 노출됩니다. 비공개 RSA 키를 소유 한 상대방이 이전의 통신을 읽을 수는 없지만 클라이언트/서버와의 인증 된 대화 상자에 들어가거나 중간자 공격 (man-in-the-middle attack)을 시작할 수 있습니다. 네트워크에 따라 쉽게 수행되지는 않음).
귀하의 접근 방식이 어떤 것을 보호 할 지 확신하지 못합니다. 당신은 서버에 개인 키를 보관할 것이고 공개 키는 배포 될 것입니다.공개 키를 가져 가면 마음대로 서버와 상호 작용할 수 있습니다. 나는 당신이 핵심 소유권을 바꾸어야한다고 생각합니다. 각 클라이언트는 자신의 개인 키를 보유 할 것이며 서버는 공개 키 (ala SSH) 목록을 갖게됩니다. 서버는 '인증 된'공개 키를 추가해야하며 개인 키 보유자 만 연결할 수 있습니다.
희망이 도움이됩니다.
... 이것은 기본적으로 PGP가 작동하는 방식이므로 올바르게 구현하면 매우 안전합니다. –