구분	~2020	~2023	~2026	~2029	~2032	~2035	소계
신설	67	54	52	15	8	11	207
기존 전환	54	122	150	140	130	90	686
누적	121	297	499	654	792	893

부	내용	읽는 목적
6	SCL(System Configuration Language): XML 기반 설정 파일 형식	장치 능력과 변전소 구성을 파일로 주고받는 규칙
7-1	원리와 모델	서버·논리 장치·논리 노드의 계층 개념
7-2	ACSI(Abstract Communication Service Interface, 추상 통신 서비스 인터페이스)	읽기·쓰기·리포트·제어·파일 같은 서비스의 의미와 상태 전이
7-3	공통 데이터 클래스(CDC)	SPS, DPC, WYE처럼 데이터 객체가 가지는 속성 묶음
7-4	논리 노드와 데이터 객체	XCBR, MMXU, LPHD처럼 기능별 변수 이름 사전
8-1	MMS와 이더넷으로의 매핑	추상 서비스를 실제 패킷으로 바꾸는 규칙
9-2	샘플값(SV)의 이더넷 매핑	머징 유닛이 보내는 샘플 메시지
10	적합성 시험	시험 방법과 추상 시험 항목
7-420	분산전원·배전 자동화 논리 노드	태양광·저장장치·인버터의 데이터 모델

적용 대상	주요 문서
변전소 내부(제어센터·로컬 SCADA·IED)	IEC 61850-7-4
풍력 발전	IEC 61400-25
분산전원	IEC 61850-90-7, IEC 61850-7-420
수력 발전	IEC 61850-7-410
배전 시스템	IEC 61850-90-6

판	작업 시기	범위와 주요 변경
1판	2002~2005년	변전소 자동화
2판	2009~2013년	전력 계통 전반의 자동화로 범위 확대 · 표현 명확화 · 중복된 데이터 모델 정리 · 적용 도메인 확장
2.1판	2018~2021년	TISSUE 해결안 반영 · 표준의 UML 모델화 · 데이터 모델 무결성 보완 · 현재 가장 최신 판
다음 판	2025년~	신기술 적용과 보안 · 기능 보완과 추가

등급	시험소
A(14곳)	Central Power Research Institute(인도) · DNV(네덜란드) · Taiwan Testing and Certification Center(대만) · 한국전기연구원 · Xuchang KETOP Testing Research Institute(중국) · 한국산업기술시험원 · State Grid Electric Power Research Institute(중국) · Tecnalia(스페인) · TÜV Rheinland(독일) · TÜV SÜD China(중국) · UL Korea · Electrical Research & Development Association(인도) · CESI–KEMA Labs(이탈리아) · POWERGRID Advanced Research and Technology(인도)
B(4곳)	Hitachi Energy(스위스) · UK Grid Solutions(영국) · NARI-RELAYS Electric(중국) · Schneider-Electric China(중국)

시험 종류	2판 절차서	2.1판 절차서
서버	Server 61850-8-1 Ed2 Rev 2.0.6	Server 61850-8-1 Ed2 Amd1 Rev 1.4(2025년)
클라이언트	Client 61850-8-1 Ed2 Rev 1.2	Client 61850-8-1 Ed2 Amd1 Rev 1.0
GOOSE 성능	GOOSE Performance Ed2 Rev 2.5	없음
SCL 도구	SCL Engineering Tools Ed2 Rev 1.2(SCT, ICT)	Server ICT Ed2 Amd1 Rev 1.1 · SCT Tool Ed2 Amd1 TP 1.0

조건(근거 문서와 항목)	수행할 조건부 시험
SCL: 동시 연결 최대 수(DynAssociation max)가 1보다 큼	sAssN8
PIXIT Sr1: 품질 비트 상세 지원	sSrv9
PIXIT Sr2: 상세 비트 지원	sSrv10
PICS: SetDataValues 지원	sSrv6, sSrvN1e, sSrvN3
SCL: FC가 CF·DC·SP이고 valKind=Set인 열거형 속성	sSrvN2
SCL: blkEna 속성	sSrv11
SCL: Mod의 off·blocked·test 값 지원	sSrv12
SCL: GrRef(논리 장치 계층 참조)	sSrv13

절차서 칸	담긴 내용	읽는 법
항목 번호·목적	예: sSBOes1, "SelectWithValue, Operate and CommandTermination"	앞의 s는 서버용, c는 클라이언트용 항목
참조	관련 표준 조항과 PIXIT 항목	판정 근거가 되는 7-2·8-1 조항을 먼저 확인
시험 순서(Test description)	시험자가 보내는 요청을 번호 순으로 기술	여기부터 읽는다
기대 결과(Expected result)	각 단계에서 시험 대상 장치(DUT)가 보내야 할 응답	시험 순서의 번호와 짝지어 대조
주석(Comment)	시험 중 발견된 쟁점과 예외	TISSUE·Redmine 번호가 함께 적힌다

단계	기대 결과
1	장치가 SelectWithValue에 긍정 응답
2	장치가 Operate에 긍정 응답
3	장치가 CommandTermination+를 보냄
4	제어 대상이 선택 해제 상태(stSeld=거짓)로 돌아옴. 또는 다시 보낸 SelectWithValue·Operate에 원인 코드 Object-not-selected로 응답
5	조작 제한 시간이 지나면 CommandTermination−와 원인 코드 Invalid-position 또는 Time-limit-over
6	조작 제한 시간이 지나면 CommandTermination−와 원인 코드 Invalid-position

2편. 2.1판 서버 시험에서 달라진 항목: 데이터 모델, 예약, 제어, 시각, 파일, 설정 도구

2판 인증을 받았던 IED를 그대로 2.1판 시험에 가져오면 여러 항목에서 불합격이 나온다. 이 편은 그 항목을 데이터 모델, 리포트 예약, 제어, 시각 동기, 파일 전송, 설정 도구의 순서로 정리하고, 각 항목이 왜 바뀌었는지와 장치 쪽에서 무엇을 고쳐야 하는지를 설명한다.

바뀐 항목의 출처: TISSUE와 시험 절차서

1편에서 설명했듯이 2.1판은 2판에 개정 1호를 합친 판이고, 개정 내용의 상당수는 TISSUE 해결안에서 왔다. TISSUE에 등록되는 쟁점은 주로 두 종류다. 하나는 표준 문장이 두 가지로 읽혀서 제조사마다 다르게 구현한 경우이고, 다른 하나는 표준이 아무 말도 하지 않아서 제조사가 각자 정한 경우다. 해결안이 나오면 표준 문안이 바뀌고, UCAIug 시험 절차서에 그 동작을 확인하는 단계가 추가된다.

그래서 2.1판 서버 시험에서 새로 생긴 항목은 대부분 "예전에는 허용되던 동작을 이제는 불합격으로 판정한다"는 성격을 가진다. LPHD 값 일치, WYE 시각 일치, 리포트 제어 블록의 명시적 예약, 취소 요청의 파라미터 검사, 윤초 처리, 파일 경로 구분자는 모두 2판 제품이 다르게 동작하던 지점이다. 시험 절차서는 연 단위로 개정되고, 새 판이 나오면 1년의 유예 기간을 둔 뒤 새 판으로만 시험한다. 2.1판 서버 절차서는 1.4판, 클라이언트 절차서는 1.0판까지 나와 있다.

이 변화는 장치 제조사 혼자 대응할 수 있는 문제가 아니다. 국내 IED 제조사 다수는 통신 스택을 직접 만들지 않고 외부 업체의 IEC 61850 스택을 사서 쓴다. 스택이 2.1판 동작을 지원하지 않으면 제조사가 응용 코드에서 아무리 고쳐도 시험을 통과하기 어렵다. 리포트 예약 강제, 비휘발 저장, 파일 경로 규칙 같은 항목은 상용 스택이 아직 지원하지 않는 경우가 있다. 2.1판 대응은 응용 코드를 고치기 전에 쓰고 있는 통신 스택이 새 절차서의 동작을 지원하는지부터 확인하는 일로 시작한다.

데이터 모델: LPHD 값 일치, WYE 시각 일치, 비휘발 저장

IED의 데이터 모델은 물리 장치 하나를 서버로 두고, 그 안에 기능 단위의 논리 장치(LD)를 여러 개 두는 구조다. 모든 논리 장치는 두 개의 특별한 논리 노드를 정확히 하나씩 가진다. LLN0은 그 논리 장치 전체에 공통인 데이터(동작 모드, 데이터셋, 리포트 제어 블록 등)를 담고, LPHD(Physical Device Information)는 장치가 놓인 물리 하드웨어의 정보를 담는다. 일반 논리 노드는 XCBR1, XCBR2처럼 번호를 붙여 여러 개 둘 수 있지만, LLN0과 LPHD는 번호를 붙여 늘릴 수 없다.

물리 장치 하나에 논리 장치가 여럿 있어도 LPHD가 가리키는 하드웨어는 하나다. 출처: IEC 61850-7-4, TISSUE 1752.

문제는 LPHD가 논리 장치마다 하나씩 있다는 점이다. 논리 장치가 세 개면 LPHD도 세 개가 되는데, 이 셋은 모두 같은 하드웨어를 가리킨다. 그런데도 2판 제품 가운데에는 LPHD마다 값을 따로 관리하는 경우가 있었다. 한 논리 장치의 LPHD에서 값이 바뀌어도 다른 논리 장치의 LPHD는 이전 값을 그대로 보여 주는 식이다. 2.1판 시험은 한 LPHD의 값이 바뀌면 같은 물리 장치의 다른 LPHD 값도 함께 바뀌는지를 확인한다. 이 항목은 TISSUE 1752의 해결안에서 왔다. 하드웨어가 하나라면 하드웨어 정보도 하나라는 당연한 요구를 시험 항목으로 명시한 것이다.

시험 항목 번호는 sSrv16(Data in multiple non-proxy LPHD have consistent values)이다. 여기서 대리(proxy)는 다른 물리 장치의 정보를 대신 보여 주는 LPHD를 말하며, LPHD의 Proxy 속성이 거짓인 것만 자기 하드웨어를 가리킨다. 시험은 두 단계로 진행한다. 먼저 클라이언트가 모든 LPHD의 값을 읽어 Proxy=거짓인 LPHD들이 같은 값을 가지는지 본다. 다음으로 장치가 지원하면 한 LPHD의 시뮬레이션 표시(LPHD.Sim)를 켜고 모든 LPHD의 Sim 값을 다시 읽는다. Sim은 GOOSE·SV 구독을 실제 메시지 대신 시뮬레이션 메시지로 받게 하는 스위치다. 하나를 바꾸면 Proxy=거짓인 모든 LPHD의 Sim이 같은 값으로 바뀌어야 통과다.

