보안 키(Key)와 인증서(Certificate) 생성

ROS2의 DDS 보안은 PKI(Public Key Infrastructure)를 활용하여 통신 데이터를 안전하게 보호한다. 이때 핵심이 되는 것이 바로 보안 키(Key)와 인증서(Certificate)를 올바르게 생성하고 관리하는 것이다. 여기서는 ROS2 보안 정책에 맞추어 키 및 인증서를 생성하는 일반적인 방법을 다룬다.

배경

• DDS 보안 계층은 메시지 무결성, 기밀성, 인증 등을 위해 공개키 암호 기반(PKI)의 메커니즘을 사용한다.

• **키(Key)**는 주로 비대칭키(Private Key, Public Key) 형태로 사용되며, 이를 통해 디지털 서명, 암호화, 인증 등의 기능을 수행한다.

• **인증서(Certificate)**는 키에 대한 소유자 정보와 신뢰 체인(Chain of Trust)을 포함하는 서명된 문서로, CA(Certificate Authority)가 서명(Sign)하여 신뢰성을 보장한다.

• 보안 설정을 위해서는 노드별(private key, public key, certificate)와 CA 관련(private key, CA certificate) 파일들이 필요하다.

키 생성 기본 절차

ROS2에서 DDS 보안을 활성화하려면 노드마다 고유한 키가 필요하고, 그 키에 대응하는 인증서가 필요하다. 핵심 절차는 아래와 같다.

1. CA(Certificate Authority) 준비

   • CA로 사용할 인증서를 하나 생성하고, 이를 통해 노드들의 인증서를 서명한다.

2. 개별 노드용 개인키(Private Key) 생성

   • 노드마다 개인키를 생성한다.

3. 개별 노드용 인증서 서명 요청(CSR, Certificate Signing Request) 생성

   • 노드별 개인키를 바탕으로 인증서 요청(CSR)을 만든다.

4. CA로부터 인증서 발급

   • CA의 개인키로 노드의 CSR을 서명하여 인증서를 발급한다.

5. ROS2 DDS 보안 디렉토리 구조에 배치

   • 생성된 키와 인증서를 노드 실행 환경에 맞게 배치한다.

개인키(Private Key) 생성

일반적으로 OpenSSL을 사용해 개인키를 생성할 수 있다. 예를 들어 RSA 방식으로 4096비트 길이의 개인키를 생성하려면 다음과 같은 명령을 사용할 수 있다.

openssl genpkey -algorithm RSA -out node_private_key.pem -pkeyopt rsa_keygen_bits:4096

다른 예로, Elliptic Curve(ECDSA) 방식의 키를 생성하려면 다음과 같이 명령을 사용할 수 있다.

openssl ecparam -name prime256v1 -genkey -noout -out node_ec_private_key.pem

인증서 서명 요청(CSR, Certificate Signing Request) 생성

개인키가 생성되면, 해당 키를 이용해 CSR 파일을 만든다. CSR은 아래 명령으로 생성할 수 있다.

openssl req -new -key node_private_key.pem -out node.csr -subj "/C=KR/ST=Seoul/O=MyROS2Org/OU=Robotics/CN=my_node"

• -subj 옵션은 인증서에 포함될 DN(Distinguished Name) 정보를 지정한다.

• CN(Common Name)은 ROS2 노드 식별에 적절한 문자열을 설정한다.

CA(Certificate Authority) 인증서 준비

ROS2 보안에는 ‘루트 CA’ 혹은 ‘중간 CA’를 통해 신뢰 체인을 형성한다. 여기서는 루트 CA를 직접 만드는 예시를 든다. 먼저 CA용 개인키를 생성한다.

openssl genpkey -algorithm RSA -out ca_private_key.pem -pkeyopt rsa_keygen_bits:4096

그리고 CA 자체 인증서(루트 인증서)를 생성한다.

openssl req -x509 -new -nodes -key ca_private_key.pem -sha256 -days 3650 -out ca_certificate.pem -subj "/C=KR/ST=Seoul/O=MyROS2RootCA/OU=Robotics/CN=my_root_ca"

노드 인증서 발급

