# ROS2 보안 기초: 통신 암호화와 성능 영향

#### 통신 암호화의 필요성

ROS2 환경에서 노드 간 통신은 일반적으로 DDS(데이터 분산 서비스) 프로토콜을 바탕으로 이루어진다. DDS는 QoS 설정, 노드 간의 동적 발견(Discovery), 데이터 배포(Publish/Subscribe) 등을 효율적으로 처리하지만, 보안을 위한 기본적인 암호화 기능이 활성화되지 않으면 악의적인 공격자가 중간에서 데이터를 도청 혹은 변조할 위험이 있다. 이를 방지하기 위해 ROS2는 DDS Security 플러그인 또는 SROS2(Secure ROS2)와 같은 보안 확장 기능을 제공한다.

암호화가 제공하는 가장 중요한 이점은 다음과 같다.

1. **비밀성(Confidentiality)**: 송신한 메시지를 수신자 외에 다른 누구도 확인할 수 없도록 데이터를 암호화한다.
2. **무결성(Integrity)**: 메시지가 전송 중에 변조되지 않았음을 보장한다.
3. **인증(Authentication)**: 통신 당사자가 실제로 의도한 주체가 맞는지, 즉 메시지를 전송한 노드와 수신 노드를 상호 확인한다.

그러나 모든 환경에서 암호화를 사용하는 것이 무조건 좋은 것은 아니다. 암호화로 인한 오버헤드(Overhead)가 있기 때문이다. CPU 자원, 네트워크 대역폭, 메시지 전송 지연(Latency) 등에 영향을 미칠 수 있다.

#### DDS Security의 암호화 메커니즘

DDS Security는 “Security Plugins”라는 구조를 통해 인증, 접근 제어(Access Control), 암호화(Cryptographic) 등을 확장한다. 주요 암호화 플러그인의 작동 과정을 간단히 요약하면 다음과 같다.

1. **Authentication**: 노드들이 DDS 네트워크에 참여할 때 자신의 인증서(Certificate)와 키(Private Key)로 서명 등을 수행해 상대 노드를 신뢰할 수 있는지 확인한다.
2. **Access Control**: 인증이 완료된 노드에 대해서만 특정 토픽, QoS, 인터페이스 등에 대한 권한(Policy)을 검사한다.
3. **Cryptographic**: 승인된 노드 간 전송되는 데이터에 대해 대칭키(Symmetric Key) 암호화를 수행한다. 대칭키는 유출되지 않도록 별도의 암호화 기법으로 주고받는다.

DDS Security에서 암호화에 활용되는 기본 알고리즘과 파라미터는 구현체별로 다를 수 있지만(예: RSA, ECC, AES 등), 일반적으로 성능과 보안을 적절히 균형 맞춘 암호 알고리즘을 선택한다.

#### 암호화로 인한 성능 영향 개요

암호화를 적용하면 다음과 같은 성능 이슈가 발생할 수 있다.

1. **CPU 부하 증가** 대칭키 암호화(AES 등)를 적용하더라도 패킷의 크기가 큰 경우에는 CPU 사용률이 높아진다. 특히 메시지 발행 빈도가 높은 시나리오에서는 CPU 리소스가 부족해질 수 있다.
2. **메시지 크기 증가** 암호화에 필요한 부가정보(Nonce, IV, Auth Tag 등)가 추가되면서 실제 전송해야 하는 패킷 크기가 커진다. 그 결과 네트워크 트래픽이 증가하고, 대역폭이 제한된 환경에서 지연(Latency)이 늘어날 가능성이 있다.
3. **키 교환(Key Exchange) 지연** 비대칭키(Asymmetric Key) 기반 RSA, ECC 등의 키 교환 과정은 연산량이 많으며, 노드 간 처음 연결되는 순간 지연이 발생한다. 키가 잦은 주기로 재교환되어야 하는 보안 정책이라면 해당 지연이 주기적으로 발생할 수 있다.

#### 성능 저하 측정 지표

ROS2 암호화 설정이 전체 시스템 성능에 얼마나 영향을 미치는지 정량적으로 평가하기 위해서는 다음과 같은 지표를 측정한다.