WYE는 상 전압·전류처럼 3상 측정값을 담는 공통 데이터 클래스다. 선간 값을 담는 DEL, 대칭 성분을 담는 SEQ도 구조가 같다. 3상 회로는 A·B·C 세 상과 중성선으로 이루어지므로, WYE 객체에는 phsA, phsB, phsC, neut 네 개의 하위 객체가 있다. 계측 장치는 같은 시점에 네 값을 함께 샘플링해서 이 객체에 넣는다. 같은 시점의 값이므로 네 하위 객체의 시각(t)도 같아야 한다. 2.1판 시험은 한 상의 값만 바뀌었을 때에도 나머지 상의 시각이 함께 갱신되는지를 본다. 시험에서는 단상만 주입하는 경우가 많은데, 이때 값이 바뀐 A상의 시각만 새로 찍히고 B상과 C상은 옛 시각에 머무는 제품이 있었다. 시험 항목 sSrv15(WYE, DEL, SEQ time stamp)는 IEC 61850-7-3의 6.2, 6.3, 6.4, 6.5, 7.4.2절을 근거로 한다. 장비 시뮬레이터로 한 상의 측정값만 바꾼 뒤, CDC가 WYE·DEL·SEQ인 객체를 GetDataValues로 읽어 모든 하위 객체의 t가 같은지 확인한다. phsA.cVal, phsB.cVal, phsC.cVal, neut.cVal 가운데 하나라도 바뀌면 phsA.t, phsB.t, phsC.t, neut.t가 모두 마지막 변경 시각으로 같이 바뀌어야 한다.

세 번째는 비휘발 저장이다. 1편에서 설명한 기능 제약(FC) 가운데 설정값(SP), 구성값(CF), 설명 문자열(DC)처럼 운전 중에 통신으로 바꿀 수 있는 속성은 장치 전원이 꺼졌다가 켜져도 마지막으로 쓴 값을 유지해야 한다. 공장 초기화를 하면 SCL 파일의 초기값으로 돌아가지만, 단순 재기동으로는 바뀐 값이 사라지면 안 된다. 장치는 처음 부팅할 때 CID 파일의 초기값으로 데이터를 구성하지만, 운전 중에 값이 바뀌면 그다음 재부팅부터는 마지막으로 바뀐 값을 유지해야 한다. 시험 항목 sSrv17(Verify that the values in SetDataValues are non-volatile)은 IEC 61850-7-2의 표 54와 TISSUE 1822를 근거로 한다. 시험은 FC가 SP, DC, EX인 쓰기 가능 속성마다 SCL의 초기값과 다른 값을 SetDataValues로 쓰고, 다시 읽어 새 값이 들어갔는지 확인한다. 그다음 일시 정전을 흉내 내 장치를 재기동시키고, 다시 연결해 값을 읽어 새 값이 남아 있는지 본다. EX는 확장 정의 정보를 가리키는 기능 제약이다. 이 항목은 스택이 쓰기 요청을 받은 뒤 비휘발 메모리에 반영하는 경로를 제공해야 통과할 수 있다.

항목	2판에서 흔하던 동작	2.1판 시험의 판정 기준
LPHD 값 일치	논리 장치마다 LPHD 값을 따로 관리	한 LPHD가 바뀌면 같은 물리 장치의 모든 LPHD가 같은 값
WYE 시각 일치	값이 바뀐 상의 시각만 갱신	phsA·phsB·phsC·neut의 시각이 같음
비휘발 저장	재기동하면 SCL 초기값으로 복귀	통신으로 쓴 SP·CF·DC 값이 재기동 뒤에도 유지

리포트 제어 블록: 예약을 먼저 해야 한다

리포트(report)는 서버가 값의 변화를 스스로 클라이언트에 알리는 서비스다. 클라이언트가 계속 값을 물어보는 대신, 서버의 리포트 제어 블록(RCB)에 "데이터셋의 값이나 품질이 바뀌면 보내라", "주기적으로 보내라" 같은 조건을 써 두고 활성화(RptEna=참)하면 서버가 조건이 생길 때마다 리포트를 보낸다. 리포트 제어 블록에는 두 종류가 있다. 버퍼형(BRCB, Buffered RCB)은 연결이 끊긴 동안 생긴 사건을 버퍼에 쌓아 두었다가 다시 연결되면 한꺼번에 보내므로 사건이 빠지지 않는다. 비버퍼형(URCB, Unbuffered RCB)은 연결이 끊긴 동안의 사건을 버린다.

서버 하나에 클라이언트가 둘 이상 붙는 것이 보통이다. 변전소 운영 시스템과 원격 감시 장치가 같은 IED에 접속하는 식이다. 두 클라이언트가 같은 리포트 제어 블록의 설정을 동시에 바꾸면 서로의 설정을 덮어쓴다. 이를 막는 장치가 예약이다. 비버퍼형은 Resv라는 참·거짓 속성을, 버퍼형은 ResvTms라는 정수 속성을 쓴다. 한 클라이언트가 Resv를 참으로 쓰면 그 블록은 그 클라이언트의 것이 되고, 다른 클라이언트가 그 블록에 쓰기를 시도하면 서버는 부정 응답(Response−)을 보낸다. ResvTms는 양수이면 그 초만큼 예약을 유지하고, 0이면 예약이 없으며, −1이면 SCL 설정으로 특정 클라이언트에 미리 배정된 블록이다.

예약 없이 활성화를 요청했을 때 2판과 2.1판 서버의 응답 차이. 출처: IEC 61850-7-2 개정 1호(2020), UCAIug 2.1판 서버 시험 절차서.

2판에서는 예약 없이 곧바로 RptEna를 참으로 써도 서버가 받아들였지만, 2.1판은 Resv를 먼저 참으로 써서 예약하지 않은 활성화 요청을 거부한다. 활성화 요청이 들어오면 서버가 그 클라이언트를 위해 암묵적으로 예약(implicit reservation)을 해 주었기 때문이다. 2.1판은 이 동작을 없앴다. 클라이언트는 먼저 Resv를 읽어 거짓인지 확인하고, Resv를 참으로 써서 예약한 뒤, 설정을 바꾸고, 마지막에 RptEna를 참으로 써야 한다. 예약 없이 들어온 활성화 요청은 거부된다. 산업용 소프트웨어 회사 COPA-DATA는 자사 IEC 61850 드라이버 문서에서, 최신 판 표준에서는 ResvTms가 −1인 버퍼형 블록이라도 클라이언트가 능동적으로 예약해야 한다고 안내했다. 서버와 함께 서버에 붙는 SCADA 클라이언트도 바뀌어야 한다는 뜻이다.

위 설명은 자유 블록, 곧 어느 클라이언트에도 미리 배정되지 않은 블록의 경우다. SCL 파일에서 ClientLN으로 특정 클라이언트에 배정해 둔 블록(인스턴스 번호 01)은 규칙이 다르다. 이런 사전 배정 블록은 2판과 2.1판 모두 Resv를 읽으면 언제나 참이 나온다. 2판에서는 배정된 클라이언트가 바로 RptEna를 참으로 써서 쓸 수 있었고, Resv를 거짓으로 쓰려고 하면 부정 응답을 받았다. 2.1판에서는 배정된 클라이언트라도 먼저 Resv를 참으로 써야 RptEna를 쓸 수 있고, Resv를 거짓으로 쓰는 요청에는 긍정 응답을 받는다. 그래도 GetURCBValues로 다시 읽으면 Resv는 여전히 참이다. 쓰기는 받아들이되 SCL이 정한 배정 상태는 바뀌지 않는다는 뜻이다.

버퍼형도 같은 구조다. 자유 블록에서 ResvTms=0인 상태로 RptEna를 참으로 쓰면 2판 서버는 받아들이고 ResvTms를 기본값으로 바꾸어 암묵 예약을 하지만, 2.1판 서버는 거부한다. 2.1판에서는 ResvTms에 양수를 먼저 써야 한다. 사전 배정 블록은 2판과 2.1판 모두 ResvTms를 읽으면 언제나 −1이다. 2판에서는 배정된 클라이언트가 바로 활성화할 수 있었고 ResvTms에 양수를 쓰면 부정 응답을 받았다. 2.1판에서는 배정된 클라이언트도 ResvTms에 양수를 먼저 써야 하고, 0이나 양수를 쓰는 요청에 긍정 응답을 받지만 다시 읽으면 여전히 −1이다.

이 동작을 확인하는 대표 항목이 sBrN9와 sBr23이다. sBrN9(Enable a free and pre-assigned BRCB without reservation)는 자유 블록과 사전 배정 블록을 예약 없이 활성화해 보고 두 경우 모두 SetBRCBValues가 부정 응답을 받는지 본다. sBr23(Successful pre-assigned BRCB ResvTms reservation)은 IEC 61850-7-2의 17.2.3절을 근거로, 사전 배정 블록에 ResvTms를 써서 예약하는 정상 절차를 확인한다. 순서는 이렇다. 시험자가 ClientLN이 지정된 인스턴스 01 블록을 구성하고 클라이언트가 GetBRCBValues를 읽는다(ResvTms=−1이어야 한다). 인증 파라미터가 맞는 클라이언트가 블록을 예약·활성화하고 GI(일반 질의)를 걸어 리포트를 받은 뒤 비활성화·해제한다. 연결을 다시 맺어 ResvTms를 10초로 쓰고 다시 활성화한다. 그 뒤 GetBRCBValues를 읽고(여전히 −1), 연결을 해제한 뒤 12초를 기다렸다가 다시 연결해 읽는다(여전히 −1). 표준은 SCL로 미리 배정된 블록에서 ResvTms=0 쓰기는 소유 클라이언트의 예약 해제로, 양수 쓰기는 소유 확인으로 해석하되, 속성값은 계속 SCL 예약을 뜻하는 −1을 보여 주도록 정한다.

버퍼형 쪽에는 변화가 하나 더 있다. 2판에서는 ResvTms 속성 자체를 둘지 말지가 선택이었는데, 2.1판에서는 필수가 되었다. 그래서 2.1판 시험에는 버퍼형 리포트 제어 블록마다 ResvTms가 구성되어 있는지를 확인하는 항목이 생겼다. 예약 시간의 기본값은 PIXIT에 적고, 시험은 그 값과 실제 동작이 맞는지를 본다.

상황	2판 서버	2.1판 서버
예약 없이 RptEna=참	받아들이고 암묵 예약	거부(Response−)
Resv=참 뒤 RptEna=참	받아들임	받아들임
다른 클라이언트가 예약한 블록에 쓰기	거부	거부
BRCB의 ResvTms 속성	구성 여부 선택	반드시 구성
사전 배정 블록을 예약 없이 활성화	받아들임	거부(Resv=참 또는 ResvTms 양수 선행)
사전 배정 블록에 Resv=거짓 쓰기	거부	받아들임 · 읽으면 여전히 참
사전 배정 블록의 ResvTms 읽기	−1	−1

제어: 제어 방식, 동작 모드, 선택과 취소의 일치

제어(control)는 클라이언트가 서버에 명령을 보내 차단기나 개폐기를 여닫게 하는 서비스다. IEC 61850-7-2는 네 가지 제어 방식을 정한다. 직접 제어·정상 보안(DOns, Direct Operate with normal security), 선택 후 조작·정상 보안(SBOns, Select Before Operate), 직접 제어·강화 보안(DOes, enhanced security), 선택 후 조작·강화 보안(SBOes)이다. 앞쪽이 가장 단순하고 뒤쪽이 가장 엄격하다.

