이 시나리오가 안전합니까?

Question

RSA를 사용하여 서버와 클라이언트 간의 통신을 암호화합니다. 키 1과 키 2의 2 개의 비대칭 키가 있다고 가정 해 봅시다.

서버에는 처음부터 key1 (private)이 있고 클라이언트에는 key1 (public)이 있습니다.

그래서 여기 시나리오가 있습니다.

1. 클라이언트는 key2를 생성합니다
2. 클라이언트는 서버에 연결합니다
3. key2 (public) key1 (public)로 암호화 된 key2 (공개) 보내기
4. 지금부터 서버에서 Key2 (public)로 암호화 된 모든 데이터를 보냅니다.
5. 클라이언트는 임의의 데이터를 서버로 보냅니다
6. 서버는 동일한 데이터 해시를 다시 보냅니다
7. 클라이언트는 데이터가 옳은지 확인합니다

내가 볼 수있는 한, 이것을 볼 수있는 한, 중간의 사람의 공격을 막아야합니까, 아니면 뭔가 빠진 것입니까? 포인트 7에서 클라이언트는 누군가가 서버를 암호화 할 수있는 잘못된 키를 제공하려고하는지 알아야합니다. 다른 사람은 Key2 (public)를 해독 할 수 없으므로.

보안을 개선하기 위해 수행 할 수있는 일이 있으면 알려주세요.

Answer 1

보안을 향상시키기 위해 할 수있는 최선의 방법은 기존 디자인을 사용하고 휠을 재창조하지 않는 것입니다. 나는 당신이 한 일이 반드시 잘못되었다고 말하는 것이 아니라, 많은 사람들이 당신과 나보다 훨씬 더 똑똑한 사람들 만이이 문제에 대해 많은 시간을 보냈습니다. 대신 TLS를 사용하십시오.

Answer 2

Key1 (개인)이 타사에 의해 어떻게 든 가로 채지 못하면 시나리오가 안전 해 보입니다.

나는 실제로 종이 어딘가에서 이것을 본 것 같아요. 앨리스는 밥에게 잠금 해제 상자 (Key 1 Public)를 주었고 밥은 자신의 상자 (키 2 공개)를 넣고 잠그고 다시 앨리스에게 보냅니다. 그런 다음 Alice는 상자를 엽니 다 (Key 1 Private). 이제 Bob이 방금 준 상자를 안전하게 밀봉 할 수 있습니다.

상자 비유에도 불구하고, 그것은 본질적으로 당신이하고있는 일이므로, 나는 그것의 안전을 말할 것입니다.

Answer 3

동의합니다. TLS 만 사용하십시오.

또한 5 ~ 7 단계는 어떤 가치를 제공합니까? 1-4 단계 이후에 작동하는 공격을 원하는 MITM (예 : N 트랜잭션을 통과 한 다음 중지하여 시작하여 재 시도를 강요함으로써 어떤 종류의 DOS의 DOS)는 5-7 이후에도 그렇게 할 수 있습니다. 그들은 무엇을 추가합니까?

- Markusq

Answer 4

아니요,이 프로토콜은 안전하지 않습니다.

중간에 사람은 클라이언트가 보낸 데이터를 가로 채고 원하는 것을 서버로 보낼 수 있습니다. 서버가 클라이언트를 인증하거나 수신하는 메시지의 무결성을 확인할 수있는 메커니즘을 지정하지 않았기 때문입니다.

물론, 당신은 이러한 눈부신 문제를 해결하기 위해 프로토콜을 닥칠 수 있지만 다른 사람들도있을 것입니다. 당신이 그들 모두를 고치면, 당신은 TLS 또는 SSH에지도를하는 것이있을 것입니다. 왜 그냥 시작하지 않습니까?

---

@petoj— 내가 집중했던 문제는 서버가받는 메시지를 신뢰하는 문제였습니다. 귀하의 제안은 거기에 어떤 보안도 제공하지 않습니다. 그러나 기밀성에 대해 걱정하는 경우 MITM은 클라이언트 메시지에 대한 개인 정보가 없기 때문에 찾기를 원하는 것을 볼 때까지 MITM이 변경되지 않은 메시지를 전달할 수 있기 때문에 여전히 문제가 있습니다.

귀하의 제안은 고객의 메시지의 무결성을 보장하는 것을 목표로하는 것 같습니다. 클라이언트가 공격과 네트워크 고장을 구별 할 수없는 지점까지 프로토콜을 개발했습니다. 클라이언트가 서버가 변조 된 메시지로 작동하는지 여부를 결정하도록 돕지 않고 서버가 메시지를 작용하기 전에 메시지의 무결성을 확인하도록 허용하십시오.

Answer 5

나는 Greg에 동의 할 것입니다 당신은 바퀴를 재창조하고 있습니다. 당신이 본질적으로 설명하는 것은 몇 가지 기본 형태입니다. 키 교환. 우연히도, 중간 공격에 대한 안전을 보장하기 위해서는 서버의 신원을 확신해야합니다. 즉, 클라이언트가 공개적으로 믿는 것이 실제로 (Key1)가 실제로 서버는 중간에 사람이 아닌 (예 : CA를 사용하거나 클라이언트쪽에 보안 스토리지에 서버의 공개 (key1)를 사용하는 것이 아닙니다.)

더욱이가 있습니다 추가 고려 사항 다음과 같은 시스템의 관점에서 알고 있어야합니다.

• 비대칭 키 암호화가 느려집니다 대칭 키 암호화보다 기존 솔루션이 다음과 같은 이유 중 하나입니다. TLS 비대칭 키 암호화 만 사용하여 임시 대칭 키를 협상 한 다음 채널 암호화에 사용됩니다.
• 타사의 트래픽 분석이 임시 대칭 키를 크래킹하는 데 성공하면 비대칭 키 쌍을 타협하지 않았습니다. 당신은 임시 키를 다시 협상하도록 권장했습니다 이런 이유로 상대적으로 자주. 아마도 새로운 생성 key2 시나리오에서는이 측면을 완화합니다.