1. **메시지 처리량(Throughput)** 일정 시간 동안 전송 가능한 메시지 양(예: MB/s)이 암호화 적용 전후로 어떻게 달라지는지 비교한다.
2. **평균 지연(Time Delay)** 노드 간 한 번의 메시지 전송에 걸리는 평균 소요 시간(왕복 지연 포함)을 측정한다. 암호화 전후의 변화를 확인하면 추가 오버헤드를 판단할 수 있다.
3. **CPU 사용률** 동일한 작업량(Pub/Sub 비율)이 있을 때 CPU 사용률의 차이를 살펴본다. 특히 에지 디바이스나 임베디드 환경에서는 CPU 리소스가 한정적이므로 중요하다.
4. **메모리 사용량** 암호화를 위해 추가적으로 필요한 버퍼, 키 저장공간, 인증서 로드 등에 따른 메모리 사용량 변화도 확인한다.

아래는 암호화에 따른 메시지 처리량 변화를 단순 모델링한 예시 수식이다. 메시지 송신 처리량을 $R$ (Mbps), CPU 클록 속도를 $f$ (Hz), 암호화 처리량(단위 연산량 당 처리 가능한 데이터 양)을 $C$ (bits/cycle)라고 할 때, 대략적인 형태로

R≈f×CR \approx f \times C

라고 볼 수 있다. 그런데 여기서 $C$는 암호 알고리즘에 따라 달라지며, $C$가 작아질수록(즉, 암호 연산이 복잡할수록) 처리 가능한 데이터 양이 줄어든다. 실제 상황에서는 QoS 설정, DDS 구현체, 네트워크 드라이버, 커널 프로세스 등의 많은 요소가 영향을 미치므로 정확한 해석을 위해서는 실험 데이터가 필요하다.

#### 암호 알고리즘 선택 가이드

ROS2에서 암호화를 구현할 때 알고리즘을 선택하는 것은 성능과 보안 수준 모두에 직결된다. DDS Security 또는 SROS2를 사용할 때, 기본적으로 다음과 같은 범주에서 알고리즘을 고려한다.

1. **대칭키(Symmetric-Key) 알고리즘**
   * 예: AES(Advanced Encryption Standard), ChaCha20 등
   * 특징: 빠른 암복호화 속도를 제공하지만, 키 교환(Key Exchange)에 별도의 안전한 채널이 필요하다. 일반적으로 AES를 많이 쓰며, 하드웨어 가속(예: AES-NI)을 이용할 경우 상당한 속도 개선을 기대할 수 있다.
2. **비대칭키(Asymmetric-Key) 알고리즘**
   * 예: RSA, ECC(Elliptic Curve Cryptography) 등
   * 특징: 키 교환이나 인증서 기반 서명에 사용된다. 연산이 대칭키 방식에 비해 무겁기 때문에, 대규모 메시지를 직접 암호화하기보다는 주로 \*\*키 합의(Key Agreement)\*\*나 **디지털 서명** 용도로 활용된다.
3. **해시(Hash) 및 MAC(Message Authentication Code)**
   * 예: SHA-256, SHA-3, HMAC 등
   * 특징: 메시지 무결성 검증과 인증에 사용한다. 암호화와 함께 반드시 고려되어야 하며, 메시지에 대한 해시값이나 MAC를 생성하여 악의적인 변조를 방지한다.

암호 알고리즘을 선택할 때 고려해야 할 요소는 다음과 같다.

* **배포 환경**: 에지(Edge) 디바이스나 임베디드 시스템처럼 리소스가 한정된 환경에서는 가벼운 알고리즘을 선택하거나 하드웨어 가속 기능을 활용해야 한다.
* **암호화 강도**: AES-128, AES-256 등 키 길이에 따른 보안 수준을 결정해야 하며, 임베디드 환경에서는 성능과 보안을 균형 있게 맞추는 게 중요하다.
* **상용 표준**: DDS Security 또는 SROS2 등 ROS2 내의 표준 보안 라이브러리에서 지원하는 알고리즘을 우선적으로 활용하면 호환성과 유지보수 측면에서 유리하다.

#### 암호화 성능 향상을 위한 하드웨어 활용

암호연산은 CPU 자원을 크게 사용하기 때문에, 하드웨어 차원에서의 암호화 지원을 적극적으로 이용하면 유리하다.

1. **AES-NI(Advanced Encryption Standard New Instructions)**
   * 인텔 프로세서에서 AES 암복호화 연산을 가속하기 위한 지시어 세트.
   * 소프트웨어 구현보다 월등히 빠른 속도를 제공하므로, AES 기반 암호화를 사용할 때는 해당 기능을 활성화하는 것이 권장된다.
2. **암호화 전용 Co-Processor**
   * GPU나 FPGA, 전용 보안 칩(HSM: Hardware Security Module) 등 추가 하드웨어에서 암호 연산을 처리한다.
   * 일반 CPU가 다른 작업(Pub/Sub, 센서 데이터 처리 등)에 전념하도록 만들어 전체 성능이 향상될 수 있다.