DOns에서 클라이언트는 Operate 요청 하나만 보낸다. 서버는 요청의 형식에 문제가 없으면 긍정 응답을 보내고 출력 접점을 움직인다. 그런데 차단기가 고장 났거나, 배선이 끊겼거나, 이미 그 위치에 있어서 실제로 아무 일도 일어나지 않았어도 서버는 그 사실을 알리지 않는다. 강화 보안 방식은 이 빈틈을 메운다. 서버는 출력을 보낸 뒤 차단기 위치가 실제로 바뀌었는지 확인하고, 그 결과를 CommandTermination 메시지로 알린다. 성공이면 긍정, 실패면 부정과 원인 코드(AddCause)를 보낸다.

선택 후 조작 방식은 Operate 전에 Select(또는 값을 함께 보내는 SelectWithValue)를 먼저 보낸다. "곧 이 값으로 조작하겠다"고 알리고, 서버가 받아들이면 정해진 선택 유지 시간 동안 그 제어 대상은 이 클라이언트만 조작할 수 있다. 다른 클라이언트가 같은 개폐기에 명령을 보내도 거부된다. 그 시간 안에 Operate가 오지 않으면 선택은 풀린다. 고압 설비를 잘못 조작했을 때의 결과가 크기 때문에, 변전소의 차단기 제어는 대개 SBOes를 쓴다.

강화 보안 선택 후 조작(SBOes)의 메시지 순서. 출처: IEC 61850-7-2 제어 모델.

2.1판에서 바뀐 첫째 항목은 동작 모드에 따른 제어 판정이다. 각 논리 노드에는 Mod(운전자가 설정한 모드)와 Beh(실제 동작 상태)가 있다. 값은 on(정상), blocked(동작하되 출력 차단), test(시험), test/blocked(시험하되 출력 차단), off(정지)다. 제어 요청에는 Test라는 표시가 있어 그 명령이 시험용인지 실제용인지를 알린다. 서버는 자기 동작 상태와 명령의 Test 표시를 비교해 받아들일지 정한다. 2.1판 시험 항목 sCtl5(Operate with test flag and mode test, test/blocked and blocked)는 각 조합에서 서버가 어떤 응답을 보내야 하는지, 그리고 거부할 때 원인 코드가 Blocked-by-mode인지를 확인한다. 일반 제어 명령과 함께, 논리 노드의 모드 자체를 바꾸는 Mod 제어 명령도 시험한다. Mod 제어가 막히면 시험 모드에서 빠져나올 방법이 없어지므로, Mod 제어는 어느 모드에서든 받아들여야 한다. 판정은 아래와 같다.

서버의 Beh	Test=거짓(실제 명령)	Test=참(시험 명령)	Mod 제어 명령
on	수락 · 출력 · CommandTermination+	거부 · Blocked-by-mode	Test=참이어도 수락·실행
test	거부 · Blocked-by-mode	수락 · 출력 · CommandTermination+	Test=거짓이어도 수락·실행
test/blocked	거부 · Blocked-by-mode	통신상 수락 · 출력 없음 · CommandTermination− (Blocked-by-mode)	Test=거짓이어도 수락·실행
blocked	통신상 수락 · 출력 없음 · CommandTermination− (Blocked-by-mode)	거부 · Blocked-by-mode	Test=거짓으로 수락·실행

출력 차단 모드의 판정이 특히 중요하다. 2판 시절의 절차서는 "명령을 받아들인다"고만 적었다. 2.1판 절차서는 통신상으로는 Operate에 긍정 응답을 보내되, 출력 신호는 내보내지 않고, CommandTermination을 부정으로 보내며 원인을 Blocked-by-mode로 적으라고 정했다. 클라이언트 입장에서는 명령이 전달은 되었지만 모드 때문에 실행되지 않았다는 사실을 정확히 알 수 있게 된다.

둘째 항목은 선택과 조작, 선택과 취소 사이의 파라미터 일치다. SelectWithValue에는 제어 값(ctlVal) 외에도 조작 시각(operTm), 명령 출처(origin), 명령 번호(ctlNum), 시각(T), Test 표시, 확인 조건(Check)이 함께 들어간다. Operate의 파라미터가 Select와 다르면 서버는 Operate를 거부해야 한다. "열겠다"고 선택해 놓고 "닫으라"고 조작하는 일을 막는 것이다. 이 검사는 2판에도 있었다. 2.1판에서는 같은 검사가 취소(Cancel)에도 적용된다. 선택한 뒤 마음을 바꾸어 Cancel을 보내면 다른 클라이언트가 그 대상을 쓸 수 있게 선택이 풀리는데, 이 Cancel의 파라미터가 Select와 다르면 거부해야 한다. 2판에서는 값이 달라도 취소를 받아들이던 제품이 많았으므로, 해당 시험 항목에 이 판정 단계가 새로 추가되었다.

해당 항목은 sSBOes8(Operate or Cancel with different value than the SelectWithValue of a SBOes control object)이며 IEC 61850-7-2의 표 108을 근거로 한다. 시험 순서와 기대 결과는 다음과 같다. 클라이언트가 Beh=on인 대상에 올바른 SelectWithValue를 보내면 긍정 응답을 받는다. 이어 ctlVal, origin.orIdent, origin.orCat, ctlNum, Test, Check 가운데 하나를 바꾼 Operate를 보내면 서버는 원인 코드 Inconsistent-parameters로 부정 응답해야 한다. Test만 참으로 바꾼 경우에는 Blocked-by-mode나 Inconsistent-parameters 가운데 하나로 거부할 수 있다. 그 뒤 제어 대상이 선택 해제 상태(stSeld=거짓)로 돌아오는지 확인하고, 다른 속성으로 이 과정을 반복한다. 새로 추가된 5~7단계는 Cancel을 시험한다. 올바른 SelectWithValue 뒤에 ctlVal, origin.orIdent, origin.orCat, ctlNum 가운데 하나가 다른 Cancel을 보내면 Inconsistent-parameters로 부정 응답해야 하고, 제어 대상은 선택 해제 상태로 돌아와야 한다.

시각: 시각 품질, 정확도 등급, 보유 시간, 윤초

변전소 장치는 사건이 일어난 시각을 정확히 남겨야 한다. 여러 IED의 기록을 합쳐 고장이 어디서 시작되어 어떻게 퍼졌는지를 재구성하려면 모든 장치의 시계가 같은 기준에 맞아 있어야 한다. 클라이언트·서버 통신을 하는 IED는 보통 SNTP(Simple Network Time Protocol)로 시간 서버에 시각을 맞추고, 머징 유닛처럼 마이크로초 단위가 필요한 장치는 IEEE 1588 정밀 시각 프로토콜(PTP)을 쓴다. 현장 제품은 보통 1분 주기로 시각을 맞추고, 적합성 시험에서는 관찰 시간을 줄이려고 10초 주기로 바꾸어 시험한다.

IEC 61850의 시각값(TimeStamp)은 1970년 1월 1일부터 센 UTC 초, 초 이하의 분수, 그리고 1바이트의 시각 품질(TimeQuality)로 이루어진다. 클라이언트는 이 품질 바이트를 보고 그 시각을 얼마나 믿을지 정한다. 첫 비트 LeapSecondsKnown은 윤초까지 반영한 시각인지, 둘째 비트 ClockFailure는 시계 자체가 고장인지, 셋째 비트 ClockNotSynchronized는 외부 기준과의 동기가 끊겼는지를 나타낸다. 나머지 다섯 비트 TimeAccuracy는 초 이하 부분 가운데 믿을 수 있는 비트 수다. 값이 n이면 시각의 불확도가 2의 −n제곱 초라는 뜻이다.

시각 품질 바이트의 비트 배치와 대표값. 0x87은 보유 시간 안에서 정확도를 낮춰 보고하는 예다. 출처: IEC 61850-7-2, 61850-8-1.

정상 동기 상태의 대표값은 0x8A다. 이진수로 1000 1010이므로 윤초를 반영한 시각이고, 고장과 비동기 표시는 없으며, 정확도는 10비트(약 1ms)다. 시간 서버와 연결이 끊기면 장치 시계는 자체 발진기로 계속 시각을 센다. 이 상태를 보유(holdover)라고 한다. 발진기는 기준과 조금씩 어긋나므로 정확도 비트 수는 시간이 지날수록 줄어든다. 2.1판은 장치가 보장하는 보유 시간 안에서는 정확도를 낮춰 보고하다가, 그 시간을 넘으면 ClockNotSynchronized를 세우도록 정리했다. 시험 절차서의 예에서는 동기가 끊긴 지 일정 시간이 지나 품질 바이트가 0x7F(0111 1111)로 바뀐다. 윤초 반영 비트가 내려가고, 고장·비동기 비트가 서고, 정확도는 미지정(31)이 된 상태다. ClockFailure를 비동기와 함께 세울지는 제조사마다 다르게 구현하며, PIXIT에 그 선택을 적는다.

이 동작을 시험하는 항목이 sTmN1(Lost time synchronisation)이다. 근거는 IEC 61850-7-2의 21절·6.1.2.9.3절·표 9, IEC 61850-8-1의 21절·6.4.2절, PIXIT의 Tm5 항목이다. 시험자는 모든 시간 서버를 끊고, 장비 시뮬레이터나 구독한 GOOSE 메시지로 상태 변화를 여러 번 일으켜 보유 시간 전후의 사건을 받는다. 그 뒤 시간 서버 하나를 다시 연결하고 같은 방식으로 사건을 받는다. 판정 기준은 단계별로 아래와 같다.

상태	품질 바이트	비트의 뜻
시간 서버와 정상 동기	0x8A(1000 1010)	LeapSecondsKnown=참 · ClockNotSynchronized=거짓 · 정확도 10비트(T1)
연결이 끊긴 뒤 보유 시간 이내	0x8A 또는 0x87(1000 0111)	비트 변화 없음 · 정확도는 T1에서 T0으로 낮출 수 있음(10→7)
보유 시간이 끝난 뒤	0x7F(0111 1111)	LeapSecondsKnown=거짓 · ClockNotSynchronized=참 · 정확도 미지정(31)
다시 연결해 동기 회복	0x8A	LeapSecondsKnown=참 · ClockNotSynchronized=거짓 · 정확도 회복(31→10)

보유 시간(HoldOverTime)은 IEC 61850에서 시각 관리 논리 노드 LTMS의 HoldTms 속성으로 표현한다. 정의는 시간 서버와 연결이 끊긴 뒤, 기준 시계의 UTC와 장치 내부 시계의 차이가 그 정확도 등급이 허용하는 최대 범위를 넘지 않는 기간이다. T1 등급으로 보고하던 장치라면 차이가 등급의 허용 범위 안에 있는 동안이 보유 시간이다. 보유 시간은 장치가 발진기 특성으로 동적으로 계산하게 할 수도 있고, 고정값으로 정할 수도 있다. 보유 시간을 0으로 정하면 연결 끊김을 알아챈 순간 곧바로 품질 바이트가 0x7F로 바뀐다. 절차서는 장치가 정확도를 동적으로 낮추면서 미지정 값에 이를 때까지 기다리는 경우 보유 시간이 꽤 길어질 수 있다고 적는다.

정확도 비트 수는 IEC 61850-5가 정한 시각 정확도 등급과 대응한다. T0는 10ms, T1은 1ms, T2는 100µs, T3는 25µs, T4는 4µs, T5는 1µs가 기준이다. 사건 기록용 IED는 T1 정도면 충분하지만, 샘플값을 내보내는 머징 유닛은 상 사이의 시각 차이가 측정 오차로 바로 이어지므로 T4 이상이 필요하다.

