Wiznet makers

프로젝트가 하는 일

구성은 Client / Server / Proxy 3요소로 나뉜다.

Client(STM32F407): 서버와 키 합의를 수행한 뒤(EDHOC), 그 결과로 만든 OSCORE 보안 컨텍스트를 사용해 보호된 CoAP 요청을 UDP로 전송한다.

Server(STM32F303): 동일한 컨텍스트로 요청을 검증·복호화하고, 보호된 CoAP 응답을 생성해 다시 UDP로 반환한다.

Proxy(라즈베리파이/PC 등): 클라이언트와 서버 사이의 CoAP 트래픽을 중계한다. 이때 OSCORE가 적용된 메시지는 “프록시가 내용을 볼 수 없는 형태”로 전달되는 것이 핵심 관찰 포인트다.

데모의 메시지는 “프록시가 존재해도 종단간 보호를 유지할 수 있다”는 것을 실제 네트워크 경로에서 확인하는 데 있다.

이미지 출처 : AI 생성

WIZnet W5500이 들어가는 위치

W5500은 클라이언트/서버 보드가 네트워크에 붙는 유선 이더넷 인터페이스다. 이 데모에서 W5500의 역할은 OSCORE 자체가 아니라, OSCORE가 올라타는 UDP 전송 경로를 안정적으로 제공하는 것이다.

유선 이더넷 기반으로 통신을 구성하면 다음 이점이 있다.

재현성: 보안 계층(EDHOC/OSCORE) 디버깅은 패킷 흐름이 흔들리지 않아야 원인 분석이 쉽다. 무선 환경의 변동을 줄이고 보안 로직 검증에 집중할 수 있다.

제약형 MCU에 적합한 통합 방식: SPI로 붙는 외부 이더넷 컨트롤러를 사용하면, 보드 레벨에서 네트워크를 분리해 구성할 수 있고 프로젝트 구조가 명확해진다.

OSCORE란?

OSCORE는 CoAP 메시지를 전송 계층 채널(DTLS/TLS)로 감싸는 대신, CoAP 메시지의 특정 부분을 애플리케이션 계층에서 보호한다. 그래서 프록시가 패킷을 중계하거나 라우팅하는 구조를 유지하면서도, 엔드포인트 간에는 다음을 달성한다.

기밀성: 보호 대상 페이로드(및 일부 옵션)가 암호문으로 전달된다.

무결성/인증: 메시지 위변조를 검출할 수 있다.

종단간 보호: 중간 노드(프록시)는 전달에 필요한 최소 정보만 다루고, 민감한 내용은 해독하지 못한다.

OSCORE가 제대로 동작하려면, 클라이언트와 서버가 공유하는 보안 컨텍스트(키 재료, 식별자, 시퀀스 등) 가 필요하다. 이 데모는 그 컨텍스트를 만들기 위해 EDHOC 기반의 키 합의 흐름을 사용한다. 즉, “키 합의(EDHOC) → 컨텍스트 생성(OSCORE) → 메시지 보호(CoAP)” 순서가 전체 동작의 골격이다.

실전 팁 / 함정

먼저 네트워크부터 분리 점검: OSCORE가 문제처럼 보여도 IP/서브넷/게이트웨이 하나가 틀리면 통신이 성립하지 않는다. “UDP 왕복이 되는 상태”를 먼저 만들고 보안 계층으로 올라가는 것이 빠르다.

SPI는 보수적으로 시작: 배선 길이, 접지, 신호 품질 이슈로 초기부터 고속으로 올리면 간헐 오류가 나기 쉽다.

CS 신호 관리: CS가 흔들리면 레지스터 접근이 불안정해져서 증상이 랜덤하게 나타난다(가끔만 링크가 끊기거나 패킷이 손실되는 형태).

OSCORE 오버헤드 고려: 보호 옵션/암호문이 붙으며 메시지 길이가 늘어난다. 수신 버퍼 크기와 MTU 경계를 염두에 두어야 한다.

프록시에서 관찰 포인트 정하기: 프록시는 “패킷 전달은 정상인데 페이로드가 읽히지 않는 상태”가 정상이다. 중간 노드에서 평문이 보인다면 설계 의도와 다르다.

릴리즈 빌드 우선: 임베디드 Rust는 디버그 빌드가 커지기 쉽다. 플래시 제약이 있으면 릴리즈 빌드가 더 현실적이다.

FAQ

1) 왜 OSCORE를 쓰나요? DTLS로 CoAP를 보호하면 안 되나요?
DTLS는 전송 계층의 “채널”을 보호한다. 반면 OSCORE는 메시지 자체를 보호해 프록시/중계 구조에서 종단간 보호를 유지하기 쉽다. 이 데모는 “프록시가 있어도 엔드포인트만 내용을 아는 구조”를 보여주려는 목적이라 OSCORE가 잘 맞는다.

2) 이 데모에서 W5500을 쓰는 기술적 이유는 뭔가요?
보안 계층 검증은 네트워크가 흔들리면 디버깅이 급격히 어려워진다. W5500 기반 유선 경로는 변동성을 줄여 재현성을 높이고, 프로젝트의 초점을 EDHOC/OSCORE 동작 확인에 맞출 수 있다.