3. **TrustZone, SGX 등 보안 영역**
   * ARM의 TrustZone, 인텔의 SGX(Software Guard Extensions) 등과 같은 보안 영역에서 키 관리와 민감 정보를 처리하면, 키 유출 위험을 줄이고 성능을 일정하게 유지할 수 있다.

이러한 하드웨어 가속 기능들을 이용하면, 메시지 암호화 시에도 CPU 부하 및 지연을 줄여 ROS2 노드가 실시간 요구사항을 충족하도록 도와준다.

#### 암호화 설정과 ROS2 QoS의 상호작용

ROS2 QoS(Quality of Service) 정책 중 `Reliability`, `Durability`, `Deadline`, `LatencyBudget` 등의 설정은 암호화 적용 시 성능 저하가 어떤 방식으로 노출되는지에 영향을 준다.

* **Reliability (신뢰성)**
  * `Reliable` 모드: 수신자 측에서 패킷 누락을 감지하면 재전송을 요청한다. 재전송 패킷도 암호화가 되어야 하므로, 암호화 오버헤드에 재전송 요구가 겹치면 지연이 누적될 수 있다.
  * `Best Effort` 모드: 가능한 한 빠른 전송을 지향하며, 재전송은 보장되지 않는다. 암호화 오버헤드만 고려하면 되므로, 지연 측면에서 조금 더 유리할 수 있지만 데이터 신뢰성을 희생한다.
* **Durability (내구성)**
  * `Transient Local` 모드 등 저장소에 데이터를 보관해야 하는 경우, 저장 시에도 암호화가 적용되어야 할 수 있다. 이 경우 메모리나 디스크 I/O 성능이 암호 연산과 함께 고려되어야 한다.
* **LatencyBudget (지연 예산)**
  * 암호화 시 일정량의 추가 지연이 발생함을 QoS 정책에서 미리 반영해야 한다. 예산이 촉박한 경우, 하드웨어 가속이나 키 길이 조정 등으로 지연을 최소화해야 한다.

메시지 전달 경로에서 암호화를 고려하려면, ROS2 QoS 정책 설정 시 성능 테스트를 병행하여 실제 상황에 맞는 파라미터를 결정하는 것이 중요하다.

#### 암호화 적용 시 대표적인 베스트 프랙티스

ROS2 환경에서 암호화 구현을 안정적으로 유지하면서 성능 저하를 최소화하기 위해 다음과 같은 방법들을 고려할 수 있다.

1. **Pub/Sub 토픽 구분**
   * 모든 토픽에 전면적으로 암호화를 적용하기보다, 민감 데이터가 오가는 토픽만 선별적으로 암호화하는 전략을 사용한다.
   * 실시간 반응이 중요한 토픽(예: 제어 신호)은 암호화 없이 빠른 전송을 유지하고, 개인정보·보안정보가 포함된 토픽만 암호화하여 처리 비용을 줄인다.
2. **Hybrid Encryption(하이브리드 암호화)**
   * 비대칭키(Asymmetric) 알고리즘은 키 교환과 인증에만 쓰고, 실제 데이터는 대칭키(Symmetric) 알고리즘으로 암호화한다.
   * DDS Security 표준에서도 이 방식을 사용하여 대규모 데이터 전송 시 발생하는 비대칭키 연산 오버헤드를 줄인다.
3. **키 수명(Key Lifetime) 관리**
   * 키가 유출될 경우 보안 취약점이 생길 수 있으므로, 일정 주기로 새 키를 재발급하되, 재교환 빈도가 너무 높아 CPU 부하가 급증하지 않도록 조절한다.
   * ‘단기 키(Short-term Key)’와 ‘장기 키(Long-term Key)’를 구분해 쓰는 방식도 고려할 수 있다.
4. **메시지 압축 후 암호화**
   * 경우에 따라 메시지를 먼저 압축(예: LZ4, Zstd)하여 크기를 줄인 뒤 암호화하면, 결과적으로 암복호화해야 할 데이터 양이 줄어든다.
   * 특히 대역폭이 한정된 무선 환경에서 효과적일 수 있으나, 압축 과정 자체도 CPU 부하가 발생하므로 상황에 맞게 선택한다.