시각 정확도 등급별 기준값과 그 기준을 만족하는 TimeAccuracy 비트 수. 막대는 2의 −n제곱 초를 마이크로초로 나타낸 값이다. 출처: IEC 61850-5 시각 정확도 등급.

2.1판 시험에서 시간이 가장 많이 걸리는 항목은 윤초 처리다. 윤초는 지구 자전 속도로 정하는 천문시(UT1)와 원자시계로 세는 UTC의 차이가 0.9초를 넘지 않게 하려고 UTC에 1초를 끼워 넣는 조정이다. 주기가 정해져 있지 않고, 지구 자전 관측 결과에 따라 국제지구자전좌표국(IERS)이 6개월 전쯤 발표한다. 1972년부터 2016년 말까지 모두 27번 들어갔고 모두 1초를 더하는 조정이었다. 마지막 윤초는 2016년 12월 31일 23:59:60이다.

2016년 마지막 윤초 전후에 IEC 61850 장치가 기록하는 초 카운터와 시각 품질. 출처: IERS 공보 C, IEC 61850-8-1 시각 표현.

1970년부터 센 초 카운터에는 23:59:60을 표현할 자리가 없다. 그래서 IEC 61850 장치는 윤초 1초 동안 다음 날 00:00:00과 같은 초 값을 쓰고, 그 1초 동안만 LeapSecondsKnown 비트를 0으로 내려 "이 시각은 윤초 구간이다"라고 표시한다. 시험은 윤초가 들어가는 날 자정 전후로 입력을 계속 바꾸어 리포트를 일으키고, 윤초 1초 동안 생긴 리포트의 품질 바이트에서 첫 비트가 빠졌는지(0x8A가 0x0A로 바뀌었는지), 그 뒤 다시 0x8A로 돌아오는지를 확인한다. 2.1판 7-2 개정은 보유 중인 장치가 자정에 윤초가 들어가는지 알 수 없는 경우까지 정했다. 이때는 자정에 ClockNotSynchronized를 세우고 동기가 회복될 때까지 유지한다.

윤초 시험 항목 sTm7(Process a leap second)의 근거는 IEC 61850-7-2의 6.2.3.7절과 표 9, IEC 61850-8-1의 부속서 F.2.3, PIXIT의 Tm3·Tm5다. 절차는 네 단계다. ① 시험자가 SNTP 시간 서버를 연결하고, 날짜와 시각을 다음 6월 30일이나 12월 31일 자정 약 1시간 전으로 바꾼다. 이때 SNTP 서버는 윤초 예고 표시(LI, Leap Indicator=1)로 양의 윤초를 알린다. LI는 다음 자정에 윤초가 들어간다는 사실을 알리는 SNTP 메시지의 표시다. ② 시험자는 자정 직전에 시간 서버를 끊되, 보유 시간이 00:00:10 전에 끝나지 않도록 시점을 고른다. ③ 장비 시뮬레이터나 구독한 GOOSE로 윤초 전후에 상태 변화를 일으킨다. ④ 클라이언트가 GetDataValues나 리포트·GOOSE로 그 사건들을 받는다.

기대 결과에서 윤초 전 사건은 ClockNotSynchronized=거짓, LeapSecondsKnown=참이고 윤초가 반영되지 않은 시각이어야 하며, 윤초 뒤 사건은 같은 비트 상태에 윤초가 반영된 시각이어야 한다. 1단계에서 LI를 미리 받았으므로, 자정 전에 연결이 끊겨도 장치는 윤초가 있다는 사실을 기억하고 있어야 한다. 윤초를 넣는 날짜는 ITU-R 권고 CCIR 460-4가 정한다. 양이든 음이든 윤초는 UTC 월의 마지막 초에 넣고, 첫째 선호는 12월과 6월 말, 둘째 선호는 3월과 9월 말이다. 패킷 분석기 Wireshark는 23:59:60을 표현하지 못해 윤초를 00:00:00으로 해석해 보여 주므로, 품질 바이트를 함께 보지 않으면 시험 결과를 잘못 읽기 쉽다.

윤초 자체는 곧 끝난다. 국제도량형총회(CGPM)는 2026년 10월 15일 제28차 총회 결의 5에서 2027년 5월 20일부터 UTC에 윤초를 넣지 않기로 했고, UT1과의 허용 차이를 3,600초(1시간)로 넓혔다. 2022년 총회가 2035년까지 허용 차이를 넓히기로 했던 일정을 앞당긴 것이다. 최근 지구 자전이 빨라져 역사상 처음으로 1초를 빼는 음의 윤초가 필요해질 수 있다는 점이 앞당긴 이유였다. 2026년 말에는 윤초가 없고, 다음 후보 날짜인 2027년 6월 말은 이미 연속 UTC 기간에 들어간다. 따라서 TAI(국제원자시)와 UTC의 차이는 37초로 고정된다.

윤초 시험은 그 뒤에도 의미가 있다. 현장에 깔린 장치와 시간 서버, SCADA는 수십 년 동안 운전되고, 그 소프트웨어는 윤초 처리 코드를 그대로 가지고 있다. 2016년 마지막 윤초 때 클라우드플레어의 DNS 서비스 일부가 시간 계산 오류로 장애를 겪었듯이, 거의 쓰이지 않는 코드 경로는 실제로 실행될 때 문제를 드러낸다. 윤초가 폐지되어도 장치가 시각 품질 비트를 정확히 보고하고, 시각 서버의 이상 신호에 일관되게 반응하는지를 확인하는 시험의 필요는 그대로 남는다.

파일 전송과 설정 도구

IED는 고장 기록(COMTRADE 파일), 사건 기록, 설정 파일을 파일 서비스로 내보낸다. 클라이언트는 GetServerDirectory로 파일 목록을 받고, GetFile로 파일을 내려받는다. 2판에서는 폴더와 파일 이름 사이의 구분자로 역슬래시(\)와 슬래시(/) 가운데 하나를 고를 수 있었고, 경로를 어떤 문자로 시작할지도 정해져 있지 않았다. 2.1판은 구분자를 슬래시 하나로 정했고, 경로는 루트를 나타내는 슬래시로 시작하도록 했다. 2판에서는 PIXIT에 어느 구분자를 쓰는지 적게 했지만, 2.1판은 슬래시로 고정했다. 장치 안의 운영체제가 윈도우든 리눅스든 통신상의 경로 표기는 같아야 한다는 뜻이다.

시험 항목은 sFt1(GetServerDirectory(FILE))이며 IEC 61850-7-2의 7.2.2절·23.1.1절, IEC 61850-8-1의 23절, PIXIT의 Ft2·Ft3·Ft4를 근거로 한다. 클라이언트가 파일 이름을 비운 GetServerDirectory를 보내면 장치는 파일 이름과 속성(크기, 마지막 수정 시각)을 담은 목록으로 응답해야 한다. 파일 이름은 255자를 넘지 않아야 하고, 모든 이름은 "/"로 시작하며 구분자로 "/"를 쓰고, 폴더 이름은 "/"로 끝나야 한다. 경로는 절대 경로로 쓴다. 예를 들어 응답 목록에는 /FTU_R300_V01.cid, /COMTRADE/, /COMTRADE/FIWAVE7.CFG, /COMTRADE/FIWAVE7.DAT처럼 적힌다. 시험은 이어서 MMS 메시지 크기를 줄이고 파일을 많이 만들어 목록이 여러 응답으로 나뉘게 한다. 이때 장치는 첫 응답들에 moreFollows=참을 넣고, 클라이언트가 마지막으로 받은 파일 이름을 continueAfter로 넘겨 다시 요청하면 그다음부터 목록을 이어 보내며, 마지막 응답에는 moreFollows=거짓을 넣거나 생략해야 한다. 확장자가 3바이트를 넘지 않아야 한다는 권고도 있지만, 넘었다고 불합격 처리하지는 않는다.

마지막은 설정 도구다. IEC 61850-6은 장치와 시스템의 설정을 SCL(System Configuration Language)이라는 XML 형식 파일로 주고받게 한다. 파일 종류는 용도에 따라 다르다. ICD(IED Capability Description)는 제조사가 그 장치가 할 수 있는 것을 기술한 파일이고, SSD(System Specification Description)는 변전소 단선도와 기능 배치를, SCD(Substation Configuration Description)는 변전소 전체 장치와 통신 구성을, CID(Configured IED Description)는 특정 장치 한 대에 적재할 최종 설정을 담는다. 제조사 도구인 ICT(IED Configuration Tool)는 ICD를 만들고 SCD에서 자기 장치 부분을 읽어 CID를 만든다. 시스템 설정 도구인 SCT(System Configuration Tool)는 여러 제조사의 ICD와 SSD를 합쳐 SCD를 만든다.

SCL 파일이 제조사 도구와 시스템 도구 사이를 오가는 순서. 출처: IEC 61850-6, UCAIug 상호운용성 시험 보고.

이 흐름은 파일이 스키마와 규칙에 맞을 때만 동작한다. UCAIug의 2019년 상호운용성 시험에서 제출된 ICD 파일 159개 가운데 오류 없이 검증을 통과한 것은 10개(6.28퍼센트)에 그쳤다. 이 결과 뒤 UCAIug는 2.1판 서버 인증 시험에 ICT 기능을 필수로 넣었다. 장치가 통신을 잘해도, 그 장치를 설명하는 파일을 도구가 올바르게 만들고 읽지 못하면 인증을 받을 수 없게 된 것이다. 국내 현장에는 이전 프로젝트의 SCL 파일을 텍스트 편집기로 열어 손으로 고치는 관행이 남아 있다. 2.1판 절차서에서는 이런 방식으로 ICT 시험 항목을 통과할 수 없다.

파일	만드는 쪽	담는 내용
ICD	제조사 ICT	장치 형식의 능력 · 데이터 모델 · 지원 서비스
IID	제조사 ICT	특정 프로젝트에 맞게 고친 장치 한 대의 설명
SSD	SCT	단선도 · 변전소 기능의 배치
SCD	SCT	변전소 전체 장치 · 통신 주소 · GOOSE·리포트 구독
CID	제조사 ICT	장치에 적재해 운전하는 최종 설정

결론 — 2.1판은 모호하던 동작을 하나로 정했다

2.1판 서버 시험에서 달라진 항목을 모아 보면 공통점이 있다. LPHD 값 일치와 WYE 시각 일치는 물리적으로 하나인 대상을 데이터 모델에서도 하나로 다루라는 요구이고, 비휘발 저장은 통신으로 바꾼 설정이 재기동 뒤에도 유지되어야 한다는 요구다. 리포트 예약 강제와 취소 파라미터 검사는 여러 클라이언트가 한 서버를 함께 쓸 때 생기는 충돌을 막는다. 동작 모드별 제어 판정은 시험 명령과 실제 명령이 섞이지 않게 하고, 시각 품질과 윤초 처리는 기록된 시각을 얼마나 믿을지를 클라이언트가 판단할 수 있게 한다. 파일 경로 규칙과 ICT 필수화는 장치 밖의 도구와 파일까지 상호운용성 범위에 넣었다.