위에서 생성한 CA 개인키와 CA 인증서를 사용하여, 노드 CSR을 서명하면 노드 인증서를 발급할 수 있다.

openssl x509 -req -in node.csr -CA ca_certificate.pem -CAkey ca_private_key.pem -CAcreateserial -out node_certificate.pem -days 3650 -sha256

• -CAcreateserial 옵션은 $CA.srl$ 파일을 자동 생성하여 일련번호(Serial Number)를 부여한다.

• -days 옵션은 인증서 유효기간을 지정한다. (예: 3650일 = 10년)

보안 디렉토리 구조

ROS2에서 DDS 보안을 적용하려면 보안 아티팩트(개인키, 인증서, 정책 파일 등)를 특정한 구조에 맞추어 저장해야 한다. 이 구조를 잘 지켜야만 각 노드가 올바른 보안 정보를 읽고 통신할 수 있다. 대표적으로 ROS_SECURITY_NODE_DIRECTORY라는 환경 변수를 사용해, 노드별로 다음과 같은 하위 디렉토리를 구성한다.

• certs 폴더: 노드 인증서(node_certificate.pem), CA 인증서(ca_certificate.pem) 등 공개키 인증서(Certificate) 파일들이 위치

• keys 폴더: 노드 개인키(node_private_key.pem) 등 민감한 키(Key) 파일들이 위치

• governance.p7s: 보안 정책(Governance) 파일(서명된 형태)

• permissions.p7s: 권한 설정(Permissions) 파일(서명된 형태)

ROS2 프로세스가 구동될 때, DDS 보안 계층에서 이 디렉토리를 참고하여 키-인증서-정책을 로드한다.

노드별 디렉토리 예시

예를 들어 노드 이름이 my_node라면, ROS_SECURITY_NODE_DIRECTORY를 다음과 같이 설정할 수 있다.

export ROS_SECURITY_NODE_DIRECTORY=/path/to/my_security/my_node

그 경로 아래 구조는 대략 아래와 같다:

/path/to/my_security/my_node
  ├─ certs
  │   ├─ node_certificate.pem
  │   └─ ca_certificate.pem
  ├─ keys
  │   └─ node_private_key.pem
  ├─ governance.p7s
  └─ permissions.p7s

물론 노드마다 디렉토리가 달라질 수 있으나, 각 노드별로 독립적인 키/인증서/정책 파일을 가져야 한다.

CA 인증서 체인 구성

CA가 여러 계층(중간 CA, 서브 CA 등)으로 구성된 상황이라면, 노드가 참조하는 CA 인증서(ca_certificate.pem)에는 전체 체인(Full Chain)을 포함해야 한다. 예를 들어 루트 CA, 중간 CA 등 여러 인증서가 있을 때, 체인 파일에 각 인증서를 연결하여 사용한다.

cat intermediate_ca_certificate.pem root_ca_certificate.pem > ca_certificate_chain.pem

이렇게 합쳐진 ca_certificate_chain.pem 파일을 노드의 certs 폴더에 배치하면 된다.

권장 키 길이와 알고리즘

• RSA 4096비트

  정도를 권장한다.

  • 키 길이가 길수록 보안 강도가 높아지지만, 반면 계산 비용이 커진다.

• **ECDSA (prime256v1 등)**를 사용하면, 적절한 보안 강도를 유지하면서도 빠른 연산 속도를 얻을 수 있다.

일반적으로 로봇 시스템의 성능, 보안 요구사항 등을 고려해 선택한다.

예시: ECDSA 키와 인증서 일괄 생성 스크립트

여러 노드의 키와 인증서를 대량으로 생성하려면 스크립트를 작성하여 자동화하는 것이 좋다. 예시로, ECDSA 키와 인증서를 생성하는 간단한 스크립트를 살펴보자.

#!/usr/bin/env bash

# Usage: ./generate_ec_certs.sh <NODE_NAME>

NODE_NAME=$1

# 1. Create private key
openssl ecparam -name prime256v1 -genkey -noout -out ${NODE_NAME}_private_key.pem