5. **성능 임계값 모니터링**
   * ROS2 노드의 성능(메시지 처리율, 지연 등)에 대한 임계값(Threshold)을 사전에 정의해 두고, 암호화 활성화로 인해 지표가 임계치를 넘어가는지 모니터링한다.
   * CPU 사용량, 네트워크 지연이 일정 수준을 넘으면 관리자에게 알림을 주거나 QoS, 암호화 파라미터를 동적으로 조정할 수 있는 메커니즘을 마련한다.

#### SROS2 설정 개요

SROS2(Secure ROS2)는 ROS2에서 요구되는 보안 기능을 손쉽게 사용할 수 있게 해주는 툴킷이자 설정 방식이다. 주요 구성 요소는 아래와 같다.

**Security Enclaves**:

* 하나의 프로세스, 혹은 노드 그룹을 독립된 ‘보안 구역(Enclave)’으로 설정한다.
* 각 Enclave마다 인증서와 권한 정책(Policy)을 부여해, 내부 노드들끼리 안전하게 통신할 수 있다.

**Policy 파일**:

* 각 노드나 토픽에 대해 접근 권한, 암호화 여부, 인증 방식 등을 정의한 XML 또는 YAML 형태의 파일.
* DDS Security 플러그인이 참조하여 노드 간 통신 시 접근을 제어한다.

**키와 인증서 생성 도구**:

* SROS2는 X.509 인증서 발급, CA(Certificate Authority) 생성 등을 위한 명령줄 도구를 제공한다.
* 예시로 아래와 같은 방식으로 인증서를 생성할 수 있다.

```bash
# CA (루트 인증서) 및 키 생성
ros2 security create_ca my_ca

# 특정 Enclave(예: /my_robot_ns/my_node)에 대한 인증서 생성
ros2 security create_key my_ca /my_robot_ns/my_node
```

이 과정을 거쳐 노드가 실행될 때, ROS2는 SROS2에서 설정된 인증서와 권한 정책을 참조하여 암호화 통신이 자동으로 이뤄지도록 구성한다.

#### 암호화와 보안 정책의 동적 업데이트

ROS2 시스템이 장기간 동작하거나, 노드가 새롭게 추가·삭제되는 상황에 따라 보안 정책을 동적으로 업데이트해야 하는 경우가 발생한다.

* **재시작(Hot Restart) 없는 업데이트**
  * 실시간 제어 시스템에서는 노드를 멈출 수 없으므로, 런타임 중에 새 노드를 등록하거나 기존 노드의 접근 권한을 철회해야 할 수 있다.
  * DDS Security 또는 SROS2 구현체에서 재시작 없이 변경된 정책을 반영할 수 있도록 지원하는지 확인해야 한다.
* **확장성(Scalability)**
  * 노드 개수가 많아질수록, 인증서 및 정책 관리가 기하급수적으로 복잡해진다.
  * 중앙 집중식 CA 서버와 자동화된 정책 분배 툴을 사용하면, 네트워크 규모가 커져도 보안을 유지하기 수월해진다.

보안 정책을 동적으로 유지하면서 성능 저하를 최소화하기 위해서는 CA 서버의 신뢰성, DDS Security 구현체의 성능, 그리고 네트워크 구조 전반에 대한 사전 계획이 필수적이다.

#### 암호화 성능 테스트와 벤치마크 기법

ROS2 환경에서 암호화가 실제로 얼마나 성능에 영향을 미치는지 정량적으로 파악하려면, 다음과 같은 단계를 거쳐 벤치마크를 수행하는 것이 좋다.

1. **테스트 시나리오 정의**
   * 메시지 크기, 발행(Publish) 주기, QoS 설정 등을 명확히 지정해야 한다.
   * 실제 사용 환경과 최대한 비슷한 조건(네트워크 대역폭, 하드웨어 스펙, 노드 수)을 구성한다.
2. **참조 지표 및 툴 선택**
   * $t\_\mathrm{latency}$ (전송 지연), 처리량(Throughput), CPU 사용률, 메모리 점유량 등을 측정한다.
   * ros2 topic benchmark 도구, ros2 CLI(커맨드 라인 인터페이스), 다양한 DDS 모니터링 툴을 사용할 수 있다.
3. **암호화 옵션별 비교**
   * 암호화 없이(Plain) vs. 대칭키 기반(AES-128 등) vs. 하드웨어 가속(AES-NI) vs. 키 길이 확장(AES-256 등)의 시나리오로 나누어 측정한다.
   * 결과 그래프를 통해 메시지 크기, 메시지 전송률(Pub rate)에 따른 성능 곡선을 확인한다.