이 변화는 하나하나 보면 작은 수정이지만, 2판 제품을 그대로 가져오면 여러 블록에서 동시에 불합격이 난다. 2.1판 대응의 핵심은 2판에서 제조사마다 다르게 해석하던 동작을 시험 절차서가 정한 한 가지 동작으로 맞추는 일이다. 그 작업은 통신 스택, 응용 코드, SCL 도구, 그리고 서버에 붙는 클라이언트까지 함께 바꿔야 끝난다. 3편에서는 이 통신 위에 메시지 단위의 인증과 암호화를 얹는 IEC 62351-4를 다룬다.

3편. IEC 62351-4 종단간 보안: MMS 메시지에 서명과 암호를 거는 방법

IEC 61850의 MMS 통신은 기본적으로 평문이다. 패킷 분석기로 보면 어떤 클라이언트가 어느 리포트 제어 블록을 예약했고 어느 차단기에 무슨 명령을 보냈는지가 그대로 읽힌다. 이 편은 그 메시지에 인증과 무결성, 암호화를 붙이는 IEC 62351-4를 다룬다. 보안 표준이 필요해진 배경, 구간 보호와 종단간 보호의 차이, 보안 메시지의 구조, 키를 만드는 절차, 재전송 방지와 키 갱신, 그리고 적합성 시험의 구성을 차례로 설명한다.

전력 통신에 보안 표준이 필요해진 배경

변전소 통신은 오랫동안 외부와 분리된 전용망 안에 있다는 이유로 보안을 따로 두지 않았다. IEC 61850도 데이터 모델과 통신 서비스를 정할 뿐, 메시지를 누가 보냈는지 확인하거나 내용을 숨기는 기능은 정하지 않는다. 그런데 변전소 장치가 이더넷과 TCP/IP로 연결되고 원격 감시와 유지보수를 위해 상위망과 이어지면서, 공격자가 통신망 안에 들어오면 계량값을 바꾸거나 정상 상태의 차단기를 여는 일이 기술적으로 가능해졌다.

그 가능성은 실제 사건으로 확인되었다. 2015년 12월 23일 우크라이나 서부의 배전회사 세 곳이 공격을 받아 약 22만 5천 명이 정전을 겪었다. 산업 보안 회사 Dragos의 분석에 따르면 공격자는 몇 달 전 피싱 메일로 사무망에 들어왔고, 그 뒤 SCADA 운영 화면을 원격으로 조작해 변전소 차단기를 열었다. 고객이 정전 신고를 하지 못하도록 콜센터 전화선에 대량 호출을 걸기도 했다. 1년 뒤인 2016년 12월에는 키이우 인근 송전 변전소가 공격받았는데, 이때 쓰인 악성코드 Industroyer는 IEC 60870-5-101·104, IEC 61850, OPC DA 같은 전력 통신 프로토콜을 직접 다루는 모듈을 갖추고 있었다. 사람이 화면을 조작하지 않아도 악성코드가 표준 프로토콜로 차단기 명령을 보낼 수 있다는 점이 드러난 것이다.

전력 통신 보안과 관련된 공격 사례, 표준 발행, 유럽 규제의 시점. 출처: Dragos, MITRE ATT&CK C0028, IEC 웹스토어, EU 규정 2024/2847.

규제도 따라왔다. 유럽연합의 사이버 복원력법(CRA, Cyber Resilience Act)은 디지털 요소를 가진 제품을 유럽 시장에 내놓는 제조사에 보안 요건을 지운다. 이 법은 2024년 12월 10일 발효되었고, 취약점과 사고 보고 의무는 2026년 9월 11일부터, 필수 보안 요건은 2027년 12월 11일부터 적용된다. 유럽에 판매하는 지능형 전력기기에는 IEC 62443이나 IEC 62351 같은 국제 보안 표준을 근거로 보안성을 입증하라는 요구가 커지고 있다. 국내 전력회사는 아직 이 수준을 요구하지 않지만, 보안 기능을 갖춘 수입 장비가 들어오고 수출 제품이 같은 기능을 갖추게 되면 국내 구매 규격도 영향을 받을 수밖에 없다.

보안 시험의 수요는 여러 곳에서 커지고 있다. 유럽의 송전망 운영자는 IEC 61850 인증과 함께 IEC 62351 시험 성적서를 요구하기 시작했다. 북미에서는 NERC CIP(North American Electric Reliability Corporation Critical Infrastructure Protection) 규정이 산업 표준에 기반한 보안 조치를 강화하고 있다. NERC CIP는 북미 전력망 운영 기관이 지켜야 하는 사이버 보안 의무 규정이다. 한전도 SCADA와 연계되는 제품의 보안성을 강화하는 방안을 연구하고 있다. 반면 국내에는 전력·에너지 분야 제품의 통신 보안 기술을 전문적으로 시험할 체계, 곧 품질 문서와 절차서, 시험 장비와 환경이 부족하다. IEC 62351로 KOLAS 공인을 받은 국내 시험소가 없어 해외 시험소에 의존해 왔다. 기업들이 스스로 비용을 들여 보안 점검을 하지만 기술 숙련도가 충분하지 않아 수행 범위가 제한적이다. 해외에서는 TÜV SÜD(독일), DNV(노르웨이), UL(미국) 같은 시험소가 IEC 62351 시험을 제공하지만, 시험 기간이 길고 비용이 높아 발급 건수는 적다.

인증 체계는 이제 갖춰지는 단계다. UCAIug는 전력 통신 분야(IEC 61850, CIM, DNP3, OpenFMB)의 국제 인증 기관으로서 인증서 발급, 시험 절차서 개발, 시험소 자격 검증과 지정·관리를 맡는다. 전 세계 IEC 61850 UCAIug 인증서는 해마다 약 100건 발급된다. UCAIug는 IEC 61850 제품을 대상으로 한 IEC 62351-4 인증 서비스를 2026년부터 시작할 계획을 세웠고, 62351-4 시험 절차서는 2025년 12월에 완성되었으며, 62351-3 절차서는 개발이 예정되어 있다. 국내에서는 KTL이 2026년 9월부터 IEC 62351-4 KOLAS 성적서를 발급할 수 있게 되었고, UCAIug 국제 인증서까지 발급할 수 있는 공인 시험소 지정을 추진하고 있다. 지정 자격 조건은 IEC 61850 시험 자격을 이미 가진 기관이다.

IEC 62351 시리즈의 구성과 IEC 62443과의 관계

IEC TC 57에서 IEC 61850을 만드는 곳은 제10작업반이고, 보안 표준은 제15작업반(WG 15)이 따로 만든다. 그 결과물이 IEC 62351 시리즈다. 이 시리즈는 TC 57이 만든 통신 프로토콜마다 대응하는 보안 부를 둔다. 아래 표는 주요 부와 그 부가 보호하는 대상을 정리한 것이다.

부	제목	보호 대상
3	TCP/IP를 포함하는 프로파일	TLS 사용 규칙 · 61850 MMS, 60870-5-104, DNP3/IP 등의 전송 구간
4	MMS와 유사 페이로드를 포함하는 프로파일	61850 MMS, TASE.2의 응용 계층 · 종단간 보안
5	IEC 60870-5와 파생 규격	60870-5-101·104, DNP3의 인증
6	IEC 61850 피어 간 프로파일	GOOSE, SV의 무결성
7	네트워크·시스템 관리	장치 상태를 감시하는 관리 객체
8	역할 기반 접근 제어(RBAC)	사용자·장치의 권한
9	키 관리	인증서와 그룹 키의 발급·폐기
100-x	적합성 시험	100-3은 3부, 100-4는 4부의 시험 사양

IEC 62443은 산업 자동화 시스템 전체의 보안 체계를 다루는 다른 시리즈다. 제품을 설계하고 개발하는 과정의 보안 요건(62443-4-1), 부품이 갖춰야 할 보안 기능(62443-4-2), 시스템을 구역으로 나누고 보안 수준을 정하는 방법 등을 정한다. 장치 뒷면 덮개를 열면 장치가 꺼지는 물리 보호까지 이 시리즈의 범위에 들어간다. 반면 IEC 62351은 통신 메시지 자체를 보호하는 요소 기술이다. 제조사가 먼저 도입하는 쪽은 대개 62443이고, 62351은 구현해야 할 요소 기술이 어려워 도입이 늦다. 두 시리즈는 서로를 대신하지 않는다. 62443이 개발 과정과 장치의 보안 기능 목록을 요구하면, 그 목록 가운데 통신 보호 항목을 실제로 구현하는 방법이 62351에 있다.

IEC 61850과 IEC 62351의 관계를 계층별로 정리하면 아래와 같다. 62351-4는 TLS 암호화에 그치지 않고, IEC 61850 MMS 응용 계층의 메시지 서명과 무결성 보호, 그리고 종단간 암호화를 결합한 보안 체계를 요구한다. IEC 61850 메시지 단위에서 무결성, 기밀성, 부인 방지를 보장하는 추가 기술이다. 부인 방지는 메시지를 보낸 쪽이 나중에 보낸 사실을 부정할 수 없게 하는 성질이다.

계층	보호 대상	보안 요구사항
응용 계층(62351-4)	MMS(IEC 61850)	MMS 메시지 서명과 무결성 검사 · 연관 식별(AP-title, AE-qualifier) · 종단간 암호화와 ClearTransfer · 세션·데이터 키 재교환(Rekey)
TLS(62351-3)	핸드셰이크 · 암호 사양 변경 · 경보 · 레코드	네트워크 암호화(TLS 1.2) · 인증서 기반 상호 인증 · 세션 암호화와 무결성 보호 · 취약한 암호 묶음 사용 제한 · CRL/OCSP 인증서 폐기 검증
전송 계층	TCP/IP	위 두 계층이 보호한다

구간 보호와 종단간 보호

IEC 62351-3은 TCP 연결을 TLS(Transport Layer Security)로 보호하는 방법을 정한다. TLS는 인터넷 뱅킹과 웹 접속에 쓰는 바로 그 프로토콜이다. 62351-3은 TLS 자체를 새로 정하지 않고, TLS 1.2와 1.3 가운데 어떤 버전과 암호 묶음을 반드시 지원해야 하는지, 인증서를 어떻게 검증하고 세션을 언제 다시 협상하는지 같은 사용 규칙을 정한다. 2023년에 나온 2판이 TLS 1.3 프로파일을 추가했다. TLS 1.2의 연결은 다음 순서로 맺는다. 클라이언트가 ClientHello를 보내면, 서버는 ServerHello, 자기 인증서(Certificate), 키 교환 정보(ServerKeyExchange)를 보낸다. 클라이언트는 ClientKeyExchange, ChangeCipherSpec, Finished를 보내고, 서버가 ChangeCipherSpec과 Finished로 답하면 그 뒤의 데이터는 암호화된다.

TLS의 한계는 연결 단위로 보호한다는 데 있다. 변전소의 IED가 보낸 메시지가 게이트웨이나 프록시를 거쳐 원격의 SCADA로 가는 경우, TLS 연결은 IED와 게이트웨이 사이, 게이트웨이와 SCADA 사이에 따로 맺어진다. 게이트웨이는 받은 메시지를 풀어서 읽고 다시 암호화해 보낸다. 그 순간 게이트웨이 안에서는 메시지가 평문으로 존재하므로, 게이트웨이를 장악한 공격자는 내용을 바꿔 보낼 수 있다. 수신자는 TLS가 정상이었으므로 그 변조를 알아채지 못한다.

