제로 트러스트 - 시스템에서 하드웨어로

보안에서 제로 트러스트는 다양한 도구와 연계되는 AI, 에이전틱 서비스에서 더 많은 관심을 받고 있는데요, 다만 이 원칙을 따라 내려가다 보면 장치의 경계에서 멈춥니다. 로봇 셀 경계에는 방화벽과 인증서가 있고 티치펜던트에는 로그인이 있어도, 제어기에서 관절로 가는 지령 하나하나에는 아직 "같은 버스에 있으니 믿는다"는 전제가 적용될 수 있습니다. 단위 자체가 '제어기'이기 때문인데, 사실 그 안에도 이제는 복잡한 구성이 많아서 단일 하드웨어라고 부르기 애매해진 것 같아요. TEE와 PCC 소식이 하드웨어 격리 위에 시스템을 쌓는 이야기였다면, 이번에는 반대로 제로 트러스트를 로봇의 관절까지 끌어내리면 무엇이 달라지는지 정리해 보았습니다. 예로 든 것은 컨베이어로 들어오는 부품을 비전으로 인식해 집어 트레이에 놓는 pick-and-place 로봇 셀입니다.

제로 트러스트가 멈추는 곳

ZTA의 기준 문서인 NIST SP 800-207은 원칙상 IoT 액추에이터까지 자원으로 보는데요, CISA의 성숙도 모델, 미 국방부의 OT 제로 트러스트 지침, KISA의 OT 제로트러스트 안내서는 모두 장치 내부 부품 사이의 신원, 인가, 집행까지는 구체적으로 다루지 않습니다. 칩 수준 보안 연구 45건 가운데 제로 트러스트 원칙을 모두 충족한 사례가 없었다는 최근 문헌도 있구요.

로봇 안으로 들어가면 이 상황이 더 구체적으로 보입니다. 협동로봇과 서보 시스템에 널리 쓰이는 EtherCAT의 일반 프레임은 CRC로만 보호되는데, CRC는 우발적인 비트 오류를 잡을 뿐 누군가 의도적으로 만든 프레임은 걸러 내지 못하죠.

이미 있는 하드웨어 구성 기술

그럼 아예 새로 만들어야 할까요? 한 기계 안에서 부품끼리 서로를 검증하는 기술은 다른 분야에서 이미 쓰이고 있습니다. 이름이 '제로 트러스트'가 아닐 뿐이구요.

• 차량 내부망: AUTOSAR SecOC, MACsec, 게이트웨이 ECU를 통한 메시지 인증과 망 분리
• 서버와 칩: DMTF SPDM, TCG DICE, OCP Caliptra를 통한 부품 신원과 펌웨어 상태 증명
• 서보 드라이브: Siemens, Rockwell, B&R 제품의 드라이브 단위 신원과 채널 보호
• 필드버스: EtherCAT 대칭키 페어링, ETG.1800 보안 프로파일 초안(2026년 9월), CANsec의 표준화 진행

그래서 로봇 내부 제로 트러스트는 새 보안 기술을 만드는 일이라기보다, ZTA의 정책 결정 지점(PDP), 정책 집행 지점(PEP), 정책 정보 지점(PIP)을 하나의 복합 장치인 로봇 안에 다시 배치하는 일에 가깝다고 생각합니다. 필드 수준에서는 하드웨어 강제 규칙으로 충분하다는 EtherCAT 진영의 반론도 있어서, 핵심 명령부터 선택적으로 적용하는 단계적 접근이 현실적일 것 같아요.

IT의 제로 트러스트와 다른 점

같은 원칙이라도 로봇 안으로 들어오면 단어의 뜻이 바뀌는데요.

• 접근의 의미: 읽기, 쓰기, 실행이 아닌 동작 여부, 동작 범위(위치, 속도, 힘), 동작 시점
• 판단 주기: 세션 단위가 아닌 작업 단위(분)와 제어 주기 단위(ms 이하)의 이원화
• 거부 시 결과: 요청 실패가 아닌 감속, 보호정지 같은 안전 상태 전이
• 신원: 계정과 인증서가 아닌 부품 고유 신원, 장착 위치(축), 펌웨어 측정값
• 가용성: 생산 중단과 안전 문제로 직결되어 외부 PDP에 의존하기 어려움

가장 크게 달라지는 건 '접근'이 데이터가 아니라 물리 동작이 된다는 점, 그리고 거부했을 때의 결과입니다. IT에서는 요청을 거부하면 에러 화면으로 끝나지만, 로봇이 지령을 거부해 급정지하면 들고 있던 공작물이 날아가거나 중력축이 떨어질 수 있거든요.

지령 하나마다 확인할 것

그렇다면 관절은 지령을 받을 때 무엇을 확인해야 할까요? 다음 여섯 가지 정도로 나눠 볼 수 있을 것 같습니다.

• 출처 진정성: 세션 키 기반 MAC으로 등록된 제어기의 지령인지 확인
• 신선도: 카운터나 타임스탬프로 재전송, 지연 지령 차단
• 송신자 상태: 측정 부팅과 DICE, SPDM 증명으로 제어기 펌웨어와 설정 확인
• 권한: PDP가 발급한 권한 증표로 이 주체가 이 축에 이 동작을 요청할 수 있는지 확인
• 물리적 범위: 축별 위치, 속도, 토크 범위와 지령값 비교
• 안전 맥락: 운전 모드, 인에이블 장치, 안전 제어기 상태 확인

