노드 인증(Authentication) 기초
인증의 개념
ROS2에서 노드는 분산 시스템 환경에서 여러 데이터 흐름을 송수신한다. 이때, 통신 채널의 암호화(Encryption)만으로는 상대 노드가 신뢰할 수 있는 노드인지 보장하기 어렵다. 따라서 누가 누구에게 데이터를 전송하고 있는지에 대한 ‘신원 증명(Identity Proof)’이 필요하다. 이를 통해 노드는 서로를 식별할 수 있으며, 권한 부여(Authorization) 등 추가적인 보안 기법과 연동될 수 있다.
DDS Security와 인증
ROS2는 하위 계층에서 DDS(Data Distribution Service)를 사용한다. DDS Security는 표준으로서 다음과 같은 보안 플러그인을 정의한다.
인증 플러그인(Authentication Plugin)
암호화 플러그인(Cryptographic Plugin)
접근 제어 플러그인(Access Control Plugin)
이 중 인증 플러그인은 노드 또는 참여자(Participant)의 신원을 확인하기 위한 역할을 담당한다. DDS 보안 스펙은 공개 키(Public Key) 인프라(PKI)에 기반한 인증 과정을 제시하며, X.509 인증서 구조를 이용해 상호 인증(Mutual Authentication)을 수행한다.
인증서 기반 구조
ROS2 노드는 PKI를 통해 배포된 인증서(예: X.509 형식)를 활용해 자신의 정당성을 증명한다. PKI에서 각 엔티티(Node 혹은 Participant)마다 ‘개인 키(Private Key)’와 ‘공개 키(Public Key)’가 존재하며, 인증 기관(CA)에서 발행한 인증서에는 ‘인증받은 공개 키’와 함께 ‘해시(Hash) 알고리즘’, ‘서명(Signature)’, ‘만료 시간(Validity)’ 등의 정보가 포함되어 있다.
개인 키(Private Key): 노드가 절대 외부에 노출하면 안 되는 비밀 키.
공개 키(Public Key): 상대방에 의해 확인될 수 있는 키. 인증서로 배포된다.
루트 CA(Root CA): 전체 PKI 체계에서 신뢰의 최상위에 위치하는 인증 기관.
노드 인증 절차
ROS2에서 노드 인증은 보안 설정이 활성화된 DDS 파티션 간 통신 시 아래와 유사한 단계를 거친다.
인증서 교환: 통신하려는 상대 노드와 인증서(공개 키)가 교환된다.
서명 검증: 상대 노드가 전송해 준 인증서의 서명이 유효한지 확인한다. 이를 위해 CA의 공개 키가 사용된다.
상호 인증(Mutual Authentication): 노드가 서로의 인증서를 확인해 “서로 신뢰할 수 있다”는 사실을 증명한다.
세션 키 교환(Session Key Exchange): 상호 인증이 완료되면 노드는 이후 통신에 사용할 대칭키(Symmetric Key)를 생성하거나 교환하여 암호화 채널을 수립한다.
수학적으로 서명 검증(Signature Verification)은 다음과 같은 과정을 거친다. 노드 A가 노드 B의 인증서를 수신했을 때, 인증서에 담긴 공개 키 $K_{B}^{\text{pub}}$와 CA의 공개 키 $K_{\text{CA}}^{\text{pub}}$로 B의 서명 $\sigma_B$를 검증한다:
여기서 $\text{message}$는 인증서의 핵심 정보(예: 공개 키, 발행자, 시리얼 번호 등)를 포함하며, $\sigma_B$는 노드 B가 자신의 개인 키로 서명한 값이다.
ROS2 보안 아키텍처에서의 노드 인증
ROS2에서는 “보안 엔클레이브(Security Enclave)”라는 개념으로 노드를 그룹화하거나, 동일한 인증서를 공유하도록 설정할 수 있다. 즉, 하나의 프로세스에 여러 노드가 있을 경우 하나의 파티션(혹은 참여자)이 ‘보안 엔클레이브’를 구성하기도 한다. 이때 각 엔클레이브는 다음과 같은 자원을 가진다:
Key Store: 노드별(private key, public key, 인증서)나 엔클레이브 단위 인증서 저장소.
Permission File(권한 파일): 어떤 노드가 어느 토픽(Topic)에 Publish/Subscribe 권한이 있는지를 정의.
Identity Certificate: 노드 또는 참여자 단위로 발급받은 X.509 인증서.
sros2를 이용한 노드 인증
ROS2 Humble 버전에서는 sros2 패키지를 통해 인증서를 생성, 관리할 수 있다. 예시로, 다음과 같이 인증서, 키 파일 등을 준비한다:
이 과정을 통해 /robot_camera 노드의 인증서를 발행하고, 필요한 키를 “my_robot_ca”라는 키 스토어에 저장할 수 있다.
노드 이름과 인증
ROS2 인증 구조에서는 노드 이름(Namespace 포함)이 중요한 식별자(identifier)가 된다. 예를 들어 /robot_camera라는 노드는 인증서에도 해당 이름이 주어진다. DDS 통신 계층은 특정 노드 이름으로 연결 시도 시, 해당 이름에 대한 인증서 유효성을 확인한다.
공격 벡터와 대처
노드 인증 부재 시, 악의적 노드(Malicious Node)가 임의로 이름을 스푸핑(spoofing)하여 시스템 내부에 침투할 가능성이 있다. 예를 들어, /gps_sensor 노드를 가장하여 잘못된 좌표를 퍼블리시할 수 있다. 따라서 노드 인증이 제대로 설정되어야만 다음과 같은 공격 벡터를 줄일 수 있다.
위장 공격(Impersionation Attack)
중간자 공격(Man-In-The-Middle Attack)
권한 탈취(Privilege Escalation)
인증서 라이프사이클 관리
ROS2 노드에서 사용하는 인증서는 유효 기간(Validity Period)이 존재한다. 유효 기간이 만료되면 해당 인증서를 더 이상 사용할 수 없으므로, 노드의 통신이 불가능해질 수 있다. 따라서 운영 중에는 인증서의 라이프사이클을 고려해야 한다.
발급(Issue): CA(인증 기관)에서 노드마다 인증서를 발급한다.
갱신(Renewal): 만료 전 일정 기간이 다가오면 새로운 인증서를 발급받는다.
폐기(Revocation): 보안 침해가 의심되거나 인증서가 노출된 경우, CA는 인증서를 폐기(리보크, Revoke) 처리한다.
CRL과 OCSP
폐기된 인증서를 확인하기 위한 방법으로 **CRL(Certificate Revocation List)**과 **OCSP(Online Certificate Status Protocol)**가 있다.
CRL: 일정 주기로 CA가 인증서 폐기 목록을 발행하고, 이를 다운받아 확인한다.
OCSP: 실시간으로 특정 인증서가 폐기되었는지 여부를 CA 서버에게 질의한다.
ROS2 환경에서는 대규모 분산 노드 환경을 구축할 수 있으므로, CRL 또는 OCSP 같은 프로토콜을 체계적으로 관리해야 한다. 다만, 실제 ROS2 배포판에서 CRL/OCSP를 직접 구현하기보다는, DDS Security 레이어(미들웨어)에서 이를 지원하거나, 시스템 환경(IT 인프라)에서 인증서 정책을 적용해 운용한다.
Hardware Security Module(HSM)
민감한 키를 소프트웨어 레벨에서만 보관하면, 시스템 해킹으로 인해 개인 키가 탈취될 가능성이 높아진다. 이를 방지하기 위해 HSM(Hardware Security Module), 또는 신뢰 실행 환경(TEE, Trusted Execution Environment)을 활용하는 방안이 있다.
HSM: 물리적인 보안 하드웨어 장치로, 암호 연산과 키 관리를 안전하게 수행한다.
TPM(Trusted Platform Module): 주로 PC나 임베디드 보드에 탑재된 보안 칩으로, 키와 인증서 저장, 무결성 검증 등을 수행한다.
ROS2 노드를 운용하는 환경에 따라 HSM이나 TPM을 통해 인증서를 안전하게 관리할 수 있다.
다중 노드 환경에서의 인증 전략
ROS2를 이용해 여러 로봇, 센서, 클라우드 노드가 동시에 통신하는 시나리오에서는 인증 체계가 더욱 중요해진다. 예를 들어, 아래 그림(mermaid로 간단히 표현)에서 CA(인증 기관)와 여러 노드가 연결되어 있다.
루트 CA(Root CA)에서 인증서 일괄 발급
모든 노드는 CA로부터 인증서를 발급받아야 한다.
상호 인증
Node1과 Node2가 DDS 통신을 개시할 때 서로의 인증서를 교환 및 검증한다.
세션 키 교환
상호 인증이 완료되면, 세션 키를 생성하고 교환하여 암호화 채널을 형성한다.
주기적 재인증
네트워크나 시스템 정책에 따라, 일정 시간마다 재인증 과정을 수행하거나 세션 키를 갱신(Rotation)한다.
인증 정책 설계 시 고려사항
네임스페이스 및 노드 명명 규칙
인증서에는 노드 이름이 식별자로 포함되므로, 일관된 네임스페이스와 노드 이름 정책이 필요하다.
서버/클라이언트 구조에서의 인증
특정 노드는 서비스(예: 제어 명령)을 제공하고, 다른 노드는 서비스를 호출(클라이언트 역할)할 수 있다. 이때 양방향 인증이 적합한지, 단방향 인증으로 충분한지 결정해야 한다.
분산 노드에서의 키 관리
로봇과 센서가 물리적으로 분산된 환경이라면, 중앙 서버(CA)와의 연결이 원활하지 않을 수 있다. 이럴 때 인증서 재발급, 폐기(Revocation) 관리를 어떻게 할지 사전에 결정해야 한다.
퍼포먼스 영향
암호화 연산(서명·검증·대칭키 교환 등)이 노드 CPU, 메모리, 네트워크 부하에 미치는 영향을 점검한다.
DDS 보안 인증 핸드셰이크(Handshake) 개요
ROS2 DDS 보안 레이어에서 노드 간 통신은 ‘핸드셰이크(Handshake)’ 과정을 통해 상호 인증을 수행한다. 이 과정은 DDS Security 표준의 Authentication Plugin에 의해 관리되며, 보통 아래와 같은 단계로 요약할 수 있다.
Request/Challenge 교환
통신 당사자끼리 인증 요청 메시지와 난수(Nonce), 타임스탬프 등을 교환한다.
인증서 검증
상대 노드가 보낸 인증서(X.509)를 검증하고, 상대방의 신원이 유효한지 확인한다.
서명 검증
상대방이 전송한 특정 데이터(Challenge)를 본인의 개인 키로 서명하고, 이를 다시 검증한다.
세션 생성
상호 인증이 완료되면, 임시 세션 키를 합의하고 이후 통신을 암호화한다.
DDS 보안 인증 핸드셰이크의 내부 구조
DDS 보안 표준 문서에 따르면, 핸드셰이크 과정은 아래와 같이 요청(Request)과 응답(Reply)을 교차하며 진행된다.
AuthenticationRequest: Node A가 자신의 인증서(또는 인증서 체인), 난수(A_nonce), 세부 옵션을 전송한다.
AuthenticationReply: Node B가 A의 인증서를 검증한 뒤, 본인의 인증서와 B_nonce를 포함해 응답한다.
FinalMessage: A는 B가 보낸 인증서를 확인하고, B가 보낸 B_nonce에 대한 서명을 포함한다. 여기서 대칭키 혹은 세션 키를 유도할 수 있는 파라미터도 전송한다.
FinalAck: B에서 A의 서명을 최종 검증하고, 세션을 공식적으로 성립시킨다.
노드 인증 실패 시 동작
인증 과정 중 어느 한쪽에서라도 검증 실패가 발생하면, DDS Security 플러그인은 해당 연결을 거부한다. 이 경우, ROS2 레이어에서는 서로 구독(Subscribe) 혹은 발행(Publish)할 수 없으며, 보안 정책에 따라 추가 로깅(logging)이나 알림(notification)을 수행할 수 있다.
인증서 불일치: 예: 노드 이름과 인증서에 명시된 이름이 다를 경우.
서명 불일치: 예: 전송된 메시지에 대한 서명이 일치하지 않는 경우.
신뢰할 수 없는 CA: 예: 루트 CA가 신뢰 목록에 등록되지 않은 경우.
sros2 설정 파일 구조
ROS2에서 sros2 패키지를 사용할 때, 보안 설정 디렉토리는 보통 다음과 같은 구조를 가진다.
ca.cert.pem / ca.key.pem: 최상위 인증 기관의 인증서와 개인 키.
거버넌스(governance) 파일: 전체 DDS 도메인에 걸쳐 적용되는 보안 정책(예: 암호화 방법, 인증 요구 여부, 로깅 정책 등)을 정의.
permissions 파일: 노드별로 토픽별 접근 권한(Publish/Subscribe)을 설정한다.
노드 디렉토리: 노드별 인증서(cert.pem), 개인 키(key.pem), 해당 노드 권한 정의 파일(permissions.xml) 등이 저장된다.
인증서 요청(CSR) 생성과 CA 서명
노드 측에서 본인의 공개 키에 대한 인증서를 발급받으려면, 먼저 CSR(Certificate Signing Request)을 생성한다. CSR에는 다음 정보가 포함된다.
공개 키 (Public Key)
조직명, 노드명, Common Name(CN) 등 식별 정보
서명 알고리즘, 해시 알고리즘
생성된 CSR을 CA에 제출하면, CA는 요청된 공개 키에 서명해 인증서를 발급한다.
이후 CA에서 다음 명령 등을 통해 node.csr.pem에 서명할 수 있다.
이렇게 발급된 node.cert.pem을 ROS2 노드에 배포하여, DDS Security 핸드셰이크에서 활용하게 된다.
암호 알고리즘 선택
ROS2 DDS 보안에서 노드 인증에 사용되는 주요 암호 알고리즘은 RSA, ECDSA 등으로 나뉘며, 각각 장단점이 있다.
RSA (Rivest–Shamir–Adleman):
장점: 보편적으로 쓰이며, 구현체와 지원 도구가 풍부하다.
단점: 키 길이가 길어질수록 연산 속도가 낮아질 수 있다.
ECDSA (Elliptic Curve Digital Signature Algorithm):
장점: 더 짧은 키 길이로도 높은 보안 강도를 확보할 수 있어 임베디드 환경에 적합하다.
단점: 구현 난이도가 비교적 높고, 일부 환경에서 호환성이 떨어질 수 있다.
노드 인증의 보안 수준은 사용할 키 길이(예: 2048비트, 4096비트 등)와 암호 알고리즘의 종류에 따라 달라진다. H/W 리소스가 제한된 임베디드 기기에서는 ECDSA 같은 타원 곡선 기반 방식을 많이 고려하게 된다.
Ephemeral Key(임시 키) 교환
서명과 인증서 검증 외에, 통신 과정에서 대칭 암호에 사용하는 “임시 세션 키(Ephemeral Key)”를 생성하고 교환하는 과정이 수행된다. 이를 통해 오랫동안 같은 키를 사용하지 않고, 일정 주기로 키를 갱신함으로써 **전방향 보안(Forward Secrecy)**을 강화할 수 있다.
Diffie-Hellman(DH) 또는 ECDH
Diffie-Hellman (DH):
전통적인 공개 키 교환 프로토콜.
$g^a \mod p$, $g^b \mod p$ 등으로 계산하여 공유 키를 생성한다.
Elliptic Curve Diffie-Hellman (ECDH):
타원 곡선을 기반으로 한 DH 알고리즘.
키 길이가 짧으면서 보안 강도는 높아, ROS2 임베디드 환경에 이점이 있다.
DDS Security에서 상호 인증이 완료된 후, 내부적으로 DH 또는 ECDH 매커니즘이 수행되어 세션 키가 합의된다. 그 결과, 노드 간 송수신되는 데이터는 대칭 암호로 암호화된다.
노드 스위트(Suite)
노드 인증과 관련하여 DDS Security에서는 특정 암호 스위트(Suite)의 사용 여부를 정의할 수 있다. 예를 들어 다음과 같이 구성 가능하다.
인증 알고리즘: RSA-2048, ECDSA-P256 등
해시 함수: SHA-256, SHA-512 등
키 교환 알고리즘: Diffie-Hellman, ECDH 등
대칭 키 알고리즘: AES-256-GCM 등
거버넌스(governance) 파일이나 보안 정책 파일에서 사용하려는 알고리즘 세트(crypto suite)를 지정하면, 인증 과정부터 데이터 암호화까지 해당 알고리즘이 사용된다.
대규모 로봇 시스템에서의 인증 설계
한두 대 로봇의 경우 CA가 간단한 스크립트 형태여도 크게 문제되지 않지만, 로봇 수가 수십~수백 대에 달하면 다음과 같은 확장이 필요하다.
중간 CA(Intermediate CA) 운영
루트 CA(Root CA)의 서명키를 직접 노출시키지 않기 위해, 중간 CA를 두고 실제 인증서 발행 업무를 중간 CA가 맡는다.
자동 인증서 발급(Automated Provisioning)
노드(로봇)가 처음 전력 인가될 때, CA 서버로부터 CSR을 전송하여 자동으로 인증서를 발급받는 절차를 갖춘다.
PKI 정책 문서화
조직 내 PKI 운영 절차(인증서 발급, 만료, 폐기, 갱신 등)를 문서화하고, 담당자가 일관성 있게 수행할 수 있도록 설계한다.
멀티 로봇 시스템에서 노드 식별
ROS2 환경에서 로봇 간 협업을 위해 멀티 로봇 시스템이 구성되면, 각 로봇은 고유한 노드 이름 체계를 가져야 한다. 예시로,
/robot1/camera_node/robot2/camera_node/robotN/lidar_node
각 노드 이름에 맞춰 인증서가 생성되고, 노드 간 통신 시 인증서 이름이 일치해야만 DDS Security가 통신을 허용한다.
권장 키 저장 방법
소프트웨어 단에서 *.key.pem 파일 형태로 키를 저장하는 것은 관리가 간단하지만, 보안 취약점이 있을 수 있다. 따라서 다음 방법들을 고려할 수 있다.
암호화 파일 시스템
키 파일이 위치한 디렉토리를 OS 레벨 암호화(예: Linux dm-crypt)로 보호한다.
HSM/TPM 연동
개인 키 연산(서명, 복호화 등)을 장치 외부로 유출하지 않고 HSM 내부에서만 수행하게 하여 보안을 강화한다.
전용 키 관리 서비스
클라우드 환경(예: AWS KMS, Azure Key Vault 등)과 연동하거나, 사내 키 관리 서버를 두고 로봇이 안전 채널로 키 연산을 호출한다.
테스트 및 검증
노드 인증 체계가 제대로 동작하는지 여부는 통신 테스트, 위협 모델 테스트를 통해 검증한다. 예를 들어,
인증 실패 상황 시뮬레이션
인증서가 만료된 노드, 이름 불일치 노드 등을 실행해, 정상 노드와 통신이 차단되는지 확인한다.
부하 테스트(Stress Test)
한꺼번에 여러 노드가 동시에 인증을 시도할 때 성능이 저하되지 않는지 측정한다.
침투 테스트(Penetration Test)
악의적 노드가 잘못된 인증서나 스푸핑된 이름으로 접근할 때, DDS Security가 차단하는지 확인한다.
오프라인 환경에서의 인증
일부 로봇 시스템은 인터넷 연결이 없거나 제한된 ‘오프라인(Offline)’ 환경에서 동작한다. 이때 노드 인증과 PKI를 유지하려면 다음과 같은 고려 사항이 필요하다.
오프라인 CA 운영
루트 CA(또는 중간 CA)를 오프라인 상태로 두고, 필요 시에만 물리적 매체(USB 등)를 통해 인증서 발급/갱신을 수행한다.
CRL(인증서 폐기 목록) 오프라인 배포
주기적으로 오프라인 CA가 폐기 목록(CRL)을 생성하여, 로봇 시스템 내부로 전달한다.
긴 만료 기간 설정
빈번한 인증서 갱신이 어려우므로, 인증서 유효 기간을 상대적으로 길게 설정할 수 있다(단, 보안 위험이 늘어남).
로봇 플랫폼별 사례
ROS2 Humble 버전으로 구성된 다양한 로봇 플랫폼(예: 로봇 팔, 자율주행 모바일 로봇, 드론)에서 노드 인증을 적용하는 방법은 공통적이지만, 하드웨어 리소스와 네트워크 토폴로지에 따라 차이가 있다.
자율주행 로봇(AGV, AMR)
실내에서 여러 로봇이 협동 작업을 수행할 때, 각 로봇이 /map, /odom, /cmd_vel 등 핵심 토픽들을 발행/구독한다.
인증이 없으면 임의 노드가 /cmd_vel를 퍼블리시해서 시스템을 혼란에 빠뜨릴 수 있다.
드론
제한된 크기, 무게 때문에 CPU/메모리가 작을 수 있으므로 ECDSA 또는 ECDH 방식으로 자원 소모를 줄이는 것이 권장된다.
무선 네트워크 환경에서 인증 실패 시 재전송이나 재핸드셰이크 오버헤드도 고려한다.
정적 로봇(고정식 산업 로봇, 로봇 팔 등)
상대적으로 전력, 네트워크 인프라가 안정적이므로 RSA 같은 안정적인 알고리즘을 사용하기 쉽다.
외부에서 데이터 캡처/명령 Injection을 막기 위해 파이어월, IDS(침입 탐지 시스템) 등과 결합할 수 있다.
노드 식별과 네임스페이스
ROS2에서는 노드 이름과 네임스페이스(namespace)가 논리적으로 시스템을 분할하는 데 중요하다. 예:
/robot1/vision/camera_front/robot2/vision/camera_front
인증서 발행 시, 인증서의 “Subject Alternative Name(SAN)” 항목 등에 위 노드 이름을 명시하여 특정 노드만이 이 인증서를 사용할 수 있도록 설정할 수 있다. DDS Security 핸드셰이크 과정에서 노드 이름과 인증서 정보가 상호 검증되어야 한다.
발전 방향
동적 재협상:
ROS2 DDS 통신에서는 연결된 상태에서 세션 키를 주기적으로 재협상하는 기능을 제공할 수 있다(드라이버·미들웨어 구현에 따라 달라짐).
정책 기반 접근 제어와 연동:
노드 인증 이후, 특정 권한이 있는 노드만 특정 토픽에 접근할 수 있도록 동적으로 조정할 수 있다.
서드파티 인증 기관 연동:
기업 내부에서 이미 사용 중인 PKI가 있으면, 이를 ROS2 DDS에 연동하여 인증서 발급/폐기가 자동화될 수 있다.
Last updated