TLS의 구간 보호와 IEC 62351-4의 종단간 보호 비교. 출처: IEC 62351-3, 62351-4.

IEC 62351-4는 이 문제를 응용 계층에서 푼다. 보호 대상인 MMS 메시지 자체에 서명과 무결성 값을 붙이고 필요하면 암호화한다. 중간 장치는 메시지를 그대로 넘길 뿐 내용을 알 수 없고, 바꾸면 최종 수신자의 검증이 실패한다. 이것을 종단간 보안(E2E security, End-to-End security)이라고 부른다. TLS가 지키는 것은 두 장치 사이의 연결이고, 62351-4가 지키는 것은 출발지에서 목적지까지 가는 메시지 그 자체다. 62351-4는 TLS를 함께 쓰는 구성도 허용하므로, 실제 장치는 전송 구간에 TLS를 걸고 그 위에서 메시지 단위 보호를 한 겹 더 거는 방식으로 쓸 수 있다.

구분	구간 보호(hop-by-hop)	종단간 보호(end-to-end)
보호 단위	인접한 두 장치 사이의 연결	출발지에서 목적지까지의 메시지
중계 장치	복호화한 뒤 다시 암호화 · 내용 열람과 변조 가능	암호화된 덩어리만 전달 · 내용을 알 수 없음
대표 기술	TLS(IEC 62351-3)	IEC 62351-4 E2E 보안

보안 메시지의 구조와 11가지 메시지

62351-4는 보호할 메시지를 세 겹으로 싼다. 가장 안쪽이 보호 대상 응용 메시지(PrPDU, Protected Protocol Data Unit)다. IEC 61850에서는 MMS의 연결 요청, 읽기·쓰기, 리포트, 제어 메시지가 여기에 들어간다. 그 바깥을 보안 메시지(SecPDU)가 싼다. SecPDU에는 토큰이라고 부르는 보안 정보(버전, 연관 식별자, 시각, 순번, 알고리즘 등)와 서명 또는 무결성 검사 값(ICV, Integrity Check Value)이 들어간다. 가장 바깥은 운반 환경에 맞춘 EnvPDU다. OSI 환경에서는 ACSE와 프레젠테이션 계층 규칙에 맞추어 싸고, XMPP 같은 다른 환경에서는 그 환경의 형식으로 싼다. 같은 SecPDU를 여러 운반 환경에서 재사용할 수 있게 한 설계다. 클라이언트와 서버 사이에 중계 시스템(intermedium system)이 있어도 보호 대상 프로토콜과 E2E 보안 부분은 양 끝에서만 처리되고, 중계 시스템은 운반 환경만 다룬다.

IEC 62351-4가 MMS 메시지를 싸는 세 겹 구조. 출처: IEC 62351-4:2018 그림 6·7.

IEC 61850-7-2가 연결, 해제, 읽기, 쓰기 같은 서비스를 정하듯이, 62351-4는 SecPDU의 종류를 11가지로 정한다. 연결을 시작할 때의 핸드셰이크 메시지, 연결을 거부하거나 중단할 때의 메시지, 정상 종료 메시지, 그리고 연결 뒤의 데이터 전송 메시지다. 연결 요청과 해제를 뺀 나머지 MMS 메시지는 모두 데이터 전송 메시지 두 종류 가운데 하나에 실린다.

번호	메시지	방향	용도
1	HandshakeReq	클라이언트→서버	보안 연관 요청 · 알고리즘 제안, 인증서, DH 공개키 전달 · MMS 연결 요청을 함께 실음
2	HandshakeAcc	서버→클라이언트	요청 수락 · 서버 인증서와 공개키, 확정한 알고리즘 전달
3	ApplicationReject	서버→클라이언트	보안 절차는 통과했지만 MMS 수준에서 연결을 거부
4	HandshakeSecReject	서버→클라이언트	보안 파라미터 불일치·인증 실패로 거부 · 진단 코드 포함 가능
5	HandshakeSecAbort	클라이언트→서버	핸드셰이크 중 복구할 수 없는 보안 오류(서명 검증 실패 등)로 중단
6	DtSecAbort	양방향	데이터 전송 중 무결성 실패·순번 오류 같은 보안 위반으로 중단
7	ApplAbort	양방향	상위 응용(MMS)의 요청으로 보안 연관 중단
8	ReleaseReq	클라이언트→서버	보안 연관의 정상 종료 요청
9	ReleaseRsp	서버→클라이언트	정상 종료 확인
10	ClearTransfer	양방향	MMS 메시지를 평문으로 싣고 무결성 값만 붙임
11	EncrTransfer	양방향	MMS 메시지를 암호화하고 무결성까지 보호

거부 메시지가 둘로 나뉜 점에 주의해야 한다. ApplicationReject는 보안 쪽에는 문제가 없지만 MMS 연결 요청 자체가 받아들여지지 않을 때 쓰고, HandshakeSecReject는 MMS 요청에는 문제가 없지만 보안 검증에 실패했을 때 쓴다. 시험에서는 두 경우를 구별해 올바른 메시지로 거부하는지를 확인한다.

핸드셰이크: 인증서, 공개키, 알고리즘 협상

핸드셰이크 요청과 수락 메시지에는 보호 대상 프로토콜의 이름(pp), 서명 대상 부분(tbs, to be signed), 서명(sign)이 있다. tbs 안에는 토큰 1과 보호 대상 응용 데이터, 곧 MMS 연결 요청이나 응답이 들어간다. 토큰 1의 주요 필드는 다음과 같다. 버전은 현재 1이다. 기능 표시는 TLS와 E2E 보안을 각각 지원하는지를 비트로 알린다. 연관 식별자(association ID)는 클라이언트와 서버가 각자 고른 번호를 이어 붙여 이 보안 연관을 구별하는 값이다. 그 밖에 자기 쪽 DH 공개키, 메시지를 만든 시각, 앞으로 쓸 암호화·무결성 알고리즘을 지정하는 암호 모드(encr-mode)가 있다.

EnvPDU에는 응용 문맥 이름(application-context-name) 1.0.62351.4.1.2.1.1이 들어간다. 이 객체 식별자는 iso(1) standard(0) iec62351(62351) part4(4) abstract-syntax(1) e2eSecurity(2) version1(1) e2eMMS(1)를 뜻한다. SecPDU의 pp에는 보호 대상 프로토콜 이름 "IEC 61850-8-1"이 들어가며 요청 메시지에만 있다. sign에는 서명에 쓴 알고리즘(algo)과 메시지를 만든 쪽의 전자 서명(sign)이 들어간다. 토큰 1의 필드 전체는 아래와 같다.

번호	필드	내용
1	version	V1(0) 고정값 · 비트로 1000 0000
2	confParams	tlsProtected(0)과 applProtected(1) · 둘 다 지원하면 1100 0000 · 응용 계층 암호화를 지원할 때만 applProtected를 1로 설정
3	assID	연관 식별자 · 예 "123:123" · 1~3자리 숫자 두 개를 콜론으로 잇거나 하나만 씀
4	dHKey	디피-헬만 파라미터 묶음(groupId, dhPublicKey) · 세션 키를 만들 공개키 교환
5	time	tbs를 만든 UTC 시각 · 예 20260323091013.000Z(연월일시분초.밀리초Z)
6	encr-mode	aea 또는 non-aea · 암호화·무결성 알고리즘
7	sigAlg	전자 서명 알고리즘 · sign.algo와 같은 값
8	hmac	"SHA-256"만 지원 · 대칭키 추출에 쓸 HMAC 해시
9	pkCert	메시지를 만든 쪽의 X.509 공개키 인증서
10	certPath(선택)	pkCert 검증에 필요한 하위 CA 인증서 목록 · 루트 CA가 pkCert에 직접 서명했으면 생략
11	attCert(선택)	사용자 권한과 역할을 확인하는 속성 인증서

보안 연관 수립, 데이터 전송, 해제의 메시지 순서. 출처: IEC 62351-4:2018+AMD1:2020.

서명은 X.509 공개키 인증서로 검증한다. 클라이언트와 서버는 핸드셰이크 메시지에 자기 인증서와 서명을 싣고, 상대는 그 인증서가 신뢰하는 인증 기관(CA)에서 발급된 것인지, 서명이 그 인증서의 공개키로 검증되는지를 확인한다. 이를 위해 양쪽은 최상위 인증 기관(루트 CA)의 인증서를 미리 가지고 있어야 한다. 루트 CA 아래에 하위 CA를 두는 계층 구조도 허용한다. 서명 알고리즘으로는 RSA와 타원곡선 서명(ECDSA)을 쓸 수 있다.

X.509 인증서는 상대가 주장하는 신원이 실제와 같은지 확인하는 수단이다. 예를 들어 MMS 연결을 맺을 때 상대 장치가 허가받은 장치인지를 확인한다. 인증 기관이 발급한 신분증에 비유되는 문서로, 한번 발급되면 유효 기간 동안 바뀌지 않으며, 보낸 쪽의 신원 정보와 공개키를 담는다. 이 공개키는 서명 검증용이며 세션 키를 만드는 dhPublicKey와는 다른 값이다. 최대 크기는 8,192옥텟이고 token1.pkCert로 전송한다. 인증서의 공개키 알고리즘은 세 가지 가운데 하나를 고른다. rsaEncryption은 전통적인 RSA 방식, ecPublicKey secp256r1은 미국 NIST P-256 곡선을 쓰는 타원곡선 방식, ecPublicKey brainpoolP256r1은 독일 연방정보보안청(BSI)이 정한 곡선을 쓰는 유럽 방식이다.

인증서 검증은 사슬을 따라 내려가며 한다. 루트 CA가 하위 CA1 인증서에 서명하고, 하위 CA1이 하위 CA2 인증서에 서명하고, 하위 CA2가 클라이언트의 인증서 서명 요청(CSR)에 서명해 pkCert를 만든 경우를 보자. 클라이언트는 pkCert와 함께 certPath[0]에 하위 CA1의 인증서를, certPath[1]에 하위 CA2의 인증서를 실어 보낸다. 서버는 ① 미리 가진 루트 CA 공개키로 하위 CA1 인증서의 서명을 검증하고, ② 검증된 하위 CA1의 공개키로 하위 CA2 인증서를 검증하고, ③ 검증된 하위 CA2의 공개키로 pkCert를 검증한 뒤, ④ pkCert에서 클라이언트의 공개키를 꺼내 핸드셰이크 메시지의 서명(sign.sign)을 검증한다. 루트 CA가 pkCert에 직접 서명한 경우에는 certPath를 구성하지 않아야 한다.

세션 키의 재료는 디피-헬만(DH, Diffie–Hellman) 키 합의로 만든다. 양쪽은 각자 난수로 개인키를 만들고, 그로부터 계산한 공개키만 상대에게 보낸다. 자기 개인키와 상대 공개키를 조합하면 양쪽이 같은 공유 비밀값을 얻는다. 개인키와 공유 비밀값은 통신망에 한 번도 나오지 않으므로 중간에서 메시지를 모두 엿본 사람도 공유 비밀값을 계산할 수 없다. 62351-4가 허용하는 DH 방식과 값의 길이는 아래와 같다.

