Wiznet makers

RP2040 + W5100S에서 Curve25519, ChaCha20-Poly1305, Elligator 2를 활용한 Secure Client-Server Chatting 구현 사례

인터넷을 통한 메시지 통신은 우리 일상에서 매우 익숙한 기술이 되었습니다. 하지만 메시지가 네트워크를 통해 이동하는 순간, 보안은 더 이상 선택 사항이 아닙니다. 특히 개인 정보, 인증 정보, 민감한 데이터를 다루는 시스템에서는 암호화, 무결성 검증, 안전한 키 교환이 필수적입니다.

이번에 소개할 연구는 WIZnet W5100S-EVB-Pico를 활용해 MCU 기반의 보안 채팅용 암호화 모듈을 구현한 사례입니다. 논문 제목은 **“Microcontroller-based Encryption Module for Secure Internet Client-Server Chatting”**이며, 2025년 Radioelektronika 학회에서 발표되었습니다.

이 연구는 단순히 MCU에서 TCP/IP 통신을 수행하는 수준을 넘어, Curve25519 기반 키 교환, ChaCha20-Poly1305 인증 암호화, Elligator 2 기반 스테가노그래픽 키 교환, XDRBG 난수 생성기를 조합해 실제 보안 통신 프로토콜을 구현했다는 점에서 의미가 큽니다.

왜 MCU 기반 암호화 모듈인가?

일반적인 보안 채팅 구조에서는 PC나 스마트폰 같은 범용 장치가 메시지 입력, 암호화, 키 저장, 네트워크 통신을 모두 처리합니다. 하지만 범용 장치는 다양한 프로그램을 실행하고, 인터넷 다운로드나 악성 링크에 노출될 수 있기 때문에 보안상 위험 요소가 많습니다.

이 연구에서는 이러한 문제를 줄이기 위해 Embedded Encryption Module, EEM이라는 구조를 제안합니다.

EEM 구조에서는 사용자의 PC가 단순한 터미널 역할만 수행하고, 실제 보안 기능은 MCU 기반 장치가 담당합니다.

이 논문이 보여준 것

https://wiznetshop.io/product/w5100s-evb-pico/1049/

대상 보드는 Wiznet W5100S-EVB-Pico이고, MCU는 RP2040 Cortex-M0+, 네트워크는 W5100S hardwired TCP/IP controller가 담당해. 논문은 이 보드가 264KB SRAM, 2MB Flash, 최대 4개 하드웨어 소켓, TCP/UDP/ICMP/ARP/IPv4 등 프로토콜 지원을 갖고 있어서 MCU 기반 보안 통신 실험에 적합

논문에서는 W5100S-EVB-Pico 보드를 사용했습니다. 이 보드는 RP2040 MCU와 W5100S Ethernet Controller가 함께 탑재된 보드입니다.

연구진은 이 보드 위에 보안 채팅용 Embedded Encryption Module, 즉 EEM을 구현했습니다. PC는 단순히 사용자가 메시지를 입력하는 터미널 역할만 하고, 실제 암호화와 TCP/IP 통신은 W5100S-EVB-Pico가 담당합니다.

구조를 간단히 표현하면 다음과 같습니다.

User PC
  │
  │ Serial
  ↓
W5100S-EVB-Pico
  │
  │ Secure TCP/IP Communication
  ↓
Server

이 방식의 장점은 명확합니다.

사용자의 PC가 암호 키를 직접 다루지 않아도 됩니다. 중요한 키와 암호화 처리를 별도의 MCU 장치 안에 둘 수 있습니다. 임베디드 장치가 네트워크 통신뿐 아니라 보안 처리까지 담당하는 구조입니다.

암호화는 잘 되었나?

논문에서 구현한 보안 통신은 단순 XOR이나 자체 제작 암호화 방식이 아닙니다. 이미 널리 알려진 현대 암호 기술을 조합했습니다.

메시지 암호화에는 ChaCha20을 사용했고, 메시지가 중간에 변조되었는지 확인하기 위해 Poly1305 MAC을 함께 사용했습니다. 이 조합은 ChaCha20-Poly1305 AEAD라고 부르며, 암호화와 무결성 검증을 함께 처리할 수 있습니다.

