자작 암호화 채팅 소프트웨어의 패킷 분석 및 무결성 보장

암호화 통신

이전에 직접 구현한 라이브러리를 통해 자바 언어 기반에서 손 쉽게 암호화 통신을 사용할 수 있도록 하였습니다. 하지만 이 라이브러리에는 무결성 보장이라는 문제가 존재하였고, 이 부분을 탐색하고 수정하기 위해 이 고찰을 작성합니다.

문제점 고찰

이전에 직접 만든 라이브러리는 기본적으로 암호화 통신을 제공합니다. 서버측 라이브러리와 클라이언트측 라이브러리를 같이 활용함으로써 손 쉽게 통신을 구축할 수 있습니다.

설명

이 도구의 프로세스를 간단하게 살펴보면, 클라이언트가 서버에 접속하면 1) 클라이언트가 서버에게 OK 신호를 보내는 단계, 2) 서버에서 그 시점에 생성된 랜덤 코드를 생성하고 서버의 공개키와 함께 클라이언트에 보내는 단계, 3) 클라이언트에서는 공개키를 검증하고 공개키로 새 AES키를 암호화하여 서버에 전송하는 단계, 4) 서버에서는 암호화된 데이터를 복호화 해 AES 키로 적용하는 단계로 구성되어 있습니다. 물론 실제 구현 단계는 조금 더 복잡하며 실질적으로 구축되는 단계는 조금 다르지만, 전체적으로는 전형적인 암호 알고리즘의 데이터 성사 과정과 비슷하게 구현했습니다.

진행도

randomCode

여기서 랜덤 코드를 넣은 이유는 클라이언트 측에서 같은 패킷을 재 활용하지 못하는 것을 의도하였습니다. 이러한 인증 수단이 없다면 클라이언트 측에서 최초로 한번 만든 패킷을 나중에 접속시 재사용하여 전송할 수 있기 때문에 보안상 문제가 발생할 수 있습니다. (또는 중간자 공격에서) 하지만 이러한 문제는 여기서만 존재하는 것이 아닙니다. 기본적으로 네트워크로 수신되는 스트림은 믿을 수 없기 때문에, 데이터의 무결성이 보장되어야 합니다.

위 과정에서 데이터가 안전하게 암호화되어 내용물을 살펴볼 수는 없지만, 내용물을 수정하거나 같은 내용을 다시 복사하여 전송할 가능성을 고려해야 합니다.

이러한 공격 행위는 당사자가 아니라 중계 또는 중간자 공격을 통해서 발생할 수도 있습니다.

예를 들어,

중간자 클라이언트가 서버에 접속하였지만 같은 네트워크 망에서 어떤 공격자가 중간자 공격을 통해 네트워크 스트림을 중계하고 있다고 가정합니다. 이러한 방법은 ARP 스푸핑 등 패킷 신호를 우회하여 받아내고, 목적지로 보내되 그 패킷들을 모두 저장하고 스니핑하며, 심지어 재 전송, 조작 가능성을 배제할 수 없습니다.

클라이언트가 "안녕"이라고 보낸 메시지에서, 모든 데이터는 RSA 비대칭 및 AES 대칭 암호 방법을 통해 안전하게 암호화되기 때문에 공격자는 그 내용을 엿볼 수는 없습니다.

그러나 중간자 공격에서, 원하는 패킷의 실제 내용을 마음대로 들여다 볼 수는 없지만 수정하거나 조작하여 전송하는 등 모든 작업이 가능합니다. 그렇기 때문에 이 암호화된 내용을 다시 전송하는 작업도 가능할 것 입니다.

즉 클라이언트는 "안녕"이라고만 보냈는데, "안녕" 패킷을 2번 전송하여 서버측에 두 번 발생시킬 수 있는데다가, 이 암호화된 패킷이 어떤 내용인지는 모르지만 암호문 그 자체를 "저장"해두고 원하는 시점에 재 전송할 수 있습니다.

이러한 문제는 명령을 보내거나 중요한 수단을 처리할 때 중대한 보안 문제를 일으킵니다.

어떤 클라이언트가 서버에 명령인 "공격 개시" 와 "공격 중단"을 보내고, 그 데이터가 암호화되어 중간자 공격에 도달하였을 때, 중간자 공격자는 이 패킷을 각각 보관합니다.