DH 방식	개인키	공개키	공유 비밀값(IKM)
2048비트 MODP 그룹(그룹 14)	난수	256바이트	256바이트
NIST P-256 타원곡선	32바이트	64바이트	32바이트
brainpoolP256r1 타원곡선	32바이트	64바이트	32바이트

암호 모드에서 고를 수 있는 알고리즘은 두 계열이다. 인증 암호(AEA, Authenticated Encryption Algorithm)는 암호화와 무결성을 한 알고리즘으로 처리한다. 그렇지 않은 계열은 암호화 알고리즘과 무결성 알고리즘을 따로 고른다. ClearTransfer만 쓰는 연관은 무결성 알고리즘만 정하면 된다.

분류	알고리즘	기능
인증 암호(AEA)	aes128-GCM, aes256-GCM	암호화와 무결성을 함께
비AEA 암호화	aes128-CBC, aes256-CBC	암호화만
비AEA 무결성	hmacWithSHA256, aes128-GMAC, aes256-GMAC	무결성만

세션 키를 만드는 방법

DH로 얻은 공유 비밀값을 그대로 암호 키로 쓰지는 않는다. 값의 길이가 알고리즘이 요구하는 키 길이와 다르고, 한 값으로 여러 용도의 키를 만들어야 하기 때문이다. 62351-4는 RFC 5869가 정한 HKDF(HMAC-based Key Derivation Function)를 써서 공유 비밀값을 세션 키로 바꾼다. HKDF는 추출(extract)과 확장(expand) 두 단계로 이루어진다. 추출 단계는 salt라는 보조 값과 공유 비밀값(IKM, Input Keying Material)을 HMAC에 넣어 고른 분포의 의사난수 키(PRK)를 만든다. SHA-256을 쓰면 PRK는 32바이트다. 확장 단계는 PRK에서 필요한 길이만큼 키 재료를 늘려 뽑는다.

DH 공유 비밀값에서 방향별 세션 키를 뽑는 과정과, 알고리즘 조합별 키 분할의 예. 출처: RFC 5869, IEC 62351-4 13.3.1.3.

62351-4가 덧붙인 부분은 salt를 만드는 방법이다. salt는 핸드셰이크 요청과 수락 메시지의 서명 대상 부분(tbs)을 차례로 해시 연쇄에 넣어 만든다. 두 메시지는 양쪽이 모두 주고받은 것이므로 클라이언트와 서버는 같은 salt를 계산할 수 있고, 핸드셰이크 내용이 조금이라도 바뀌면 salt가 달라져 세션 키도 달라진다. 이 salt 생성 부분은 62351-4 고유의 절차라서 직접 구현해야 하고, 그 뒤의 HMAC·HKDF 계산은 OpenSSL 같은 공개 라이브러리 함수를 가져다 쓸 수 있다.

구체적인 식은 h_n = hash(data_n ‖ h_n−1), h₀ = 0이다. ‖는 바이트열을 이어 붙인다는 뜻이고, hash는 HandshakeReq의 token1.hmac에서 정한 해시 함수다. data₁은 HandshakeReq의 tbs 데이터, data₂는 HandshakeAcc의 tbs 데이터이며, 둘 다 ASN.1 인코딩의 시작 태그와 길이 필드를 뺀 내용만 쓴다. h₁ = hash(data₁ ‖ 0)이고, h₂ = hash(data₂ ‖ h₁)이 HKDF에 쓸 최종 salt_I다. 예를 들어 data₁이 0x12 34라면 h₁ = hash(0x12 34 00)이고, data₂가 0x56 78이고 h₁이 0xaa bb라면 h₂ = hash(0x56 78 aa bb)다. 키를 갱신할 때는 h₃ = hash(data₃ ‖ salt_I)를 새 salt_u로 쓴다. data₃은 rekey 필드를 담은 데이터 전송 요청 메시지의 tbp(to be protected) 데이터다.

추출 단계의 식은 PRK = HMAC-Hash(salt, IKM)이다. salt가 HMAC의 키 역할을 하고, IKM은 자기 개인키와 상대 공개키로 만든 값이다. DH에서 IKM = C^A mod p이며, A는 자기 개인키, C는 상대 공개키, p는 그룹의 소수다. PRK의 크기는 해시 함수에 따라 SHA-256이면 32바이트, SHA-384면 48바이트, SHA-512면 64바이트다. 확장 단계의 식은 OKM = HKDF-Expand(PRK, info, L)이다. info는 비워 두고(null), L은 필요한 모든 키의 길이 합이다. OKM(Output Keying Material)은 이렇게 뽑은 키 재료를 말한다.

확장 단계에서 뽑는 길이는 협상한 알고리즘에 따라 다르다. aes128-GCM 하나로 암호화와 무결성을 함께 처리하면 클라이언트용 16바이트와 서버용 16바이트, 합계 32바이트면 된다. aes128-CBC 암호화와 hmacWithSHA256 무결성을 따로 쓰면 클라이언트 무결성 키 32바이트, 서버 무결성 키 32바이트, 클라이언트 암호 키 16바이트, 서버 암호 키 16바이트를 합쳐 96바이트가 필요하다. 뽑은 키 재료를 정해진 순서대로 잘라 각 용도에 배정하는 것을 키 분할이라고 한다. aes128-GCM이면 OKM의 0~15바이트가 클라이언트 암호 키, 16~31바이트가 서버 암호 키다. aes128-CBC와 hmacWithSHA256 조합이면 0~31바이트가 클라이언트 무결성 키, 32~63바이트가 서버 무결성 키, 64~79바이트가 클라이언트 암호 키, 80~95바이트가 서버 암호 키다. 방향마다 다른 키를 쓰므로, 공격자가 한쪽 방향의 메시지를 반대 방향으로 되돌려 보내도 수신자의 검증은 실패한다.

재전송 방지와 키 갱신

데이터 전송 메시지(ClearTransfer, EncrTransfer)에는 토큰 2가 붙는다. 토큰 2에는 버전, 연관 식별자, 메시지를 만든 시각, 메시지 순번이 들어간다. 순번은 메시지를 보낼 때마다 하나씩 늘어난다. 수신자는 시각과 순번을 보고, 같은 값이 두 번 오거나 순서가 맞지 않으면 누군가 예전 메시지를 다시 보낸 재전송 공격으로 판단하고 DtSecAbort로 연관을 끊는다. 공격자가 정상 제어 명령을 녹화해 두었다가 나중에 다시 흘려보내는 공격을 막는 장치다.

데이터 전송 메시지의 SecPDU 필드 전체는 아래와 같다.

번호	필드	내용
1	version	V1(0) 고정값 · 1000 0000
2	assID	연관 식별자 · 예 "123:123"
3	time	tbs를 만든 시각 · 예 20260323091013.000Z
4	seq	메시지 순번 · 첫 메시지 0에서 시작해 1씩 증가
5	iv	초기화 벡터 · 같은 평문이라도 매번 다른 암호문이 나오게 하는 값 · ClearTransfer에는 없음 · AE는 12옥텟, 비AE의 AES-CBC는 16옥텟
6	rekey	새 공개키 · 클라이언트만 보낼 수 있음
7	reqRekey	새 대칭키 갱신 요청 시 참 · 서버만 보낼 수 있음
8	changedKey	새 대칭키 적용 완료 시 참 · 서버만 보낼 수 있음
9	applData	MMS 메시지 · 암호화 대상
auth	algo · nonce · icv	비AEA 방식에서만 구성 · 무결성 알고리즘, GMAC 알고리즘용 salt(한 번만 쓰는 수로 재전송 방지에 쓰임), tbp 전체에 대한 무결성 검증 값

실제 패킷으로 비교하면 차이가 분명하다. 리포트 제어 블록 예약(SetDataValues로 Resv를 참으로 쓰기) 요청을 ClearTransfer와 hmacWithSHA256으로 보내면 MMS 내용이 그대로 보이고 끝에 무결성 값만 붙는다. 패킷 분석기에서도 어느 논리 장치의 어느 리포트 제어 블록에 무엇을 쓰는지 읽힌다. 같은 요청을 EncrTransfer로 보내면, aes128-CBC와 hmacWithSHA256 조합이든 aes128-GCM이든 applData는 식별할 수 없는 바이트로만 보인다.

이 판정은 GOOSE 시험과 반대 방향이다. GOOSE에도 순번이 있지만, GOOSE는 스위치 부하로 프레임 하나가 빠지거나 순서가 바뀌는 상황에서도 구독자가 정상 동작해야 한다고 시험한다. 고속 보호 신호는 하나를 놓쳤다고 통신을 끊으면 더 큰 문제가 생기기 때문이다. 반면 62351-4의 데이터 전송은 보안 연관이므로 순번 이상을 곧바로 공격 신호로 보고 끊는다. 같은 순번이라는 필드가 어떤 메시지에 붙느냐에 따라 정반대의 판정 규칙을 가진다는 점을 구현자가 구별해야 한다.

세션 키는 오래 쓸수록 공격자가 분석할 수 있는 암호문이 많아진다. 그래서 62351-4는 연결을 끊지 않고 키를 바꾸는 갱신(rekey) 절차를 둔다. 엄격한 암호화 보장을 위해 15분에서 24시간 사이의 주기로 세션 키 묶음을 갱신하도록 권장한다. 갱신은 핸드셰이크에서 교환한 dhPublicKey로 만든 세션 키 묶음(암호화 키, 무결성 키 등)을 새로 만드는 절차다. 데이터 전송 중에 클라이언트가 먼저 rekey를 보낼 수도 있고, 서버가 갱신을 요청할 수도 있다. 서버가 갱신을 원하면 데이터 전송 메시지의 reqRekey 필드를 참으로 보낸다. 클라이언트는 새 DH 개인키·공개키를 만들고 새 공개키를 rekey 필드에 실어 보낸다. 서버는 새 키를 계산하는 동안 기존 키로 처리를 계속하다가, 준비가 끝나면 changedKey를 참으로 보낸다. 그 메시지 이후부터 양쪽이 새 세션 키를 쓴다. 서버는 기존 개인키와 클라이언트의 새 공개키로 새 암호화·무결성 키를 만든다.

연결을 유지한 채 세션 키를 바꾸는 절차. 출처: IEC 62351-4 13.3.2.

GOOSE와 SV는 왜 암호화하지 않는가

GOOSE의 순번 누락을 보안과 어떻게 연결해 보아야 하는지는 자주 나오는 질문이다. 답은 62351-4와 62351-6의 대상이 다르다는 데서 출발한다. 62351-4는 클라이언트·서버 사이의 MMS 통신만 다룬다. GOOSE와 SV는 TCP/IP를 거치지 않고 이더넷 프레임으로 여러 장치에 동시에 뿌려지는 메시지이며, 이들의 보안은 62351-6이 따로 정한다.