4. **모니터링 및 로그 분석**
   * 벤치마크 실행 중에 ddsperf, eProsima Fast DDS Monitor, Eclipse Cyclone DDS 툴 등의 모니터링 기능으로 실시간 지표를 수집한다.
   * SROS2 로그(특히 보안 플러그인 로그)를 분석해, 암호화·복호화에 걸리는 시간과 키 교환 시점을 추적한다.

아래는 예시로, ROS2 노드 간 메시지 전송에 대해 $N$개의 메시지를 전송했을 때 측정된 평균 지연($\bar{t}\_\mathrm{latency}$)과 최대 처리량($T\*\mathrm{max}$)을 비교하는 단순 표 형식 예시이다.

| 암호화 방식          | 평균 지연($\bar{t}\_\mathrm{latency}$) | 최대 처리량($T\_\mathrm{max}$) |
| --------------- | ---------------------------------- | ------------------------- |
| 없음(Plain)       | 5 ms                               | 10,000 msg/s              |
| AES-128 (SW)    | 8 ms                               | 8,000 msg/s               |
| AES-128 (HW 가속) | 6 ms                               | 9,500 msg/s               |
| AES-256 (SW)    | 12 ms                              | 6,000 msg/s               |

(\* 위 수치는 가상의 예시이므로 실제 환경과 다를 수 있음)

#### 모바일·임베디드 디바이스 시나리오

로봇 시스템이 소형 드론, 자율주행차, IoT 센서 등 임베디드 프로세서를 사용하는 환경으로 확장되면서, 암호화에 따른 성능 문제는 더욱 부각된다.

1. **한정된 처리 능력**
   * ARM 코어 기반 디바이스나 MCU(Microcontroller Unit)는 CPU 클록 속도와 메모리가 제한적이다.
   * AES-NI 같은 기능이 제공되지 않을 수 있어, 소프트웨어 방식 암호화로 인한 부하가 크다.
2. **저전력 요구사항**
   * 임베디드 디바이스는 전력 사용이 제한적이며, 암호화 연산 시 CPU 부하와 함께 전력 소모가 증가한다.
   * 배터리 수명을 고려할 때, 필요 최소한의 암호화만 적용하거나, 전용 보안 칩(예: ARM TrustZone-M)을 통해 전력 사용 효율을 높일 수 있다.
3. **무선 네트워크 특성**
   * 드론, AGV(Automated Guided Vehicle) 등 무선 통신이 기본인 환경은 신호 세기가 약하거나 대역폭이 제한적일 수 있다.
   * 암호화로 인해 패킷 크기가 커지거나 재전송이 늘어날 경우, 무선 링크 품질이 더욱 저하될 위험이 있다.
4. **고급 보안 기능 적용 시 Trade-off**
   * 예: TPM(Trusted Platform Module)으로 키를 안전하게 저장하거나, 안전부팅(Secure Boot)까지 도입하면 전체 시스템 보안 수준이 높아진다.
   * 하지만 임베디드 환경에서 이 모든 보안 기능을 활성화하면 부팅 시간, 운영 중 지연이 증가할 수 있다.

#### 디버깅 및 트러블슈팅

암호화가 적용된 ROS2 환경에서는 패킷이 암호화되어 있기 때문에, 단순 와이어샤크(Wireshark) 패킷 캡처로는 내용 확인이 어렵다. 트러블슈팅 시 다음과 같은 방법들을 고려한다.

1. **DDS Security 로그 레벨 조절**
   * DDS 구현체(eProsima Fast-DDS, Eclipse Cyclone DDS 등)에서 보안 플러그인의 로그 레벨을 높여, 키 교환·인증서 검증 과정에서 문제가 발생하지 않는지 확인한다.
2. **동적 정책 검사**
   * SROS2 Policy 파일에서 특정 노드 또는 토픽에 접근 권한이 올바르게 설정되었는지, Policy XML/YAML이 DDS Security 플러그인에서 정상 파싱되는지 확인한다.
3. **네트워크 계층 모니터링**
   * 암호화된 데이터라도, 패킷 크기와 전송 빈도는 확인할 수 있으므로 네트워크 트래픽 모니터링이 가능하다.
   * 지연이 과도하게 증가하는 지점(특정 라우터, 무선 AP 등)을 찾아낼 수 있다.
4. **암호화 설정 단계별 테스트**
   * 인증(Authentication)만 활성화, 인증 + 무결성, 인증 + 무결성 + 암호화 등 점진적으로 보안 기능을 하나씩 추가해보며, 성능 저하가 어느 부분에서 가장 크게 발생하는지 파악한다.