이 상황에서 클라이언트의 의도 없이 서버에게 중간자 공격에서 원하는 패킷을 골라 전송하여 의도치 않은 명령을 발생할 수 있습니다.

다시 말하자면, 중간자 공격에서는 원하는 내용으로 패킷을 직접 만들지는 못합니다. 왜냐하면 초반 RSA 암호 인증 방법을 통해 안전하게 AES 키를 교환했고, AES 암호키를 알 수 없는 상황이기 때문에 그에 맞는 데이터를 생성해내지는 못하지만, 데이터를 수정하거나 해당 패킷을 다시 전송해 낼 수는 있습니다. 이 방법을 통해서 의도치 않은 문제를 전송시킬 수 있으며 무결성이 훼손됩니다.

따라서 저는 해당 라이브러리에 모든 데이터를 보낼 때 데이터의 앞에는 절대 중복성이 없는 오름차순의 숫자 코드를 넣어 전송하게끔 구현하였고 이 값이 유효한 경우에만 패킷으로 간주하게끔 하였습니다. 예를 들어 처음 보내는 데이터에는 0:안녕, 1:안녕, 2:안녕... 와 같이 숫자를 카운팅한 데이터를 암호화 데이터를 보냅니다. 받는 입장에서 다음 와야 할 숫자가 아닌 경우 패킷이 재 사용된 것을 알 수 있습니다.

암호 알고리즘에서의 무결성 문제

패킷의 무결성은 숫자 카운팅을 통해 해결되었지만 암호 알고리즘에서의 무결성 문제가 존재합니다. AES 암호화가 되어 있다고 하더라도 그 내용을 알아볼 수는 없지만 비트와 바이트를 조작함으로써 어느정도 실제 데이터를 조작할 수 있습니다. 즉 앞서 구현한 숫자 카운팅 부분을 다음 숫자에 맞춰서 조작할 가능성이 존재하다는 것이며, 암호화 자체가 조작된 것은 아닌지 확인할 필요가 존재합니다.

기본적으로 암호화 방법에는 암호 모드가 존재합니다. 대표적으로 CBC 모드가 존재하는데 이 CBC 모드 대신, GCM 모드를 사용함으로써 데이터의 태그 값과 비교함으로써 암호화 내용이 조작된지 확인할 수 있다고 합니다.

따라서 GCM 모드에 대한 IV 벡터 값을 지정해주고, 암호화 , 복호화 라이브러리를 조금 수정하였습니다.

패킷 확인

이로써 알려진 문제는 해결하였고, 데이터가 정상적으로 송수신되는지 패킷 스니퍼로 확인 해 보며 프로젝트를 마무리합니다.

먼저 로그인시 패킷입니다. 클라이언트에서 서버로 보내는 패킷으로 보입니다.

실제 데이터가 보내는 부분과 동일하게 OK 부분이 보임을 확인할 수 있습니다.

서버에서는 공개키를 전송 해 오고, 그 공개키가 클라이언트에서 인증한 공개키와 동일한지 확인하는 부분도 정상 동작합니다. 그리고 내부적인 암호화 절차 후 서버에 전송합니다.

특히 여기서 특이한 점은, write를 보냈을 때 한번에 전송되는 것이 아니라 잘라서 전송되는데, 먼저 앞 부분의 length packet (4 byte array)가 전송되고 00 00 00 80 의 hex 의 dec 값인 128바이트가 다음으로 전송된 것을 확인할 수 있습니다. 이 128바이트는 암호문 데이터가 담긴 RSA 암호 데이터로 보입니다.

그리고 데이터를 주고 받는 모습이 보입니다.

이 모든 내용이 위 사진의 패킷 내에서 이뤄졌습니다.

패킷 참고

기본적으로 네트워크로 송수신되는 모든 패킷은 정확하게 잘라내지 못하고 크기를 항상 예측하지 못합니다. 따라서 원하는 데이터를 전송하고 원하는 데이터를 받기 위해서 그 데이터만큼만 잘라서 읽기 위한 크기 정보가 앞에 딸려서 전송되어야 합니다. 그러한 작업이 위 4바이트 00 00 00 28, 00 00 00 80 과 같은 역할을 합니다. 이러한 부분에 대해서는 별도로 작성하겠습니다..