62351-6은 GOOSE와 SV를 암호화하지 않는다. 1편에서 보았듯이 트립 신호는 3ms 안에 도착해야 하고, 머징 유닛은 초당 수천 개의 샘플 프레임을 보낸다. 프레임마다 암호화와 복호화를 하면 그 지연과 연산 부담을 감당하기 어렵다. 그래서 62351-6은 프레임 끝에 메시지 인증 코드(MAC) 하나를 붙여, 프레임을 누가 보냈고 중간에 바뀌지 않았는지만 확인하게 한다. 여러 구독자가 같은 프레임을 검증해야 하므로 키는 그룹 키이고, 그 배포는 62351-9의 키 관리 방식을 따른다. 프레임 하나하나가 독립적으로 검증되므로 순서가 바뀌거나 하나가 빠져도 나머지 프레임의 검증에는 영향이 없다.

구분	MMS(62351-4)	GOOSE·SV(62351-6)
통신 방식	클라이언트·서버, TCP/IP 위	게시·구독, 이더넷 프레임 직접
암호화	선택(EncrTransfer)	하지 않음
무결성	메시지마다 ICV	프레임마다 MAC
키	연관마다 DH로 만든 세션 키	62351-9로 배포하는 그룹 키
순번 이상	연관 중단	프레임 단위 검증 · 순서와 무관

적합성 시험과 개발 환경의 현실

IEC 61850에 10부가 있듯이 62351에는 100번대 부가 있다. 62351-100-4는 4부의 적합성 시험 사양이며 2023년 11월 기술 사양(TS) 1판으로 나왔다. 이 사양은 시험 항목과 목적을 정하지만, 단계별 요청과 기대 응답을 적은 자세한 절차는 담지 않는다. 이 사양은 정상 절차 시험과 복원력(resiliency) 시험을 나눈다. 정상 절차 시험은 올바른 요청에 올바른 응답을 하는지를, 복원력 시험은 필수 파라미터를 빼거나 서명을 틀리게 한 요청을 받았을 때 올바른 거부 메시지로 대응하는지를 본다. 예를 들어 연결 요청에 반드시 있어야 할 프로토콜 이름 파라미터를 빼고 보냈을 때 서버가 정해진 부정 응답을 하는지를 확인한다.

UCAIug도 IEC 61850 서버 절차서와 같은 형식으로 62351-4 서버 시험 절차서(Conformance Test Procedures for IEC 61850-8-1 MMS Server Devices with IEC 62351-4 Edition 1 with Amendment 1 E2E security interface, 2025년 12월 판)를 만들었다. 62351-100-4가 정한 시험 블록에 따라 37개 시험 항목의 절차를 정한다. 62351-100-4는 시험 블록을 네 개로 정하고, 첫 블록을 인증 암호 사용 여부로 나누어 절차서에는 다섯 칸이 있다. 1a는 인증 암호(AE)를 쓰는 연관·해제·중단, 1b는 인증 암호를 쓰지 않는 연관·해제·중단, 2는 평문 데이터 전송(ClearTransfer), 3은 암호화 데이터 전송(EncrTransfer), 4는 키 갱신이다. 이 절차서는 37개 시험 항목으로 이루어지며, IEC 61850 서버 시험과 달리 모든 블록을 요구한다. 조건부 항목은 평문 전송과 암호화 전송에 각각 두 개씩만 있다.

블록	내용	필수 항목	조건부 항목
1a	연관·해제·중단(인증 암호 사용)	sHnd1~3, sHndN1~N6	없음
1b	연관·해제·중단(인증 암호 미사용)	sHnd1~3, sHndN1~N6	없음
2	평문 데이터 전송	sCdt1, sCdtN1·N2·N4·N5·N6	sCdt2, sCdtN3
3	암호화 데이터 전송	sEdt1·2, sEdtN1·N2·N4·N5·N6	sEdt3, sEdtN3
4	키 갱신	sRky1, sRky2	없음

시험 환경은 IEC 62351-4 기반 클라이언트 시뮬레이터, 이더넷 스위치, 통신 패킷 분석기(Wireshark), NTP 시각 동기용 시간 서버, 그리고 인증서 발급기로 이루어진다. 시험 대상 장치에는 그 장치의 ICT도 함께 준비한다. 인증서를 발급하는 인증 기관 역할이다. 공개키 인증서를 만들고 CA 역할을 대신하는 응용 프로그램이 필요하며, 서버 인증서와 루트 CA 인증서는 시험소가 제공한다. 시험소가 인증 기관을 운영해 시험 대상 장치와 시험 도구에 인증서를 발급해야 하고, 시각 비교를 위해 NTP 시간 서버도 필요하다. 패킷 분석기는 여전히 쓰지만 쓰임새가 바뀐다. EncrTransfer로 암호화된 MMS 메시지는 Wireshark에서 의미 없는 바이트로만 보이므로, 시험 도구가 자기 쪽 키로 복호화한 내용을 표준의 필드 이름 그대로 기록해 보여 주어야 한다.

대표 항목 세 개를 보면 시험의 성격이 드러난다. sHnd1(Associate and release a secure link)은 IEC 62351-4의 10, 12, 13, 14, 15절을 근거로, 공개키 인증서와 서명 알고리즘을 바꿔 가며 정상 연결과 해제가 되는지 확인한다. 클라이언트가 sha256WithRSAEncryption 서명으로 연결을 요청하고 해제한 뒤, 같은 과정을 secp256r1 곡선의 ecdsa-with-SHA256, brainpoolP256r1 곡선의 ecdsa-with-SHA256으로 반복한다. 장치는 연결 요청에 긍정 응답을 보내야 하고, 시험자는 세션·프레젠테이션 파라미터, ACSE 응답(AARE) 파라미터, EnvPDU(OSI-AssoRsp), HandshakeAcc의 SecPDU 파라미터가 표준 조항과 맞는지 확인한다. 해제 응답도 ACSE 해제 응답(RLRE), OSI-AssoRelRsp, ReleaseRsp 파라미터를 같은 방식으로 본다. 이 밖의 서명 알고리즘은 시험 범위가 아니다.

sHndN2(Associate and force server to send HandshakeSecReject)는 클라이언트의 HandshakeReq SecPDU 파라미터 값이 잘못되었을 때 서버가 HandshakeSecReject로 응답하는지 본다. 근거는 IEC 62351-4의 14.2.1, 14.3.3, 14.3.4절이며, TISSUE 94(진단 코드 altSig-mismatch(19)를 부속서 B에서 삭제)와 TISSUE 130(진단 코드 aea-algorithms-not-supported(15) 중복 오류)이 함께 적혀 있다. 장치는 연결 요청에 부정 응답을 보내고, 그 HandshakeSecReject의 진단 코드가 각 오류에 맞아야 한다.

클라이언트가 보낸 잘못된 요청	서버의 진단 코드
ClearToken1의 필수 구성 요소 누락	protocol-error(1)
지원하지 않는 보호 대상 프로토콜(HandshakeReq.pp)	protected-protocol-not-supported(2)
지원하지 않는 서명 알고리즘	invalid-signatureAlgorithm(3)
유효하지 않은 속성 인증서(attCert)	invalid-attribute-certificate(16)
폐기된 공개키 인증서(pkCert)	P_ABORT로 연결 중단

sEdtN6(ClearToken2 replay detected security event)은 IEC 62351-4의 14.4.3절 d)를 근거로 재전송 공격 대응을 본다. 클라이언트는 인증 암호를 쓰지 않는 방식(aes128-CBC와 hmacWithSHA256)으로 연결하고, 올바른 IEC 61850 요청을 EncrTransfer로 보낸 뒤, 시각(token2.time)과 순번(token2.seq)이 같은 EncrTransfer를 다시 보낸다. 장치는 처음 요청에는 정상 응답하고, 두 번째 요청을 받으면 연관을 중단하고 재전송 감지(replay-detected) 보안 이벤트를 일으켜야 한다.

62351-4를 적용한 서버를 개발할 때 붙여 볼 보안 클라이언트나 상용 분석 도구는 현재 세계적으로 상용화된 것이 없다. 일부 상용 스택이 62351-4 옵션을 판매하지만, 메시지 구조만 갖추고 표준이 요구하는 암호·무결성 알고리즘과 키 생성 절차는 구현되지 않은 경우가 있다. 그래서 서버 제조사는 스택의 구조를 이해한 뒤 공개 암호 라이브러리를 연결해 직접 구현하고, 시험소의 시험 도구에 붙여 보며 세부를 맞추는 방식으로 개발하고 있다.

인증 일정도 늦어졌다. UCAIug는 62351-4 시험 절차서를 공개한 뒤 시험소 심사와 인증 사업을 시작하려 했으나, 제조사들이 시험 도구가 없고 패킷이 보이지 않아 대응하기 어렵다며 TLS를 다루는 62351-3 시험부터 시작하자는 의견을 냈다. 그 결과 UCAIug는 62351-100-3 개정에 맞추어 62351-3과 62351-4 인증을 함께 시작하는 쪽으로 일정을 1년가량 미루었다. 유럽 규제가 보안 입증을 요구하는 시점과 시험 도구·인증 체계가 갖춰지는 시점 사이의 간격이, 지금 제조사가 62351-4 구현을 미루기 어려운 이유다.

결론 — 보안의 단위가 연결에서 메시지로 바뀌었다

IEC 62351-4는 IEC 61850의 MMS 메시지를 SecPDU로 싸고, 핸드셰이크에서 인증서로 상대를 확인하고 DH로 공유 비밀값을 만든 뒤, HKDF로 방향별 세션 키를 뽑아 메시지마다 무결성 값과 암호화를 적용한다. 데이터 전송 메시지의 시각과 순번은 재전송을 막고, 키 갱신 절차는 연결을 유지한 채 키를 주기적으로 바꾼다. GOOSE와 SV는 시간 제약 때문에 62351-6의 MAC으로 무결성만 지킨다. 이 구조의 요점은 중계 장치를 믿지 않는다는 데 있다. TLS가 연결 구간을 지킨다면, 62351-4는 게이트웨이나 프록시를 거쳐도 최종 수신자만 내용을 검증하고 풀 수 있게 한다.

구현 쪽 과제는 분명하다. 62351-4 고유의 salt 생성과 토큰 처리는 직접 만들어야 하고, 암호 알고리즘은 공개 라이브러리로 연결할 수 있으며, 암호화된 통신을 검증할 시험 도구는 아직 시험소 중심으로만 갖춰져 있다. 1편이 다룬 인증 체계와 2편이 다룬 2.1판 변경 위에 이 보안 계층이 더해지면, IEC 61850 제품의 적합성은 "표준대로 통신하는가"에서 "표준대로 통신하면서 그 통신을 위조할 수 없게 하는가"로 범위가 넓어진다.

IEC 61850 적합성 시험과 IEC 62351-4 보안: 인증 체계, 2.1판 변경 항목, 종단간 보안

1편. IEC 61850과 적합성 인증: 표준의 구성, 판의 교체, 시험 체계

표준 문서만으로는 상호운용성이 생기지 않는다

디지털 변전소의 세 단계와 국내 전환 현황

표준의 구성과 먼저 읽을 부(部)

1판, 2판, 2.1판, 그리고 연도 판

적합성 인증의 구조: 시험소, 인증 기관, 등록부

시험 블록을 고르는 방법과 시험 절차서 읽기

변전소 밖의 설비: 분산전원과 인버터

결론 — 표준의 상호운용성은 인증 체계가 만든다