개념
왜 이 규격부터 보는가
레슨 1에서 EU가 무선기기에 EN 18031을 지정했다고 했다. 그런데 EN 18031을 열어 보면 여러 곳에서 다른 규격을 참조하고, 공개된 해설 자료들은 EN 303 645를 충족하면 EN 18031 대응의 상당 부분이 준비된다 는 대응표를 싣는다. 영국의 제품보안법 규정은 이 규격의 특정 조항을 그대로 인용하고, 싱가포르·핀란드·독일의 IoT 보안 라벨 제도도 이 규격을 토대로 삼는다.
즉 EN 303 645는 여러 규제가 공유하는 기준선(baseline) 이다. 한 번 제대로 시험 체계를 만들면 여러 제도에 재사용된다. 이 모듈에서 규격 조항을 처음으로 직접 읽는 자리를 이 규격으로 잡은 이유다.
적용 범위 — "소비자 IoT 기기와 그에 딸린 서비스"
규격이 대상으로 삼는 것은 네트워크(인터넷이나 가정 내 네트워크)에 연결되는 소비자 IoT 기기와, 그 기기가 상호작용하는 연관 서비스(associated services) 다. 규격이 드는 예시는 이런 것들이다.
- 연결형 완구, 아기 모니터
- 연결형 화재감지기, 도어락, 창문 센서
- 여러 기기가 붙는 IoT 게이트웨이·허브
- 스마트 카메라, 스마트 스피커, 스마트 TV
- 착용형 건강 추적기
- 세탁기·냉장고 같은 연결형 가전
- 스마트 홈 어시스턴트
두 번째 줄의 "연관 서비스"를 놓치면 안 된다. 규격은 연관 서비스의 예로 모바일 앱, 클라우드 저장·연산, 제3자 API 를 든다. 기기 본체만 시험하고 앱과 클라우드를 빼면 범위를 잘못 잡은 것이다. 모듈 31 레슨 1의 의뢰 범위와 제외 범위 가 이 규격에서는 "연관 서비스를 어디까지 포함하는가"로 나타난다.
규격은 자원이 제한된 기기의 사정도 명시적으로 고려한다. 전원, 대역폭, 연산 능력, 메모리가 부족한 기기에서는 일부 보안 기능을 구현하기 어렵다는 점을 인정하고, 그 대신 왜 구현하지 않았는지를 기록하라 고 요구한다.
13개 조항군
5장이 사이버보안 조항, 6장이 개인정보 보호 조항이다. 5장은 13개 조항군으로 나뉜다.
| 조항군 | 제목(요지) | 시험에서 보는 것 |
|---|---|---|
| 5.1 | 공통 기본 패스워드를 쓰지 않는다 | 기기마다 고유한 초기 패스워드인가, 사용자가 정하는가. 무차별 대입 억제 |
| 5.2 | 취약점 제보를 관리하는 수단을 둔다 | 공개된 취약점 공개 정책, 접수 창구, 처리 기한 |
| 5.3 | 소프트웨어를 최신으로 유지한다 | 업데이트 수단의 보안, 무결성 검증, 지원 기간 공개 |
| 5.4 | 민감한 보안 파라미터를 안전하게 저장한다 | 키·자격증명의 저장 위치와 보호, 하드코딩 여부 |
| 5.5 | 안전하게 통신한다 | 모범 사례 암호로 전송 구간 보호 |
| 5.6 | 노출된 공격 표면을 최소화한다 | 쓰지 않는 인터페이스·서비스 비활성화, 디버그 인터페이스, 최소 권한 |
| 5.7 | 소프트웨어 무결성을 보장한다 | 보안 부팅, 변조 탐지 |
| 5.8 | 개인정보가 안전하도록 한다 | 민감 개인정보의 전송·저장 보호 |
| 5.9 | 장애에 대한 복원력을 갖춘다 | 네트워크·전원 단절 시 로컬 기능 유지와 복구 |
| 5.10 | 시스템 원격측정 데이터를 검토한다 | 수집 데이터에서 보안 이상 징후를 찾는가 |
| 5.11 | 사용자가 데이터를 쉽게 삭제할 수 있게 한다 | 초기화·계정 삭제·재판매 전 데이터 제거 |
| 5.12 | 설치와 유지보수를 쉽게 한다 | 안전한 설정으로 이끄는 설치 안내 |
| 5.13 | 입력 데이터를 검증한다 | UI·API·네트워크 입력의 검증 |
6장은 개인정보 처리의 투명성, 동의, 최소 수집 같은 데이터 보호 조항 이다. V3 판에서 이 부분이 보강됐다.
13개를 외울 필요는 없다. 대신 "기기 수준에서 시험기로 확인할 수 있는 것"과 "조직의 정책·프로세스를 문서로 확인해야 하는 것" 이 섞여 있다는 점을 봐야 한다. 5.2(취약점 공개 정책)와 5.3의 지원 기간 공개는 기기를 아무리 두드려도 나오지 않는다. 웹사이트, 정책 문서, 운영 기록을 봐야 한다. 시험 계획서를 쓸 때 증거 유형(기기 시험 / 문서 검토 / 인터뷰) 을 조항마다 먼저 붙이는 이유다.
조항 번호 읽는 법과 "shall·should"
조항은 조항군-번호 형식으로 붙는다. 5.1-1 은 5.1 조항군의 첫 번째 조항이다.
번호 뒤에 알파벳이 붙은 조항(예: 5.1-2A)은 이전 판과의 번호 호환을 위해
나중에 끼워 넣은 것이다.
각 조항은 동사로 성격이 갈린다.
| 표현 | 성격 | 시험 설계에서의 의미 |
|---|---|---|
| shall | 필수(mandatory) | 충족해야 한다. 미충족이면 부적합 |
| should | 권고(recommendation) | 충족하지 않아도 되지만 그 이유를 기록해야 한다 |
| 조건부 | 특정 기능이 있을 때만 적용(예: "패스워드를 사용하는 경우") | 조건 성립 여부를 먼저 판정 |
두 번째 줄이 이 규격의 특징이자 함정이다. 5장 맨 앞 5.0-1 은 해당하지 않거나
충족하지 않는 권고 조항마다 정당화 사유를 기록하라 는 필수 조항이다. 즉 권고
조항을 무시해도 된다는 뜻이 아니라, 무시하려면 이유를 문서로 남기는 것이
필수 라는 뜻이다.
권고 조항 5.x-y 를 구현하지 않음
│
├─ 사유 기록 있음, 사유가 기기 특성과 맞음 → 적합
├─ 사유 기록 있음, 사유가 기기 특성과 모순 → 사유 불인정 (부적합 의견)
└─ 사유 기록 없음 → 5.0-1 위반규격 서문은 앞으로의 개정에서 현재 권고인 조항 일부가 필수로 바뀔 수 있다 고 밝힌다. 오늘 권고 조항을 사유 기록으로 넘긴 제품은, 다음 판 대응에서 그 조항부터 구현 부담이 생긴다. 시험 결과 보고서에 권고 미충족 목록을 따로 모아 두는 것 이 제조사에게 주는 실질적인 가치다.
규격 스스로 "시험 방법은 정하지 않는다"고 말한다
EN 303 645에는 중요한 단서가 있다. 이 규격은 기기의 보안 요구를 정하지만 시험이나 인증 방법은 정하지 않는다 고 스스로 적는다. 요구를 충족하는 방법에 따라서는 특정 시험 체계에서 입증하기 어렵거나 불가능할 수도 있다고까지 말한다. 그리고 제3자 평가를 하려면 아키텍처 문서, 위협 모델, 수명주기 정책 문서, 부품의 평가 인증서 같은 자료가 필요할 것이라고 안내한다.
그 평가 방법을 정한 문서가 ETSI TS 103 701 이다. 규격과 시험 방법이 서로 다른 문서로 분리되어 있다는 점은 모듈 32 레슨 7에서 본 문서 유형 구분과 맞닿는다. EN은 요구사항, TS는 그 요구를 평가하는 방법이다. 2025년에 TS 103 701 V2 판이 나왔고, EN 303 645 V3.1.3은 시험 사례 범위를 TS 103 701 V2와 맞췄다.
TS 103 701의 평가 구조 — ICS, IXIT, 개념 평가, 기능 평가
TS 103 701은 평가를 제조사가 먼저 채우는 두 문서에서 시작한다.
ICS(Implementation Conformance Statement) — 제조사가 "우리 기기는 이 기능을 구현했다/안 했다"를 조항 단위로 선언하는 표다. 어떤 시험이 적용되는지 가 여기서 결정된다. 패스워드를 쓰지 않는 기기라면 패스워드 조건부 조항의 시험이 빠진다.
IXIT(Implementation eXtra Information for Testing) — ICS 외에 시험소가 시험을 수행하는 데 필요한 모든 추가 정보다. 인터페이스 목록, 사용 암호 방식, 업데이트 절차, 보안 파라미터 목록, 취약점 공개 정책의 위치 같은 것들이다. 시험의 입력 자료 라고 보면 된다.
평가는 조항군 단위의 시험 시나리오 목표 아래 조항별 시험 그룹 이 있고, 그 안에 시험 사례가 있다. 시험 사례는 대체로 두 성격으로 나뉜다.
| 평가 | 무엇을 보는가 | 예 (5.1 패스워드) |
|---|---|---|
| 개념 평가(conceptual) | IXIT에 기술된 설계가 조항 요구를 충족하는가 | "기기별 고유 패스워드를 생성한다"는 설명의 생성 방식이 추측 불가능한가 — 일련번호·MAC 주소에서 유도되지 않는가 |
| 기능 평가(functional) | 실제 기기가 IXIT에 적힌 대로 동작하는가 | 샘플 여러 대의 초기 패스워드를 확인해 서로 다르고, 규칙성이 없는가 |
이 두 층을 섞지 않는 것이 핵심이다. 문서가 틀렸는데 기기가 우연히 맞게 동작하는 경우 도, 문서는 완벽한데 기기가 다르게 동작하는 경우 도 있다. 개념 평가만 하면 후자를 놓치고, 기능 평가만 하면 설계 결함을 표본 운으로 넘긴다.
[제조사] [시험소]
ICS 작성 ─────────────────────▶ 적용 시험 선정
IXIT 작성 ────────────────────▶ 개념 평가 (문서 ↔ 요구)
시료·계정·펌웨어 제공 ─────────▶ 기능 평가 (기기 ↔ 문서)
│
▼
조항별 판정 + 권고 미충족 사유 검토레슨 3의 EN 18031은 이 두 층을 세 층(개념·기능 완전성·기능 충분성)으로 한 단계 더 쪼갠다. 이 레슨의 구조를 먼저 익히면 EN 18031이 훨씬 쉽게 읽힌다.
조항 하나를 시험 항목으로 풀어 보기 — 5.1 패스워드
5.1 조항군은 공통 기본 패스워드를 금지한다. 요지는 두 가지다. 패스워드를 쓴다면 기기마다 고유하거나 사용자가 정해야 하고, 고유 패스워드라면 일련번호처럼 추측 가능한 규칙으로 만들면 안 된다.
모듈 3에서 배운 설계 기법으로 풀면 시험 항목이 이렇게 나온다.
| 시험 항목 | 설계 근거 | 증거 |
|---|---|---|
| 출고 상태 샘플 N대의 초기 패스워드가 모두 다른가 | 동등 분할 — "같은 패스워드 쌍 존재" 분할 | 샘플별 기록 |
| 초기 패스워드가 라벨의 일련번호·MAC과 규칙적 관계가 없는가 | 오류 추정 — 흔한 구현 실수 | 생성 알고리즘 설명(IXIT) + 샘플 대조 |
| 초기화(factory reset) 후에도 공통 패스워드로 돌아가지 않는가 | 상태 전이 — 초기화 전이 | 초기화 전후 기록 |
| 모든 인증 인터페이스(웹 UI·앱·Telnet·SSH·UART)에 동일하게 적용되는가 | 인터페이스 목록 전수 | 포트 스캔 결과 + IXIT 인터페이스 목록 대조 |
| 연속 실패 시 무차별 대입을 억제하는가 | 경계값 — 허용 실패 횟수 전후 | 시도 로그 |
네 번째 줄이 가장 자주 실패한다. 웹 UI는 고유 패스워드인데, 개발 중에 쓰던 시리얼 콘솔이나 Telnet이 공통 계정으로 열려 있는 경우다. 이것은 5.1과 5.6(공격 표면 최소화)이 동시에 걸리는 결함이다. IXIT의 인터페이스 목록과 실제 포트 스캔 결과를 대조하는 것이 단일 시험 항목 중 가장 값이 크다.
영국 PSTI — 규격의 조항 네 개가 법이 된 사례
영국은 2024년 4월 29일부터 제품보안법(PSTI) 규정으로 소비자 연결형 제품에 세 가지 보안 요구를 의무화했다. 공통 기본 패스워드 금지, 취약점 신고 방법 공개, 최소 보안 업데이트 지원 기간 공개 다. 그리고 EN 303 645의 5.1-1, 5.1-2, 5.2-1, 5.3-13 조항을 충족하면 해당 요구를 충족한 것으로 간주하는 경로를 두었다.
이 사례가 보여주는 것은 두 가지다. 첫째, 법이 규격 전체가 아니라 특정 조항 만 끌어올 수 있다. 성적서에 조항 단위 판정이 있어야 이런 제도에 재사용된다. 둘째, 네 조항 중 셋이 문서·정책 증거 를 요구한다. 취약점 신고 창구와 지원 기간 공개는 기기 시험으로 확인할 수 없다.
국내 IoT 보안인증과의 관계
국내 정보통신망연결기기등 정보보호인증은 라이트·베이직·스탠다드 세 등급으로 나뉘며, 2025년 개편 안내 기준 등급별 인증 항목 수가 각각 10개·23개·41개 수준으로 제시되어 있다. 평가 영역은 식별 및 인증, 데이터 보호, 암호, 소프트웨어 보안, 업데이트 및 기술 지원, 운영체제·네트워크 보안, 하드웨어 보안이다.
EN 303 645의 13개 조항군과 영역이 크게 겹친다. 수출 제품이라면 한 기기에 대해 조항 대응표 한 장 을 만든다.
| EN 303 645 조항 | 국내 IoT 인증 항목 | EN 18031 요구 | 증거 파일 | 판정 |증거 파일 칸이 같으면 시험을 한 번만 한다. 칸이 다르면 어느 쪽 요구가 더 엄격한지 표시한다. 이 표를 처음부터 만드는 조직과 제도별로 따로 대응한 뒤 합치려는 조직의 비용 차이는 크다.
실무에서 왜 필요한가
EN 303 645 기반 시험을 설계할 때 실무에서 가장 흔한 실패는 기술이 아니라 입력 자료 에서 난다. 제조사가 IXIT를 부실하게 채워 오면 개념 평가를 할 수 없고, 시험소는 기기를 뜯어 보며 설계를 역추적하게 된다. 시험 기간이 늘어나는 원인의 대부분이 여기 있다. 제조사 쪽 QA가 이 레슨에서 가져가야 할 가장 실용적인 기술은 IXIT를 시험소가 바로 쓸 수 있게 채우는 능력 이다. 모듈 33 레슨 3에서 제품 설명서를 판촉 문서가 아니라 사양서로 쓰라고 했던 것과 같은 원리다.
권고 조항의 사유 기록도 실무 비용이 큰 곳이다. "해당 없음"이라고만 적은 사유는 평가에서 거의 받아들여지지 않는다. 기기 특성 → 위협 부재 또는 대체 통제 → 결론 의 세 단계로 적어야 한다.
시험소 쪽에서는 이 규격이 여러 제도의 공통 입력 이라는 점이 사업 구조를 바꾼다. 조항 단위 판정과 증거를 잘 구조화한 성적서 한 건이, 영국·EU·기타 라벨 제도에서 재사용된다. 성적서 서식을 조항 단위로 설계해야 하는 이유다.