쉽게 말하면 다음 두 가지를 동시에 확인할 수 있습니다.

1. 메시지 내용을 다른 사람이 읽을 수 없는가?
2. 메시지가 전송 중에 바뀌지 않았는가?

또한 키 교환에는 Curve25519 기반 ECDH를 사용했습니다. 매번 통신 세션마다 임시 키를 만들어 사용하기 때문에, 장기 키가 나중에 유출되더라도 과거 통신 내용을 보호하는 Forward Secrecy 구조를 갖습니다.

논문에서는 추가로 Elligator 2를 사용해 키 교환 데이터가 일반 공개키처럼 보이지 않고 랜덤 데이터처럼 보이도록 하는 기능도 넣었습니다. 일반적인 IoT 프로젝트에서 반드시 필요한 기능은 아니지만, 키 교환 자체를 덜 눈에 띄게 만들고 싶을 때 참고할 수 있는 방식입니다.

속도는 쓸 만한가?

MCU에서 암호화를 한다고 하면 가장 먼저 걱정되는 부분은 성능입니다.

“암호화 때문에 통신이 너무 느려지지 않을까?”

논문 결과를 보면, 채팅 메시지 수준에서는 충분히 사용할 수 있는 성능을 보여줍니다.

400바이트 메시지를 압축하고, 암호화하고, MAC을 생성하고, 서버로 전송한 뒤 응답을 받는 전체 과정은 424,844 CPU cycles가 걸렸습니다. 10바이트 메시지는 190,661 CPU cycles가 걸렸습니다. 논문에서는 두 경우의 차이가 약 2ms 수준이며, 실제 사용자가 체감하기 어려운 수준이라고 설명합니다.

즉, 이 사례에서 확인할 수 있는 결론은 다음과 같습니다.

W5100S-EVB-Pico 같은 작은 MCU 보드에서도 짧은 메시지나 IoT 데이터 정도는 암호화해서 충분히 주고받을 수 있다.

물론 대용량 파일 전송이나 고속 스트리밍을 암호화하는 용도라면 별도 검토가 필요합니다. 하지만 센서 데이터, 제어 명령, 상태 메시지, 채팅 메시지 같은 일반적인 IoT payload라면 적용 가능성이 충분합니다.

내 프로젝트에는 어떻게 적용할 수 있을까?

WIZnet 칩 사용자가 이 논문에서 가장 참고할 부분은 전체 구조입니다.

보안 통신을 적용하려면 다음 순서로 생각하면 됩니다.

1. WIZnet 칩으로 TCP 또는 UDP Socket 연결을 만든다.
2. MCU에서 세션 키를 생성하거나 교환한다.
3. 전송할 데이터를 MCU에서 암호화한다.
4. 암호화된 데이터를 WIZnet Socket으로 전송한다.
5. 수신 측은 데이터를 받은 뒤 MAC을 검증하고 복호화한다.

일반적인 TCP 송신 코드가 아래와 같다면,

send(socket, plain_data, length);

보안 통신에서는 개념적으로 이렇게 바뀝니다.

encrypted_len = encrypt_and_authenticate(
    plain_data,
    plain_len,
    encrypted_data,
    session_key
);

send(socket, encrypted_data, encrypted_len);

수신 측에서는 반대로 처리합니다.

recv(socket, encrypted_data, encrypted_len);

result = verify_and_decrypt(
    encrypted_data,
    encrypted_len,
    plain_data,
    session_key
);

if (result == OK) {
    process_message(plain_data);
} else {
    reject_message();
}

중요한 점은 WIZnet Socket 사용 방식 자체는 크게 바뀌지 않는다는 것입니다.

WIZnet 칩 입장에서는 평문 데이터든 암호화된 데이터든 모두 byte stream입니다. 따라서 기존 TCP/UDP 통신 구조는 그대로 두고, send() 전에 암호화하고 recv() 후에 복호화하는 레이어를 추가하면 됩니다.

어떤 프로젝트에 적용할 수 있을까?

이 구조는 다음과 같은 프로젝트에 적합합니다.