# 2. Create CSR
openssl req -new -key ${NODE_NAME}_private_key.pem \
    -out ${NODE_NAME}.csr \
    -subj "/C=KR/ST=Seoul/O=MyROS2Org/OU=Robotics/CN=${NODE_NAME}"

# 3. CA signing (assume CA key and cert already exist)
openssl x509 -req -in ${NODE_NAME}.csr \
    -CA ca_certificate.pem -CAkey ca_private_key.pem \
    -CAcreateserial -out ${NODE_NAME}_certificate.pem \
    -days 3650 -sha256

echo "ECDSA key and certificate for ${NODE_NAME} generated successfully."

위 스크립트 실행 예시는 다음과 같다.

./generate_ec_certs.sh my_node

실행 결과로 my_node_private_key.pem, my_node.csr, my_node_certificate.pem이 생성된다. 이를 노드 전용 디렉토리로 옮겨서 사용한다.

파일 권한 관리

보안 키와 인증서 파일이 올바르게 생성되었다 해도, 시스템 파일 권한을 잘못 설정하면 악의적인 접근을 막지 못할 수 있다. 특히 개인키(Private Key) 파일은 절대 외부로 유출되어서는 안 되므로 최소 권한으로 설정해야 한다.

개인키 파일(.pem)에 대한 일반적인 권장 권한:

chmod 400 node_private_key.pem

이렇게 하면 파일 소유자만 읽기 가능하고, 쓰기나 실행 권한은 없다.

인증서 파일(.pem)이나 정책 파일(.p7s)도 불필요한 쓰기 권한은 제거한다.

chmod 444 node_certificate.pem

일반적으로 읽기만 필요한 파일은 444(소유자, 그룹, 기타 모두 읽기) 정도로 설정한다.

운영 환경에 따라 그룹 권한이나 사용자 권한을 세분화하여 관리할 수도 있다. 예를 들어 여러 노드가 공통 그룹을 사용한다면, 그룹 권한을 허용해둘 수도 있지만, 개인키 파일에 대해서는 그룹 읽기 권한조차 제거하는 것이 안전하다.

Subject Alternative Name(SAN) 처리

ROS2 노드가 특정 도메인이나 IP 주소로 식별될 가능성이 있으면, 인증서에 SAN(Subject Alternative Name)을 포함해야 할 수 있다. 예를 들어 내부 DNS로 노드 이름을 관리하거나, IP 주소 기반으로 통신해야 하는 경우가 이에 해당한다.

QOpenSSL로 CSR 생성 시, SAN을 포함하려면 별도의 설정 파일을 사용하거나 -addext 옵션을 사용한다.

예시 (SAN에 IP와 도메인 이름 모두 추가):

openssl req -new -key node_private_key.pem -out node.csr \
    -subj "/C=KR/ST=Seoul/O=MyROS2Org/OU=Robotics/CN=my_node" \
    -addext "subjectAltName = DNS:my_node.local, IP:192.168.1.10"

CA 서명 시에도 SAN이 유지되도록 CA 설정 파일 혹은 명령 옵션을 맞춰주어야 한다.

인증서 유효성 검사

생성된 인증서가 ROS2 DDS 보안에서 제대로 동작하는지 확인하기 위해서는, OpenSSL을 사용하여 인증서 체인과 서명을 검증해볼 수 있다.

openssl verify -CAfile ca_certificate.pem node_certificate.pem

위 명령을 통해 노드 인증서가 CA 인증서로부터 유효하게 서명되었는지 확인한다. 루트 CA와 중간 CA가 여러 개 있다면, -CAfile에 전체 체인을 포함한 파일을 지정한다.

추가 고려사항

• 갱신 주기: 임시 프로젝트가 아닌, 장기간 운용되는 로봇 시스템의 경우, 인증서 유효기간이 만료되기 전에 미리 갱신해야 한다.

• CRL(Certificate Revocation List): 만약 특정 노드 인증서가 유출되었거나 무효화해야 하는 상황이 발생하면, CA 측에서 CRL을 관리하고 DDS 보안 설정에 반영해야 한다.

• 하드웨어 보안 모듈(HSM): 민감한 키를 안전하게 보관하기 위해 HSM(Hardware Security Module) 사용을 고려할 수도 있다.