물리적 범위를 따로 두는 이유는 인증만으로 막기 어려운 공격이 이미 보고되어 있기 때문인데요. SROS2 키스토어를 탈취하면 정상 참여자로 인증된 채 제어 명령을 주입할 수 있고, 산업용 로봇 제어기에서 1축 PID 이득만 바꿔 2mm 미만의 궤적 오차를 만든 연구도 있습니다. 인증은 "누가 보냈는가"에 답할 뿐 "보낸 내용이 말이 되는가"에는 답하지 않으니까요. 그래서 관절이 권한 증표의 범위와 지령값을 직접 비교하고, 지령과 상태 응답 양쪽을 모두 인증하는 쪽이 바람직해 보입니다.

같은 모양의 관절 여섯 개

6축 로봇에는 같은 기종의 드라이브가 여러 개 들어가는 경우가 많은데요, 지금의 버스 수준 식별자는 평문이라 복제가 쉽고 같은 기종끼리 케이블이 바뀌어도 알아채기 어렵습니다. 그래서 "진품인가", "펌웨어가 정상인가", "정말 J3 자리에 있는가"라는 세 질문을 따로 다룰 필요가 있어 보입니다.

• 개체 신원: 제조 시 부품 제조사가 발급하는 IDevID, DICE DeviceID로 진품 여부 확인
• 상태 신원: 부팅마다 부품이 스스로 유도하는 DICE Alias 인증서와 SPDM 측정값으로 펌웨어 확인
• 역할 신원: 설치나 교체 때 통합업체나 소유자가 발급하는 LDevID로 정책의 대상 이름(R01/J3) 부여

정책은 "J3에 MOVE를 허용한다"처럼 역할로 쓰기 때문에, 관절을 교체해도 새 부품에 역할 신원만 다시 발급하면 정책을 고칠 필요가 없겠죠. 로봇 전체의 증명은 IETF RATS의 복합 장치 모델처럼 제어기가 관절, 그리퍼, 카메라의 증거를 모아 기준값과 대조하는 구조로 묶어 볼 수 있을 것 같습니다.

판단은 위에서, 집행은 아래에서

관절 MCU가 1 kHz 제어 주기마다 정책 전체를 평가하기는 어렵다 보니, 판단과 집행을 두 단계로 나누는 구조를 생각해 볼 수 있습니다.

• 느린 경로(작업, 이벤트 단위): 작업 시작, 모드 전환, 정비 진입 때 제어기 보안 영역의 PDP가 정책을 평가하고 관절마다 서명된 권한 증표 발급
• 빠른 경로(제어 주기 단위): 관절의 PEP가 지령마다 MAC, 신선도, 증표 범위만 비교

공개된 명령 단위 MAC 연구 가운데에는 처리에 평균 7.9 ms가 걸려 1 kHz 제어 주기에 맞지 않는 결과도 있어서, 하드웨어 암호 가속기를 전제로 한 실측이 필요해 보이구요. 정책도 제조사, 통합업체, 소유자, 작업(MES)의 네 층위로 나누고 실제 허용 권한은 네 층위의 교집합으로 정하는 방안을 고려해 볼 수 있을 것 같아요.

보안은 좁히기만 한다

로봇에서 가장 조심해야 할 부분은 안전 기능과의 관계인데요, 원칙은 '보안 계층은 동작 범위를 좁힐 수만 있고 넓힐 수는 없다'로 간단히 정리해 볼 수 있습니다.

• 안전 기능의 독립 유지: STO, SS1, SLS와 안전 설정은 보안 정책과 분리하고 기능안전 인증 범위 유지
• 정지 방식의 단계화: 위반 프레임 하나에 곧바로 STO를 걸지 않고 이전 유효 지령 유지, 감속, SS1 순으로 단계 정의
• 통신 두절의 설계 조건 반영: 연결이 끊기면 새 권한 없이 이미 발급된 증표의 범위와 유효 시간 안에서만 움직이고, 만료되면 사이클 종료 위치에서 정지

PDP가 있는 제어기 자체가 장악되는 경우라면 어떨까요? PDP를 TEE나 별도 보안 MCU에 두고, 통합업체가 서명한 상한을 관절에 직접 저장해 두는 방안이 있습니다. 그러면 한 지점이 뚫려도 상위 층위의 한계와 안전 한계는 유지되겠죠.

아직 비어 있는 곳

현재 보호 단위는 제어기와 드라이브 장치에 머물러 있고, 그 사이를 오가는 지령 하나하나가 허용된 것인지 따지는 계층, 축 단위와 동작 단위 인가, 실행 중 재증명은 공개 구현을 찾기 어렵습니다. 그래도 표준과 규제는 움직이고 있는데요. EtherCAT 보안 프로파일(ETG.1800) 초안이 2026년 9월에 나왔고, EU 기계규정이 2027년 1월, 사이버 복원력법(CRA)이 2027년 12월부터 적용되며, ISO 10218-1:2025에도 로봇 안전에 영향을 주는 범위의 사이버보안 요구가 들어갔습니다.

제로 트러스트의 원칙은 그대로이고, 적용 단위만 사용자에서 장치로, 장치에서 부품으로, 요청에서 지령 하나로 내려가는 것 같아요. 물리보안이나 Physical AI 쪽에서도 이 관점이 유효할 수 있을 것 같구요. 시스템에서 시작한 제로 트러스트가 하드웨어 안쪽까지 내려가려면 보안과 안전, 실시간 제어를 함께 고려해 보는 것도 의미가 있을 듯 합니다.

---

센터의 관련 연구는 과제 페이지에 정리되어 있습니다.