- 센서 데이터를 서버로 안전하게 전송하는 장치
- 원격 제어 명령을 암호화해서 받는 IoT 장치
- 공장/빌딩 내부 Ethernet 기반 제어 장치
- 사용자 인증이 필요한 TCP Client 장치
- MCU 기반 Secure Terminal
- WIZnet Ethernet 보드를 활용한 보안 교육 예제

예를 들어 온도 센서 데이터를 서버로 보내는 프로젝트라면, 기존에는 다음과 같이 보냈을 수 있습니다.

{
  "device_id": "sensor-001",
  "temperature": 24.5
}

보안을 적용하면 이 JSON 데이터를 그대로 보내지 않고, MCU에서 암호화한 뒤 WIZnet TCP socket으로 전송합니다. 서버는 받은 데이터를 복호화한 뒤 원래 JSON을 처리합니다.

즉, 애플리케이션 데이터 형식은 유지하면서도 네트워크 상에서는 내용을 숨길 수 있습니다.

TLS와는 어떤 차이가 있을까?

보안 통신이라고 하면 보통 TLS를 먼저 떠올립니다.

가능하다면 표준 TLS를 사용하는 것이 가장 좋습니다. 하지만 작은 MCU에서는 TLS 전체 스택이 부담이 될 수 있습니다. 인증서 관리, 메모리 사용량, handshake 처리, 라이브러리 포팅 등이 프로젝트에 따라 어려울 수 있습니다.

이 논문은 TLS를 대체하는 범용 표준을 제안한다기보다는, 작은 MCU에서도 목적에 맞는 경량 암호화 통신 구조를 구현할 수 있다는 것을 보여주는 사례에 가깝습니다.

정리하면 다음과 같습니다.

제품이나 상용 서비스라면 검증된 TLS 라이브러리 사용을 우선 고려하는 것이 좋습니다. 반면 제한된 환경, 폐쇄망, 교육용 예제, 연구용 프로토타입, 특정 서버와만 통신하는 장치라면 이 논문의 구조를 참고할 수 있습니다.

WIZnet 칩 사용자에게 중요한 포인트

이 논문에서 WIZnet 사용자에게 가장 중요한 메시지는 다음입니다.

첫째, WIZnet Ethernet Controller는 암호화된 데이터를 전송하는 데 문제가 없다.
암호화는 MCU에서 처리하고, WIZnet 칩은 TCP/IP 전송을 담당하면 됩니다.

둘째, RP2040급 MCU에서도 메시지 단위 암호화는 충분히 가능하다.
논문에서는 400바이트 메시지를 처리하고 전송하는 데 사용자가 체감하기 어려운 수준의 시간이 걸렸다고 보고했습니다.

셋째, 기존 WIZnet TCP/UDP 예제에 암호화 레이어를 추가하는 방식으로 접근할 수 있다.
Socket 연결 구조를 완전히 바꿀 필요는 없습니다. 송신 전 암호화, 수신 후 복호화 구조를 추가하면 됩니다.

넷째, 키 관리는 반드시 별도로 설계해야 한다.
암호 알고리즘만 넣는다고 보안이 완성되는 것은 아닙니다. 키를 어디에 저장할지, 어떻게 교환할지, 장치 분실 시 어떻게 보호할지까지 함께 고려해야 합니다.

마무리

W5100S-EVB-Pico를 활용한 이 연구는 WIZnet Ethernet 칩 사용자가 보안 통신을 고민할 때 좋은 참고 사례가 됩니다.

핵심은 간단합니다.

WIZnet 칩은 안정적인 TCP/IP 연결을 담당하고, MCU는 데이터를 암호화한다.
이 구조를 사용하면 작은 임베디드 보드에서도 암호화된 메시지 통신을 구현할 수 있습니다.

IoT 장치에서 평문 TCP 통신이 걱정된다면, 이 논문의 구조처럼 애플리케이션 데이터에 암호화 레이어를 추가하는 방식을 검토해볼 수 있습니다.

W5100S, W5500, W6100을 사용하는 프로젝트에서도 같은 개념을 적용할 수 있습니다.
보내기 전에 암호화하고, 받은 뒤 검증하고 복호화하는 것. 이것이 MCU 기반 보안 통신의 출발점입니다.