3) W5500은 STM32와 어떤 인터페이스로 연결되나요?
SPI로 연결한다. 펌웨어는 SPI 초기화 후 W5500을 초기화하고, MAC/IP/서브넷/게이트웨이를 설정한 다음 UDP 소켓을 열어 CoAP 트래픽을 송수신한다.

4) 이 프로젝트에서 OSCORE는 구체적으로 무엇을 보호하나요?
프록시가 알아야 하는 라우팅/전달 정보는 남기고, 애플리케이션 데이터(주로 페이로드 및 관련 옵션)를 암호화·무결성 보호한다. 그래서 프록시는 전달은 가능하지만, 민감 데이터의 평문은 볼 수 없다.

5) 초보자라면 어떤 순서로 따라가는 게 좋나요?
(1) W5500 배선과 링크를 안정화하고, (2) 정적 IP로 UDP 송수신이 되는 상태를 만든 뒤, (3) 프록시를 통해 패킷이 오가는지 확인하고, (4) 마지막으로 EDHOC/OSCORE 적용 후 “프록시에서 평문이 안 보이는지”를 확인하는 순서가 가장 빠르다.

What the Project Does

The system is split into three components: Client / Server / Proxy.

Client (STM32F407): After performing key agreement with the server (EDHOC), the client uses the resulting OSCORE security context to send protected CoAP requests over UDP.

Server (STM32F303): Using the same context, the server verifies and decrypts incoming requests, generates protected CoAP responses, and sends them back over UDP.

Proxy (Raspberry Pi / PC, etc.): Relays CoAP traffic between the client and server. The key observation is that OSCORE-protected messages are forwarded in a form where the proxy cannot read the protected content.

The point of the demo is to validate, on a real network path, that end-to-end protection can be preserved even when a proxy is present.

Image source: AI-generated

Where WIZnet W5500 Fits

The W5500 is the wired Ethernet interface that connects the client and server boards to the network. In this demo, the W5500’s role is not OSCORE itself, but to provide a stable UDP transport path on which OSCORE runs.

Building the setup on wired Ethernet has two practical benefits:

Reproducibility: Debugging security layers (EDHOC/OSCORE) is much easier when packet flow is stable. A wired link reduces the variability of wireless environments and lets you focus on validating the security logic.

A good integration model for constrained MCUs: Using an external SPI-based Ethernet controller lets you separate networking at the board level and keeps the overall project structure clearer.

What Is OSCORE?

Instead of wrapping CoAP in a transport-layer channel (DTLS/TLS), OSCORE protects specific parts of a CoAP message at the application layer. This preserves CoAP’s proxying and routing model while still delivering the following properties end to end:

Confidentiality: Protected payloads (and some options) are carried as ciphertext.

Integrity / Authentication: Message tampering can be detected.

End-to-end protection: Intermediate nodes (proxies) handle only the minimum information needed for forwarding and cannot decrypt sensitive content.

For OSCORE to work correctly, the client and server must share a security context (key material, identifiers, sequence numbers, and related parameters). This demo establishes that context using an EDHOC-based key agreement flow. In other words, the overall backbone is:

Key agreement (EDHOC) → Context creation (OSCORE) → Message protection (CoAP)

Practical Tips / Pitfalls

Validate the network first: Even if it looks like an OSCORE issue, a wrong IP/subnet/gateway will prevent communication entirely. Get to a “UDP round-trip works” state before moving up to the security layer.

Start SPI conservatively: If you push SPI speed too early, wiring length, grounding, and signal integrity issues can cause intermittent failures.

Manage the CS signal carefully: If chip-select is unstable, register access becomes unreliable and symptoms can look random (occasional link drops or packet loss).

Account for OSCORE overhead: Protected options and ciphertext increase message size. Plan receive buffers and MTU boundaries accordingly.

Define what “success” looks like on the proxy: The normal state is “packets forward correctly, but payload is unreadable.” If plaintext is visible at the intermediate node, the result does not match the design intent.

Prefer release builds: Embedded Rust debug builds can grow quickly. If flash is tight, release builds are often the realistic option.

FAQ

1) Why use OSCORE? Can’t we just secure CoAP with DTLS?
DTLS protects a transport-layer “channel.” OSCORE protects the message itself, which makes it easier to preserve end-to-end protection in proxy/relay architectures. This demo aims to show “only the endpoints can read the content even with a proxy in the middle,” so OSCORE is a good fit.

2) What’s the technical reason for using the W5500 in this demo?
Security-layer verification becomes much harder when the network path is unstable. A W5500-based wired path reduces variability, improves reproducibility, and keeps the focus on confirming EDHOC/OSCORE behavior.

3) How does the W5500 connect to the STM32, and what does firmware configure?
It connects via SPI. After SPI initialization, the firmware initializes the W5500, configures MAC/IP/subnet/gateway, then opens a UDP socket to send and receive CoAP traffic.

4) What exactly does OSCORE protect in this project?
It leaves routing/forwarding-relevant information that a proxy needs, while encrypting and integrity-protecting the application data (primarily the payload and related options). The proxy can forward messages but cannot see the sensitive plaintext.

5) If I’m a beginner, what’s the fastest order to follow?
(1) Stabilize W5500 wiring and link, (2) reach a working UDP send/receive state with static IP, (3) confirm packets traverse the proxy, then (4) enable EDHOC/OSCORE and verify that plaintext is not visible at the proxy.