2012-07-04 3 views
1

SilverLight 응용 프로그램간에 데이터를 보내야합니다. SSL/TLS와 같은 보안 프로토콜을 사용하여 데이터를 전송해야한다는 요구 사항이 있습니다. 성능상의 이유로 TCP 소켓을 사용하여 데이터가 전송됩니다. 아쉽게도 SilverLight는 SslStream을 지원하지 않습니다. SSL/TLS를 통해 데이터를 전송하려면 제 3 자 라이브러리를 구입해야합니다. SecureBlackbox. 전송 레이어를 처리 할 때 제 3 자 라이브러리에 의존하고 싶지 않습니다.CryptoStream을 SslStream 대신 사용할 수 있습니까?

그러나 SilverLight는 CryptoStream 클래스입니다. SSL을 통한 WCF (SilverLight 지원)를 사용하여 대칭 암호화를위한 키를 교환 한 다음 CryptoStream을 사용하여 AES로 데이터를 암호화하려고합니다.

이 솔루션은 안전한가요? 보안 측면에서 SSL/TLS를 사용하는 것과 비교할 수 있습니까? 내가 누락 된 확실한 보안 구멍이 있습니까?

+3

SSL은 단순한 암호화가 아니라 패킷 무결성 검사, 인증 된 암호화, 보안 키 생성, 적절한 암호화 모드 등의 여러 가지 기능과 압축 등을 제공합니다. –

+0

@ EugeneMayevski'EldoSCorp 저는 정보를 교환하는 양쪽 당사자를 전적으로 통제하고 있습니다. 키는 SSL을 사용하여 교환되며 양 당사자가 AES를 사용할 수 있음을 알고 있습니다. 아무도 키를 모른 채 데이터를 해독 할 방법이 없다고 생각합니다. 누군가가 전송을 중단 할 수는 있지만 데이터로 암호화하는 데 키를 알고 있어야하므로 잡음이 들릴 것이라고 동의합니다. 메시지의 보안 측면에서 어떤 결함이 보이십니까? (즉, 등급이 지정되지 않은 사람이 자신의 데이터를 전송의 일부로 전송하거나 전송 데이터를 읽음) – empi

+0

AES의 신뢰할 수있는 암호화 모드를 선택해야하며 키와 IV를 모두 협상해야합니다. 그러나 SSL을 통해 WCF를 사용하여 연결할 수 있다면 WCF를 추가 통신에 사용하지 않아야 할 이유가 있습니까? –

답변

1

AES 방식의 주요 문제점은 키 관리와 키 확인입니다. SSL이 SSL 체인의 '유효성을 확인하기 위해 CA 체인 (인증 기관)을 사용하는'핸드 셰이크 '를 사용한다는 것을 알고 계실 것입니다. 이 모든 것은 SSL 세션에 대해 AES 키가 생성되기 전에 발생합니다. 따라서 SSL을 사용하지 않으면이 중요한 단계를 놓치게됩니다.

즉, 키가 안전하고 안전하게 교환되었는지 확인하는 것은 사용자의 책임입니다.

+1

SSL/TLS 연결을 사용하여 세션 키를 교환하는 경우 유효성 검사에 문제가 없어야합니다. –

+0

키가 안전하게 교환됩니다. https를 통한 webservice 호출을 사용합니다. – empi

관련 문제