Blog & News

신뢰도 높은 자율주행 기술을 구현하기 위해서는 차량 주변의 3차원 환경을 실시간으로 정확하게 재구성하는 것이 필수적입니다. 42dot에서는 실시간으로 작동하는 고성능 3차원 인지 모델을 개발하기 위해 지속적으로 데이터를 수집하고, 모델의 성능을 추적하여 자율주행 기술을 발전시키고 있습니다. 1. 객체 탐지 모델의 중복 예측 문제와 그 영향 자율주행 자동차는 차량 주변의 환경을 재구성하여 장애물의 위치를 파악하고, 다른 차량과 보행자의 움직임을 예측하여, 차량이 안전하게 주행할 수 있는 경로를 계획합니다. 따라서, 자율주행 시스템에서 가장 먼저 수행되는 3차원 객체 탐지 모델의 정확도는 차량의 안정적인 운행에 큰 영향을 미칩니다. 42dot에서는 지속적으로 데이터를 수집하여 모델을 평가, 개선하고 있습니다. 최근 추가된 데이터로 모델을 평가한 결과, 작은 구역에 보행자가 4-5명 모여있는 경우, 실제 보행자 수보다 많은 중복 예측이 발생하는 것을 확인했습니다. 이러한 중복 예측은 자율주행 차량이 존재하지 않는 물체를 인식하게 만들어 비정상적인 움직임을 유발할 수 있습니다. 예측된 결과의 후처리 과정에서 예측 점수의 임계값을 높여 오탐지를 줄일 수 있지만, 이 경우 탐지하지 못하는 보행자의 수가 증가하여 안전에 위협이 될 수 있습니다. 예측된 보행자의 점수가 낮은 경우, 검출된 물체가 중복된 예측일 확률이 높아집니다. 2. Active Learning Pipeline 42dot에서는 모델의 약점을 개선하기 위해 유사한 케이스의 데이터를 지속적으로 수집하고 네트워크 학습에 포함시키는 Active Learning Pipeline을 운영하고 있습니다. 이때 새롭게 수집된 데이터를 사람의 개입을 최소화하며 효율적으로 모델 학습에 포함시키기 위해, 비실시간으로 동작하는 고성능 모델을 사용하고 있습니다. 이렇게 고성능 모델에서 학습된 지식은, 차량에서 실시간으로 동작하는 모델에 증류(distillation)되어 성능을 향상시키는데 이용됩니다. 3. Transformer 모델 구조 도입 최신의 객체 탐지 모델[1, 2]들은 트랜스포머 구조 도입하여 성능을 크게 향상시키고 있습니다. 트랜스포머는 object query들이 self-attention을 통해 객체 간 정보를 교환하고, feature map의 전체 정보를 활용하여 CNN 구조보다 더 풍부한 정보를 활용할 수 있습니다. 특히 트랜스포머 기반의 객체 탐지 모델은 학습 과정에서 GT와 예측 사이의 one-to-one 매칭을 사용하기 때문에 중복 예측을 억제하는 데 큰 효과가 있습니다. 이러한 트랜스포머 모델의 특성은 보행자 중복 예측 문제를 효과적으로 해결하여 보행자 탐지 성능을 크게 향상시킬 수 것이라고 기대할 수 있습니다. 4. Denoising 기법 활용 하지만 기대와는 다르게 단순히 트랜스포머 기반의 객체 탐지 모델을 도입하는 것만으로는 높은 성능 향상을 확인할 수 없었습니다. 문제의 원인을 파악하기 위해 모델의 클래스 별 object query의 개수를 분석한 결과, 사람이 매우 밀집된 도심 구간에서는 아래와 같이 보행자 주변에서 생성된 object query의 숫자가 매우 많기 때문에 생성된 object query와 GT를 매칭하는 과정에서 학습이 불안정해지는 것을 알 수 있었습니다. 이를 해결하기 위해 2023년 CVPR에서 소개된 Dense Distinct Query[3] 기법을 적용하여 문제를 해결하고 학습의 안정성을 확보할 수 있었습니다. 5. 성능 향상 결과 이와 같이 다양한 기술을 도입하여 보행자 중복 예측의 수를 대폭 감소시키면서 모델의 정밀도(precision)를 크게 향상시켰습니다. 또한, 보행자의 위치, 크기, 진행 방향 등의 예측 품질도 한층 더 개선되었습니다. 이렇게 향상된 고성능 모델은 차량에 적용되어 주행 성능을 높이는 데 사용됩니다. 42dot은 끊임없는 기술 개발과 연구를 통해 자율주행 기술을 더 안전하고 친숙하게 발전시키기 위해 최선을 다하고 있습니다. 김영석, 차주한(Intern) ⎢ AD Algorithm 자율주행 차량이 주변 환경을 더욱 빠르고 정확하게 이해할 수 있도록 돕는 기술을 개발하고 있습니다. Reference [1] Nicolas Carion et al., “ End-to-End Object Detection with Transformers ,” ECCV, 2020. [2] Xuyang Bai et al., “ TransFusion: Robust LiDAR-Camera Fusion for 3D Object Detection with Transformers ,” CVPR, 2022. [3] Shilong Zhang et al., “ Dense Distinct Query for End-to-End Object Detection ,” CVPR, 2023.

42dot에서는 지난 가을, 자체 개발한 초거대 언어 모델인 42dot LLM을 공개한 바 있습니다. 42dot LLM은 국내 최초의 한영 통합 언어 모델로서 직접 구축한 데이터와 자체 학습 인프라를 활용해, 비슷한 규모의 다른 언어 모델 대비 월등한 성능을 달성하며 좋은 품질을 보여줬습니다. LLM은 크게 사전 학습 모델인 PLM과 사용자 지침을 따르도록 튜닝한 파인 튜닝 모델로 구분할 수 있습니다. 저희는 두 모델을 모두 공개하였으며, 전자는 42dot LLM-PLM이라는 이름으로, 후자는 42dot LLM-SFT라는 이름으로 공개한 바 있습니다. [42dot LLM 실행 데모] https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B 1. SFT 모델 미세 조정 모델 중에서도 정교하게 레이블을 지정한 소규모 데이터셋을 이용해 사전 학습 모델의 가중치와 편향을 조정하는 기법을 Supervised Fine-Tuning이라 하는데, 이 기법을 활용한 언어 모델을 해당 기법의 영어 약어를 덧붙여 SFT 모델이라 부릅니다. 저희가 공개한 생성 언어 모델 또한 SFT 기법을 활용했기 때문에 특별히 42dot LLM-SFT라 명명하였으며, 우리가 흔히 챗GPT처럼 대화를 주고받을 수 있는 LLM을 이야기할 때는 바로 이 SFT 기법을 활용한 모델을 일컫습니다. 2. 라마(LLaMA) 구조 42dot LLM은 여타 LLM과 동일하게 트랜스포머의 디코더 구조를 사용하며, 특히 페이스북에서 오픈소스로 공개하여 큰 호응을 얻은 바 있는 라마(LLaMA)와 거의 동일한 구조를 채택하였습니다. 굳이 라마를 택한 이유는 다양한 프레임워크와의 호환성을 유지하기 위해 오랜 기간 심사숙고하여 내린 결정이며, 그 덕분에 한글을 전혀 이해하지 못하는 라마와 달리 저희 모델은 한글을 자연스럽게 이해하면서 해외 유명 프레임워크에서도 아무런 문제 없이 자연스럽게 구동됩니다. 물론 구조만 동일할 뿐 라마 모델의 원래 매개변수는 전혀 사용하지 않았기 때문에 모든 매개변수는 바닥부터 저희가 직접 학습을 진행하였습니다. 3. 모델 크기 42dot LLM은 13억 개가 넘는 매개변수를 지닌 1.3B 모델이며, 총 24개의 레이어를 갖고 있는 초거대 언어 모델입니다. 여기에 라마와 거의 동일한 분량인 1.4조(1.4T) 개의 토큰을 이용해 학습을 진행하였으며, 해외의 여타 LLM과 달리 대량의 고품질 한글 데이터를 포함하여, 한글과 영어를 동시에 이해하는 한영 통합 언어 모델을 구축하였습니다. 4. 토크나이저 문장을 단어 또는 음절 같이 최소 단위로 나누는 작업을 토큰화(Tokenization) 작업이라고 하며 이 작업을 하는 도구를 토크나이저(Tokenizer)로 부릅니다. 이 중 글자를 바이트 단위로 쪼개어, 자주 등장하는 바이트의 쌍을 쌓아나가는 방식을 Byte-Pair Encoding, 줄여서 BPE 알고리즘이라 하는데 이 방식은 한글에도 매우 유리합니다. 왜냐면 우리말은 교착어이기 때문에 다양한 표현이 가능하여 분석하기 어렵지만 BPE는 이런 다양한 변형을 잘 파악할 수 있기 때문이죠. 이 때문에 오픈 AI의 GPT도 같은 방식을 사용한 바 있으며, 저희 42dot LLM 또한 BPE 방식을 사용해 문장을 토큰화하고 있습니다. 이렇게 토큰화 과정을 거쳐 한글과 영어 토큰 약 5만여 개로 구성된 단어 사전을 구축하였으며 이 과정은 총 1천만 건의 문서를 샘플링하여 구축하였습니다. 5. GPU 학습 클러스터 42dot은 320장의 GPU를 동시에 투입할 수 있는 고성능의 GPU 학습 클러스터를 자체 구축하여 보유하고 있습니다. 42dot LLM-PLM의 학습 또한 이 인프라를 활용하였으며 A100 80G GPU로 총 49,152 시간(GPU hours) 동안 학습을 진행하였습니다. 320장을 동시에 투입할 경우 약 1주일 남짓 소요되는 시간이며, 여기에 더해 42dot LLM-SFT에 112 시간(GPU hours)을 추가로 학습하였습니다. 6. 성능 평가 결과 이렇게 완성된 42dot LLM은 제로샷 성능 평가에서 비슷한 규모의 다른 언어 모델 대비 월등한 성능을 달성하였습니다. 한국어뿐만 아니라 영어에서도 높은 성능을 보였으며 10가지 카테고리에 대해 총 121개의 프롬프트로 구성한 대화 성능 평가에서도 비슷한 규모의 다른 언어 모델에 대비해서 압도적인 성능 차이를 보입니다. 심지어 GPT-3.5와도 크게 차이 나지 않는 놀라운 품질을 보여줍니다. 7. 모델 무료 공개 각 모델 파일은 모두 무료로 공개하였습니다. 또한 간단한 생성 코드를 함께 제공하여 누구나 손쉽게 LLM을 구동할 수 있도록 하였습니다. 라이선스는 CC BY-NC 4.0를 따르며 출처를 밝히면 비상업적 용도에 한 해 누구나 자유롭게 활용하실 수 있습니다. https://huggingface.co/42dot/42dot_LLM-PLM-1.3B https://huggingface.co/42dot/42dot_LLM-SFT-1.3B 저희는 오픈소스 생태계의 힘을 믿습니다. 여타 LLM과 마찬가지로 42dot LLM도 환각(Hallucination) 현상 같은 근본적인 문제를 지니고 있으며, 미처 포함하지 못한 질문-응답 케이스가 존재할 수 있기 때문에 기대하는 형태의 응답을 생성하지 못할 수도 있습니다. 하지만 혁신을 촉발하는 오픈소스의 힘은 이 같은 문제 또한 근시일 내에 해결해 내리라 믿습니다. 42dot의 국내 최초 한영통합 언어 모델 공개로 우리나라의 LLM 생태계가 한 단계 더 도약하길 기대해 봅니다. LLM Group 새로운 유형의 모빌리티 경험을 제공하기 위한 large language model을 개발하고 있습니다.

CES 2024에서 현대자동차그룹이 발표한 ‘software-defined everything’ 전략에 맞춰 그룹의 글로벌 소프트웨어 센터인 42dot이 공개한 새로운 SDV 전기・전자 아키텍처와 핵심 기술들을 소개합니다. 1. New E/E Architecture for SDV 최근 차량에 많은 기능이 탑재되면서 차량의 전기・전자 아키텍처 또한 복잡해지고 있습니다. 이런 복잡성은 차량 개발을 위한 시간과 비용을 증가시켜 새로운 기능을 쉽게 추가하기 어렵게 만듭니다. 42dot은 이 문제를 해결하기 위해 SDV (software-defined vehicle)로 하드웨어와 소프트웨어를 디커플링하여 차량의 아키텍처를 단순화하였습니다. 새로운 전기・전자 아키텍처는 고성능 차량용 컴퓨터인 HPVC와 차량의 센서와 액추에이터를 제어하는 zone controller 그리고 SDV OS로 구성되어 있으며, 이를 통해 엔지니어는 소프트웨어 개발에 집중하여 사용자 경험에 최적화된 시스템을 빠르게 만들 수 있습니다. 1.1 HPVC (High-Performance Vehicle Computer) SDV 전기・전자 아키텍처의 핵심은 고성능 차량용 컴퓨터인 HPVC (high-performance vehicle computer)입니다. HPVC는 여러 기능을 동시에 실행하는 고성능 제어기로 하드웨어와 도메인 컨트롤러의 기능을 하나의 유닛으로 통합하여 하드웨어를 단순화할 수 있습니다. HPVC는 다음과 같은 주요 기능이 있습니다. • 차량 내부 제어기들 사이의 커뮤니케이션에 필요한 gateway 역할을 합니다. • 차량 내/외부의 data를 저장하는 storage 역할을 제공하여 필요한 애플리케이션에서 사용할 수 있도록 합니다. • Connected service를 위한 RF 통신 장치로, LTE (5G), BT/WiFi 등을 통해 차량의 정보를 외부로 연결하고 차량 제어, OTA를 위한 데이터를 외부로부터 수신할 수 있습니다. • 레벨 2(ADAS)부터 레벨 4의 자율주행 시스템까지 포함하는 자율주행 스택은 사용자에게 안전한 이동을 제공합니다. • 운전 정보와 멀티미디어 콘텐츠와 같은 엔터테인먼트와 AI 어시스턴트 음성 제어를 통해 차량 편의 장치 및 앱 서비스를 제공할 수 있는 IVI (In-vehicle infotainment) 스택도 제공합니다. 1.2 Zone Controller Zone controller는 차량의 센서와 액추에이터를 제어하는 전자 제어 장치입니다. 기존 수십에서 백여 개에 달하는 제어 시스템을 zone controller를 통해 물리적으로 통합함으로써 전기・전자 아키텍처의 복잡성을 낮춰 SDV (software-defined vehicle)로의 전환에 빠르게 대응할 수 있습니다. 또한 차량 구역 단위로 제어기들을 통합하여 기능적으로도 재구성할 수 있으며, 차량의 신경/혈관과도 같은 배선을 통해 전력 공급과 제어/통신의 복잡도를 낮춤으로써 비용 또한 절감할 수 있습니다. 또한, SDV 전기・전자 아키텍처는 fault-tolerant 시스템으로 기능 장애에 즉시 대응할 수 있는 장점이 있습니다. 특정 zone controller에 장애가 발생해도 디커플링된 아키텍처와 SDV OS의 fault tolerance로 다른 zone controller가 그 역할을 대신 수행할 수 있습니다. 1.3 SDV OS SDV OS는 HPVC, zone controller, high speed network backbone으로 재편된 전기・전자 아키텍처에서 애플리케이션이 안정적이고 효율적으로 동작하도록 관리합니다. 또한 통합된 차량 API는 분산된 하드웨어로 구성된 차량이 하나의 제품처럼 가상으로 관리되어 소프트웨어의 유연성을 극대화하며, 차량 전반의 리소스 사용을 최적화합니다. SDV OS상에서 구현되는 모든 application들은 안전한 시스템을 제공하기 위해 미션 크리티컬 시스템을 위한 프로그래밍 언어인 Rust를 기본 언어로 사용합니다. 2. Core SDV Technologies 42dot은 자동차를 ‘AI 머신’ 즉, 스스로 배우고 개선하는 기계로 정의하고 있습니다. 엔지니어가 주는 데이터만으로 학습하는 것이 아니라, 차량이 각종 센서 등으로부터 수집한 데이터 기반으로 학습, 분석, 인지, 판단 및 제어까지 하는 기술들을 개발하고 있습니다. SDV로 고객이 누리게 될, 안전하고 지속적으로 개선되는 사용자 경험과 편의를 제공하는 기술들을 소개합니다. 2. 1 Data-Driven Learning Systems 42dot은 스마트한 AI 시스템을 만들기 위해 차량을 끊임없이 학습하고 개선되는 AI 머신으로 규정하고 AI와 자율주행 기술을 대중에게 제공하는 목표를 가지고 있습니다. 42dot은 지속적으로 데이터를 수집, 가공 및 학습시켜 AI 모델을 검증하고 카메라 기반의 자율주행 기술을 개선하고 있습니다. 2주 단위 스프린트로 개발, 시뮬레이션, R&D 검증을 거쳐 최종적으로 서비스 차량에 소프트웨어를 배포하는 빠르고 유연한 애자일 개발 프로세스를 진행하고 있습니다. 이렇게 학습, 최적화, 배포 및 통합 프로세스를 자동화하여 효율성을 향상시키고 있으며(CI/CD), MLOps 및 DataOps를 통한 신속한 개선이 가능한 개발 환경을 갖추고 있습니다. 2.2 Safety-Designed Vehicle 최근 차량 외부와의 연결로 안전성, 해킹 및 개인정보 노출 위협 요소가 커지고 있습니다. SDV의 사이버 보안은 운전자와 교통안전을 보장하는데 결정적인 역할을 하고 있습니다. 42dot은 하드웨어와 소프트웨어의 모든 부분에서 안전을 최우선 가치로 두고 통합된 SDV 보안 솔루션을 개발하고 있습니다. 카메라 비전과 운행 정보를 기반으로 한 AI 알고리즘은 차량의 경로를 예측하고 장애물과의 잠재적 충돌에 대비하여 경고합니다. 이 데이터들은 클라우드로 전송되어 다른 차량들과 공유되어 안전 운전을 지원합니다. 2.3 LLM for Advanced Mobility LLM (large language models)은 복잡한 언어 구조를 학습하여, 우리가 이동하는 방식을 획기적으로 변화시킬 수 있습니다. 대부분의 차량 AI assistant는 싱글 턴(single-turn) 방법으로 응답을 제공하지만, 방대한 데이터에서 훈련된 42dot의 LLM 기반 AI assistant는 사람의 상호 작용을 모방하는 연속적인 대화가 가능합니다. 42dot의 AI assistant는 다양한 인포테인먼트 앱은 물론, AI 내비게이션, 자율주행, IFS (intelligent fleet safety) 등 connected service까지 무한한 적용 범위를 가지고 있습니다. 또한 운전자의 습관과 라이프스타일을 기반으로 맞춤형 서비스를 제공할 수도 있으며, 텍스트나 소리를 통해 중요한 정보를 제공하여 효율적인 차량 관리가 가능합니다. 2.4 Self-Managed Smart City SDV 기술은 fleet과 도시에도 적용되어 관련 비즈니스와 교통 인프라를 최적화할 수 있습니다. 42dot은 사용자 중심의 자율주행 기술과 알고리즘을 통해 실시간 데이터를 기반으로 최적의 라우팅을 제공합니다. 또한 클라우드를 통해 관리되는 도로 데이터는 모든 SDV 차량과 공유되어 최적의 이동이 가능합니다. 차량, 운전자, 도로 데이터와 실시간 교통 정보는 중앙화된 FMS (fleet management system)를 통해 디지털화되어 관리되고, 차량 사고 발생 시, AI 기반 사고 알림 및 보고 시스템으로 처리됩니다. 42dot의 시스템은 자동으로 관계자들에게 사고 사실을 알리고 운영에 필요한 리포트를 작성합니다. 동영상을 포함한 모든 운전자, 차량 및 교통 데이터는 블록체인 기술로 관리되고 보호됩니다. 이러한 기술로 "software-defined everything"을 통해 차량을 넘어 도시의 모든 이동이 스스로 관리될 수 있습니다. 2.5 Autonomous Mobility Platform TAP! 42dot의 ‘TAP!’은 서울시의 자율주행 플랫폼으로서 자율주행 상용화를 이끌고 있습니다. 42dot의 자율주행차 외에도, 다양한 업체가 서비스를 쉽게 운영할 수 있도록 자율주행 플랫폼을 제공하고 있으며, 서울시 상암동을 시작으로 7개 지역에서 자율주행 서비스를 운영하고 있습니다. 승객들은 TAP! 앱을 통해 다양한 차량을 호출하여 안전하고 편안한 자율주행 경험을 할 수 있습니다. 지금까지 CES 2024에서 공개한 소프트웨어 중심의 SDV (software-defined vehicle) 기술을 소개했습니다. 42dot은 지속적으로 업데이트되는 스마트폰 같은 차량을 만들기 위해 소프트웨어 회사의 개발 방식을 차량에 적용하며 ‘개발 방식의 대전환’도 이끌고 있습니다. 42dot과 함께 software-defined everything 전략을 실현할 engineering, product, business 전문가라면, 지금 바로 채용 공고를 확인해 보세요. *링크: https://www.42dot.ai/ko/careers/open-roles BMX (Brand Marketing eXperience)팀 42dot의 브랜드 마케팅을 담당하고 있습니다.

42dot에서는 모빌리티 사용자에게 새로운 유형의 모틸리티 경험을 제공하기 위한 블록체인 플랫폼을 개발하고 있습니다. 영지식 증명은 42dot이 생각하고 있는 블록체인의 중요한 기술적인 기반 중 하나 입니다. 이에 영지식 기술이 무엇이고 그것이 어떻게 동작하는지 그리고 42dot의 블록체인에 영지식 증명 기술이 어떻게 사용되고 나아가서는 SDV와 모빌리티 서비스에 어떻게 적용될 수 있는지 간단히 이야기 하려고 합니다. 1. 영지식 증명이란? 영지식 증명(Zero-knowledge proof, ZKP)은 증명자(prover)가 검증자(verifier)에게 자신의 주장(statement)이 사실임을 증명하는데 사용되는 암호화 기술이라고 할 수 있으며, 증명자는 자신의 주장을 증명하기 위해서 검증자에게 자신의 주장에 관한 어떤 정보도 제공(유출)하지 않으며, 검증자는 증명자의 주장에 대한 어떤 정보도 알지 못한 상태에서 검증을 수행하게 수행하게 됩니다. 예를 들어, A는 B에게 자신이 천만원이 있다고 증명하고 싶다고 가정해 보겠습니다. 가장 쉬운 방법은 A가 B에게 천만원이라는 돈을 실제로 보여주거나, 자신의 통장 잔고 증명서를 보여주는 것입니다. 하지만 이는 영지식 증명이 아닙니다. A의 주장을 뒷받침하는 명확한 정보를 B에게 전달하기 때문입니다. 영지식 증명에서 A는 자신이 가지고 있는 돈과 관련된 정보를 전혀 제공하지 않은 상태에서 증명을 할 수 있어야 하고, B 또한 A가 가지고 있는 돈과 관련된 어떤 정보도 없이 A의 주장이 사실인지 검증할 수 있어야 합니다. 또 다른 예를 들면, A는 편의점에서 담배나 술을 사려고 합니다. 편의점 판매원 B는 A가 성인인지 의심스럽다면 A가 성인인지 여부를 확인해야 합니다. 일반적으로 B는 A에게 주민등록증과 같은 신분증을 요구하게 됩니다.즉, B는 신분증을 보고 A가 담배나 술을 살 수 있는 권한이 있는지 확인하는 것입니다. 이때, A는 신분증을 보여주지 않고 자신이 성인인지를 증명할 수는 없을까요? 이와 같은 경우에 영지식 증명을 사용한다면 A는 신분증을 보여주지 않고 자신이 성인이라는 것을 증명할 수 있습니다. 블록체인에 대한 예를 들면, A가 B에게 가상 자산을 보내려고 합니다. 가상 자산이 전달되는 트랜잭션에 영지식 증명을 적용한다면 가상 자산을 송신하는 A와 그것을 수신하는 B의 프라이버시를 보호하면서 트랜잭션이 정당하다는 것을 증명할 수 있습니다. 이처럼 영지식 증명에서는 증명자가 자신의 주장과 관련된 정보 노출을 배제시키면서 자신의 주장을 증명할 수 있기 때문에 사용자의 프라이버시가 중요한 부분에 사용될 수 있습니다. 영지식 증명이 무엇이고 어떻게 가능한지를 설명할 때 가장 흔하게 볼 수 있는 예가 알리바바의 동굴(Ali Baba cave) 문제입니다. 즉, 앨리스(Alice)와 밥(Bob)이 있을때, 밥은 자신이 동굴 안에 있는 문을 열 수 있는 열쇠가 있다는 것을 증명하고 싶습니다. 증명 과정은 다음과 같은 과정으로 진행됩니다. 이때 중요한 부분은, 밥은 자신이 열쇠가 있다는 사실을 증명하기 위해서 앨리스에게 열쇠를 보여 주지 않고 증명 과정이 수행된다는 것입니다. 1.1 영지식 증명의 구성 요소 영지식 증명(이후 부터는 ZKP와 혼용해서 사용)은 다음과 같은 세 가지 구성 요소로 이루어집니다. • 증명자(prover) : 자신의 주장이나 진술을 증명하고자 하는 주체 • 검증자(verifier) : 증명자의 주장이나 진술이 맞는지 검증하는 주체 • 주장 또는 진술(statement) : 증명자가 검증자에게 증명하고자하는 내용 1.2 영지식 증명은 어떤 경우에 사용할 수 있을까? 영지식 증명은 다양한 경우에 사용될 수 있으며, 적용할 수 있는 몇 가지 예를 들면 다음과 같습니다. • 인증(로그인) : 어떤 사이트나 시스템에 대한 인증(로그인)이 필요할때 인증 정보(패스워드)를 입력하지 않고 해당 인증 정보(패스워드)를 소유하고 있다는 것을 증명함으로써 인증을 수행할 수 있습니다. • 온라인 투표 : 영지식 증명은 온라인 비밀 투표에서 사용할 수 있습니다.(영지식 증명을 이용한 블록체인 기반의 온라인 비밀 투표 시스템인 zkVoting인 CES 2023에서 기술 혁신상을 수상하기도 하였습니다.) • 자격 증명 : 영지식 증명을 통해서 어떤 정보도 노출하지 않고 단지 자격이 있는지를 검증할 수 있습니다. • 블록체인 : 블록체인의 트랜잭션 데이터에 영지식 증명을 적용하면 트랜잭션에 포함되는 민감 정보를 은닉(hiding)시킬 수 있습니다. 즉, 프라이버시를 위해서 거래(트랜잭션)의 익명성을 제공(shielded/confidential transaction)할 수 있고 블록체인에 저장되는 데이터의 용량을 줄일 수 있습니다. 또한, 블록체인의 scalability 향상을 위한 목적으로 많이 사용(zk-rollup)되고 있습니다. • 데이터 프라이버시 : 사용자의 민감 정보(개인 정보, 금융 정보 등)를 노출하지 않고 증명할 수 있는 용도로 사용될 수 있습니다. • 지식에 대한 증명 : 어떤 문제의 답을 알고 있다고 증명하거나, 어떤 정보를 알고 있거나 어떤 데이터를 가지고 있다고 증명하는데 사용될 수 있습니다. 2. 영지식 증명이 이루어지는 과정 영지식 증명은 다음과 같은 함수 f가 있을때, 증명자는 함수의 결과를 true로 만드는 입력 값을 가지고 있다는 것을 증명하는 것이고 검증자는 증명자의 입력 값에 의해서 만들어지는 함수의 결과가 true인지 false인지 판단하는 것이라고 정의할 수 있습니다. f(x, w) = true/false 함수 f에 입력되는 x는 public input이고 w는 private입니다. 이해를 돕기 위해서, 증명자는 자신의 은행 잔고가 1000원 보다 많다(사실, 증명자의 은행 잔고는 2000원 입니다)는 사실을 자신의 은행 잔고를 노출시키지 않고 검증자에게 증명하고 싶다고 가정해 보겠습니다. 이를 함수 f로 표현하면, f(1000,2000) = true 이때, 1000은 public input인 x가 되고, 2000은 private input인 w가 됩니다. 2000은 검증자에게 노출되어서는 안되는 입력 값이기 때문에 private input이라고 부르며 또 다른 용어로는 witness라고도 합니다. 결국, 증명자는 x가 주어졌을 때 함수 f의 결과를 true로 만드는 w를 알고 있다는 것을 증명하는 과정이라고 할 수 있습니다. 함수 f를 프로그래밍 코드로 표현하면 다음과 같습니다. function f(x, w) { return (x < w); } 영지식 증명 과정을 논리적인 관점에서 보면 크게 3 단계로 이루어집니다. 2.1 1단계 : 키 생성 단계 키 생성(key generation)은 다음과 같이 정의된 함수 G에 의해서 수행된다고 정의할 수 있습니다. G(f, λ) = (pk, vk) f : program code / circuit λ : random secret parameter pk : proving key vk : verification key 함수 G는 검증자가 수행하며, 함수 G의 결과로 만들어진 pk는 증명자에게 공유해줍니다. 기본적으로 키 생성은 주어진 f에 대해서 한번만 수행되어야 합니다. 2.2 2단계 : 증명 데이터 생성 단계 증명 데이터(proof) 생성은 다음과 같이 정의된 함수 P에 의해서 수행된다고 정의할 수 있습니다. P(pk, x, w) = proof pk : proving key x : public input w : private input (witness) proof : proof data 함수 P는 증명자가 수행하며, 키 생성 단계에서 만들어진 pk와 x, w를 이용해서 증명 데이터(proof)를 생성합니다. 그리고 함수 P의 결과로 만들어진 증명 데이터는 검증자에게 전달됩니다. 2.3 3단계 : 검증 단계 증명 데이터(proof)를 검증하는 것은 다음과 같이 정의된 함수 V에 의해서 수행된다고 정의할 수 있습니다. V(vk, x, proof) = true/false vk : verification key x : public input proof : proof data 함수 V는 검증자가 수행하며, 증명자가 전달한 증명 데이터(proof)를 이용해서 함수 V의 결과가 true인지 false인지 확인하는 것입니다. 즉, 검증자는 증명자만 알고 있는 w를 모른 상태에서 검증을 수행하는 것입니다. 만일, 결과가 true라면 f(x,w)의 결과가 true라는 의미가 되고 검증자는 증명자의 주장이 맞다고 확신할 수 있습니다. 3. zk-SNARK zk-SNARK는 “ zero-knowledge Succinct Non-Interactive Argument of Knowledge”의 약자이며, 이름에서 유추할 수 있듯이 non-interactive ZKP이며 증명 데이터가 간결(succinct)한 것이 특징이며 가장 많이 사용되는 Scheme입니다. zk-SNARK가 구체적으로 어떻게 수행되는지에 대해서는 링크 의 페이지에서 자세히 설명하였으며 해당 페이지를 참고하길 바랍니다. 4. 42dot의 영지식 증명과 블록체인 그리고 SDV, 모빌리티 42dot에서는 블록체인 뿐만 아니라 SDV(software-defined vehicle)와 모빌리티 서비스에 영지식 증명 기술을 적용하여 인증, 자격 증명, 데이터 프라이버시, 지식에 대한 증명을 제공할 예정입니다. 즉, 다음과 같은 영역에 영지식 증명 기술을 적용할 수 있습니다. 4.1 인증 (authentication) • 블록체인이나 클라우드 서비스에 대한 자동차 자체 또는 모빌리티 서비스 사용자의 인증을 영지식 증명을 이용하여 제공할 수 있습니다. • 자동차 내부의 ECU 간의 상호 인증에 적용할 수 있습니다. • SDV OS와 상호 작용하는 SDV app간의 인증에도 적용할 수 있습니다. 4.2 자격 증명 (authorization) • 영지식 증명을 통해서 자동차/모빌리티 서비스 사용자의 민감한 정보의 노출없이 자격의 유무를 검증할 수 있는 기능을 제공합니다. • DID의 VC/VP 안에 있는 proof data를 영지식 증명 데이터로 대체하여 정보 노출없이 검증 가능하도록 만들 수 있습니다. • 사용자가 FoD의 특정 기능을 영지식 증명을 이용하여 구독 여부를 검증할 수 있습니다. 4.3 익명성 (anonymity) 사이트나 시스템에 대한 로그인이 필요할때 인증 정보(패스워드)를 입력하지 않고 해당 인증 정보(패스워드)를 소유하고 있다는 것을 증명함으로써 익명으로 로그인 (즉, 익명으로 서비스를 이용)을 수행할 수 있는 기능을 제공합니다. 4.4 데이터 프라이버시 개인 정보 보호 강화를 위해서 사용자의 민감 정보(개인 정보, 금융 정보 등)를 노출하지 않고 해당 정보의 내용을 증명할 수 있는 기능을 제공합니다. 4.5 지식에 대한 증명 어떤 정보를 알고 있거나 어떤 데이터를 가지고 있다고 증명하여 신뢰할 수 있는 데이터 공유 주체인지 판단할 수 있는 기능을 제공합니다. 이와 같은 기능들은 민감한 데이터에 대한 privacy-preserving과 네트워크, 서비스에 대한 authentication/verification, anonymity를 제공하게 될 것입니다. 따라서, 영지식 증명은 42dot이 추구하는 새로운 유형의 모빌리티 서비스 경험을 가능하게 만들기 위한 중요한 요소 기술이라고 할 수 있습니다. 윤근용 | Blockchain Platform (Tech Lead) 새로운 유형의 모빌리티 경험을 제공하기 위한 블록체인 플랫폼을 개발하고 있습니다.

42dot Inc. has presented the solution referred to as MiLO which won the 2nd place (honorable runner-up) in the fiercely contested 3D Occupancy Prediction Challenge for autonomous driving at the Computer Vision and Pattern Recognition Conference (CVPR) 2023; in Vancouver, Canada. This is the first worldwide competition for occupancy prediction, yet being one the most competitive tracks, with almost 150 participating teams from 10 regions. Notably, 42dot's solution does not require access to external data or very large-scale models (models with millions of parameters). 3D occupancy prediction is promising for safe and robust autonomous driving systems. 3D occupancy prediction divides the 3D scenes into a grid of 3D voxels and then estimates voxel occupancy states which are occupied, free, and unobserved. The occupied voxels are further categorized with semantic predictions (such as car, pedestrian, bicycle, etc). Occupancy Prediction addresses the limitations of the conventional object detection approach in two important aspects. First, object detection assign objects of interest with bounding boxes that do not capture the geometric details of the objects. Second, object detectors typically detect objects of interest and ignore uncommon categories. For example, object detectors for car detection will ignore a kangaroo on the street, which is a serious problem in practice. 3D occupancy prediction preserves 3D geometric information and takes the uncommon categories into consideration via occupied/free states. In CVPR 2023 occupancy prediction challenge, team 42dot focuses on optimizing the AI model with constraint data and resources. The proposed method is referred to as Multi-task Learning with Localization Ambiguity Suppression for Occupancy Prediction (MiLO). The method is unique in two important points. First, varying-depth multi-task learning is proposed for task synergy and easing deep network training. Second, localization ambiguity suppression is proposed to adaptively filter out low-confident prediction based on object class and distance. The final model also consists of different techniques for performance improvement and achieves 52.45 points on the challenge leaderboard without external data or large-scale models. MiLO is expected to provide additional insight for accurate 3D occupancy prediction for safe and robust autonomous driving. For more information, check out the technical report and presentation video as below. https://opendrivelab.com/e2ead/AD23Challenge/Track_3_42dot.pdf https://www.youtube.com/watch?v=HyTojp5bSxA Thang Vu | AD algorithm I am in charge of developing perception models from 2D/3D data for autonomous vehicles.

2023 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP 2023)에서 발표 예정인 박진석, 김형용, 박지환, 김병열, 최석재, 임윤규 저자의 “Joint unsupervised and supervised learning for context-aware language identification” 논문을 소개합니다. ICASSP는 음향, 음성 및 신호 처리 분야의 top-tier 국제 학회로 음성 신호처리 분야의 연구자들이 최신 기술과 연구 결과를 공유하고 있습니다. Conference • The 48th IEEE International Conference on Acoustics, Speech, & Signal Processing (ICASSP) will be held in Rhodes Island, Greece, from June 4 to June 10, 2023, at the Rodos Palace Luxury Convention Center ( https://2023.ieeeicassp.org/ ). • The paper “Joint unsupervised and supervised learning for context-aware language identification” written by Jinseok Park, Hyung Yong Kim, Jihwan Park, Byeong-Yeol Kim, Shukjae Choi, Yunkyu Lim, has been accepted by the ICASSP 2023. • Click the link below for details. https://arxiv.org/abs/2303.16511 Publication • Title: Joint unsupervised and supervised learning for context-aware language identification • Authors: Jinseok Park, Hyung Yong Kim, Jihwan Park, Byeong-Yeol Kim, Shukjae Choi, Yunkyu Lim • Abstract: Language identification (LID) recognizes the language of a spoken utterance automatically. According to recent studies, LID models trained with an automatic speech recognition (ASR) task perform better than those trained with a LID task only. However, we need additional text labels to train the model to recognize speech, and acquiring the text labels is a cost high. In order to overcome this problem, we propose context-aware language identification using a combination of unsupervised and supervised learning without any text labels. The proposed method learns the context of speech through masked language modeling (MLM) loss and simultaneously trains to determine the language of the utterance with supervised learning loss. The proposed joint learning was found to reduce the error rate by 15.6% compared to the same structure model trained by supervised-only learning on a subset of the VoxLingua107 dataset consisting of sub-three-second utterances in 11 languages. Jinseok Park | Speech I’m in charge of developing multilingual speech recognition models for conversational Intelligence.

AWS Cloud Development Kit(이하 AWS CDK)는 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 정의할 수 있는 오픈 소스 소프트웨어 개발 프레임워크 ( CDK official page )입니다. 이러한 코드를 통해 인프라를 관리하는 방식을 Infrastructure as Code, 줄여서 IaC라고 부릅니다. CDK는 작성된 코드를 모두 CloudFormation 템플릿으로 변환하여 리소스들을 생성합니다. 비슷한 툴 중 가장 보편적으로 쓰이는 것은 테라폼입니다. 테라폼은 HCL(HashiCorp Configuration Language)이라는 언어를 사용하여 다른 IaC 툴에 비해 진입 장벽이 조금 높습니다. 이에 반해 CDK는 AWS에서 제공하는 공식적인 IaC 툴이며 널리 쓰이는 다양한 언어로 IaC를 가능하게 한다는 장점이 있습니다. AWS에서 처음으로 IaC를 구현하고자 하는 분들 중 terraform에 대한 사용경험이 없다면 AWS가 제공하는 CDK가 좋은 선택지가 될 것입니다. 1. AWS IoT Core AWS IoT Core는 IoT 디바이스들을 연결 및 관리하고, 다른 AWS 서비스들과 연동이 가능한 AWS의 IoT 서비스입니다. AWS는 IoT Device SDK( SDK official page )를 제공하며, 이를 기반으로 개발된 디바이스는 IoT Core를 쉽게 사용할 수 있도록 해 줍니다. IoT Core는 디바이스와의 통신을 담당하여 문자 그대로 AWS IoT 서비스에서 중심 역할을 합니다. IoT Core는 메시지 라우팅을 통해 S3 같은 저장소, MSK 등과 같은 데이터 파이프라인과 함께 사용될 수 있도록 합니다. 이와 더불어 Greengrass , FleetWise , SiteWise 와 같은 서비스들을 활용하여 IoT 디바이스 운영 및 관리의 효율성을 높이는 방법도 있습니다. 이번 포스팅에서는 CDK를 활용해 AWS IoT Core를 활용한 간단한 시스템 인프라를 구성해 보고자 합니다. 2. 간단한 CDK 사용법 2.1 CDK 설치 설치 방법에 대해서는 AWS CDK 설치하기 를 참조하시기 바랍니다. 터미널에서 npm을 통해 cdk를 설치합니다. npm install -g aws-cdk 설치 후에는 다음의 명령어를 통해 설치 여부와 버전을 확인 가능합니다. cdk --version 2.2 CDK 프로젝트 시작하기 CDK 코드를 작성할 빈 디렉터리를 하나 만들고, 터미널에서 다음 명령어를 통해 CDK 프로젝트를 시작합니다. CDK는 TypeScript(JavaScript), Python, Go, .NET 등 여러 가지 언어를 지원합니다. 본 포스팅에서는 TypeScript를 이용해 CDK 코드를 구현해 보겠습니다. mkdir cdk-test-project && cd cdk-test-project cdk init --language typescript Root directory 내에 초기화된 코드 트리가 생깁니다. cdk-test-project ├── README.md ├── bin │ └── cdk-test-project.ts ├── cdk.json ├── jest.config.js ├── lib │ └── cdk-test-project-stack.ts ├── node_modules ├── package-lock.json ├── package.json ├── test └── tsconfig.json Shell 여기서 저희가 주로 작업해야 할 코드는 /bin/cdk-test-project.ts, /lib/cdk-test-project-stack 입니다. cdk init 명령어를 통해 프로젝트가 초기화 되면, /lib/cdk-test-project-stack.ts라는 샘플 코드를 자동으로 생성합니다. stack 은 리소스들의 모음을 뜻하는 오브젝트이며, stack 내부에 원하는 리소스들을 정의할 수 있습니다. 이렇게 정의된 stack은 /bin/cdk-test-project.ts 에서 app으로 패키징 되어 배포가 가능하도록 구조가 구성되어 있습니다. 만일, stack을 여러 개 정의할 경우, /lib 디렉터리 하위에 다른 stack을 정의하고, stack을 /bin/cdk-test-project.ts 코드에서 app에 추가하면 됩니다. 2.3 CDK 프로젝트 AWS와 연결하기 로컬에서 작업한 코드와 AWS 클라우드 환경을 연결해 주려면, bootstrap이라는 과정을 거쳐야 합니다. AWS 계정 번호와 region 정보를 넣어 다음의 명령어를 구성합니다. cdk bootstrap aws://ACCOUNT-NUMBER/REGION 2.4 CDK 프로젝트 배포하기 코드 작성이 끝나면 터미널 프로젝트 디렉터리에서 cdk synth 명령어를 통해 AWS CloudFormation template으로 구성해 볼 수 있습니다. 해당 명령어의 실행 결과는 root 디렉토리에 cdk.out 디렉토리가 생성되며 결과들이 저장됩니다. cdk synth cdk diff 명령어를 통해 기존에 배포된 내역과 현재 코드에 의해 정의된 리소스를 비교할 수 있습니다. cdk diff cdk deploy 명령어는 구성된 리소스 코드들을 AWS CloudFormation에 배포하고, 순차적으로 리소스들을 생성합니다. 이때, Stack 하나 혹은 전부를 배포할 수도 있습니다. cdk deploy # stack이 하나 일경우 cdk deploy STACK_NAME # 여러개의 stack 중 특정 stack 하나만 배포 할경우 cdk deploy --all # 여러개의 stack 을 모두 배포할 경우 IoT 시스템 및 시나리오 1. IoT 시스템 아키텍쳐 본 포스팅을 위해서 간단한 간단한 IoT system을 구성해 보았습니다. 차량이 상태 관련 데이터를 서버로 보내고, 이 데이터를 S3에 저장하는 시나리오입니다. 좀 더 기술적으로 시나리오를 기술해 보면 다음과 같습니다. 차량에 장착된 Device는 mqtt 프로토콜을 이용해 IoT core 서버로 차량 데이터를 송신합니다. 메시지를 수신한 IoT Core 서버는 수신한 메시지를 Basic Ingest 기능을 통해 S3 bucket에 저장합니다. Basic ingest는 AWS IoT core가 제공하는 Message routing 기능으로, 메시징 비용 없이 편리하게 다른 S3 서비스로의 전송을 가능하게 해줍니다. 구성하고자 하는 시스템에서 사용할 서비스는 표면적으로는 AWS IoT Core 와 S3 두 가지입니다. 그러나 두 가지 서비스의 사용을 위한 프로비저닝은 이보다는 조금 더 복잡합니다. 2. 디바이스 프로비저닝 2.1 시나리오에 따른 디바이스 프로비저닝 AWS 설명서 에는 다음과 같은 세 가지 시나리오에서의 디바이스 프로비저닝을 설명하고 있습니다. 인증서를 전달하기 전에 IoT 디바이스에 설치할 수 있습니다 첫 번째 방법은 가장 간편한 방법으로 이 방법은 디바이스의 제조사가 사용자와 사용 시점을 특정할 수 있을 때 활용 가능합니다. 디바이스 제조사가 사용자를 특정할 수 있기 때문에 디바이스에 최종적으로 사용할 인증서(PC, Permanent Certificate)를 저장하여 출고하는 것이 가능합니다. 이 방법은 세부적으로 Bulk regislation, JITR(Just In Time Regislation), JITP(Just In Time Provisioninig) 등의 방법이 있습니다. 최종 사용자 또는 설치 관리자는 앱을 사용하여 IoT 디바이스에 인증서를 설치할 수 있습니다. 두 번째 방법은 디바이스 제조사가 디바이스를 관리자를 특정 및 신뢰 할 수 있고, 이 관리자가 최종적으로 PC를 발급해 줄 수 있는 시나리오에서 가능한 방법입니다. 최종 사용자는 앱을 사용하여 IoT 디바이스에 인증서를 설치할 수 없습니다. 마지막 방법은 디바이스 제조사가 관리자와 최종 사용자, 사용 시점을 파악할 수 없고, 최종 사용자가 디바이스 사용을 시작할 때 디바이스가 스스로 PC를 발급받아야 할 경우에 사용하는 방법입니다. 이번 포스팅에서는 마지막 시나리오일 경우 사용하는 방법인 클레임에 의한 프로비저닝 방법을 사용하려고 합니다. 이는 사용자를 특정하기 어려운 B2C 상품에서 주로 사용하게 되는 방법입니다. 다시 말해, 수많은 불특정 다수가 사용할 디바이스이지만 관리 주체가 서비스 제공 업체일 경우 매우 유용하다는 장점이 있습니다. 이번 포스팅에서는 이에 더해 사전 프로비저닝 훅 과 lambda를 통해 디바이스를 검증하는 방법도 구현해 보겠습니다. 2.2 클레임에 의한 프로비저닝 클레임에 의한 프로비저닝 은 다음과 같은 과정을 거칩니다. 2.2.1 Before operation 1) 디바이스는 내부에 클레임 인증서(Claim Certificate, 이하 CC)를 저장하여 출고 2) 디바이스는 최초 사용 시 CC를 기반으로 AWS IoT Core를 통해 접속 3) CC를 이용한 접속이 완료되면 IoT Core는 최종적으로 사용할 영구 인증서(Permanent Certificate, 이하 PC)를 생성 4) IoT Core는 최종적으로 PC 와 키를 전달하고, 디바이스는 이를 저장 5) 디바이스는 AWS IoT Thing으로 등록 요청 6) AWS IoT는 사전 프로비저닝 훅으로 AWS Lambda Function을 call 7) Lambda는 단말의 유효성을 검증하기 위해 필요한 정보를 조회하여 IoT Core의 프로비저닝 서비스에 조회 성공 여부 전달 8) 조회에 성공할 경우 프로비저닝 서비스는 프로비저닝 템플릿에 정의된 대로 클라우드 리소스를 생성 9) 디바이스는 클레임 인증서를 이용한 접속을 해제하고, 새 인증서로 AWS IoT core에 접속→operation 시작 2.2.2 Operation 1) AWS IoT Thing으로 등록된 디바이스는 AWS IoT core에 메시지를 전달 2) AWS IoT Core는 수신한 메시지를 Rule engine을 통해 S3에 저장 위와 같은 절차를 순서도로 그려보면 다음과 같이 도식화할 수 있습니다. 시스템 구축에 필요한 인프라 리소스 이제 시스템 구축에 필요한 인프라 리소스를 정의해 보겠습니다. 필요한 인프라 리소스 Stack을 성격에 따라 크게 세 부분으로 나누었습니다. Provisioning template과 pre-provisioning hook Stack 이름 : AwsIotCoreProvisioningInfraStack 첫 번째로 구현해야 할 것은 클레임 인증서를 가지고 있는 AWS IoT Thing의 등록과 영구 인증서 발급, 이에 따르는 프로비저닝 서비스를 위한 템플릿 구현입니다. Claim certificate의 생성 및 저장 Stack 이름: AwsIotCoreProvisioningInfraStack 두 번째로 구현해야 할 것은 클레임 인증서의 발급과 저장입니다. 이렇게 생성된 인증서는 디바이스 펌웨어에 함께 저장되어 출고되고, 최초 사용 시 영구 인증서 발급과 프로비저닝을 요청합니다. Claim certificate의 생성과 저장은 Provisioning template에 의존하기 때문에 AwsIotCoreProvisioningInfraStack 안에서 같이 구현해 보겠습니다. Rule engine을 통한 메시지의 S3 저장 Stack 이름: AwsIotCoreRuleInfraStack 마지막으로는 운영에 들어간 디바이스에서 보고한 메세지의 전달과 저장입니다. 이 과정에서는 AWS IoT Core의 Rule engine을 사용하게 되며, Basic ingest을 통해 AWS의 저장소 서비스인 S3에 메시지들을 저장하게 됩니다. ( AWS 개발자 안내서 ) 1. 코드와 함께 구현하기 - 들어가기 전에 1.1 json 개발 패턴 필요한 모든 정책과 템플릿의 json 문서들은 AWS 공식 설명서( 클레임에 의한 프로비저닝 ) 기본으로 작성되었으며, 적절한 환경 변수를 코드 내에서 json 문서를 업데이트하는 방식으로 작업하였습니다. 왜냐하면 CDK 코드는 앞서 선언된 리소스의 property 들이 뒤에서 사용되는 경우가 잦은데, hard-coded json 문서를 사용할 경우 변경 시 업데이트가 누락되는 경우가 있기 때문입니다. json 문서의 업데이트 코드 때문에 다소 코드가 복잡해지나, json 업데이트 패턴이 궁극적으로는 코드의 오류를 줄일 수 있습니다. 1.2 Config 설정 Config/config.ts 에 적절히 Config를 설정합니다. 여기서 s3BucketName 은 목적에 따라 네이밍 하되, 유일해야 합니다. 이번 포스팅에서는 cdk-s3-test-bucket 라는 이름을 사용하겠습니다. const Config = { aws: { account: YOUR_ACCOUNT_HERE, region: YOUR_REGION_HERE, }, app: { service: 'cdk-test', application: 'iot', environment: 'dev' }, s3BucketName : "cdk-s3-test-bucket" }; export { Config }; 1.3 Initiation 된 Stack 과 App cdk init 명령어를 통해 초기화된 디렉토리에서 저희가 주로 다루게 될 코드는 다음의 두가지 파일입니다. bin/cdk-test-project.ts → Stack 들을 묶어 cdk app으로 만듭니다. lib/cdk-test-project-stack.ts → 각각의 stack 구성합니다. cdk init 명령어를 통해 초기화된 코드의 기본적인 Stack 이름은 cdkTestProjectStack 입니다. 이번 포스팅에서는 AwsIotCoreProvisioningInfraStack 를 구성한 뒤, 추가적으로 AwsIotCoreRuleInfraStack 을 생성하여 두 개의 stack을 만들어 배포할 예정입니다. 먼저 기능적인 구별이 가능하도록 예제 stack의 이름을 바꿔보겠습니다. 나머지 주석 부분은 CDK 가 기본적으로 제공하는 예제 코드로, 참고를 위해 그대로 두도록 하겠습니다. 변경 내용 CdkTestProjectStack → AwsIotCoreProvisioningInfraStack 또한 헛갈리지 않도록 리소스 id (AwsIotCoreProvisioningInfraStack 의 두 번째 입력값) 도 바꾸어 줍니다. 변경된 코드 lib/cdk-test-project-stack.ts import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; // import * as sqs from 'aws-cdk-lib/aws-sqs'; export class AwsIotCoreProvisioningInfraStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // The code that defines your stack goes here // example resource // const queue = new sqs.Queue(this, 'CdkTestProjectQueue', { // visibilityTimeout: cdk.Duration.seconds(300) // }); } } /bin/cdk-test-project.ts import 'source-map-support/register'; import * as cdk from 'aws-cdk-lib'; import { CdkTestProjectStack } from '../lib/cdk-test-project-stack'; const app = new cdk.App(); new AwsIotCoreProvisioningInfraStack(app, 'AwsIotCoreProvisioningInfraStack', { /* If you don't specify 'env', this stack will be environment-agnostic. * Account/Region-dependent features and context lookups will not work, * but a single synthesized template can be deployed anywhere. */ /* Uncomment the next line to specialize this stack for the AWS Account * and Region that are implied by the current CLI configuration. */ // env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION }, /* Uncomment the next line if you know exactly what Account and Region you * want to deploy the stack to. */ // env: { account: '123456789012', region: 'us-east-1' }, /* For more information, see https://docs.aws.amazon.com/cdk/latest/guide/environments.html */ }); 이제 모든 준비가 완료되었고, cdk-test-project-stack.ts 에서 작업을 시작해 보겠습니다. 2. Provisioning template과 pre-provisioning hook 2.1 Policy for test device 영구 인증서를 발급받고 Thing 등록과 프로비저닝이 마무리된 디바이스에 대한 정책입니다. 정책 내용은 기본 AWS IoT Core 정책 변수 섹션을 기반으로 합니다. device/device-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": "*" }, { "Effect": "Allow", "Action": [ "iot:Publish", "iot:Receive", "iot:RetainPublish" ], "Resource": [""] }, { "Effect": "Allow", "Action": "iot:Subscribe", "Resource": [""] } ] } 위 정책 문서를 testDevicePolicyJson 이라는 이름으로 삽입하고, 환경 변수에 맞게 업데이트 합니다. 그리고 수정된 문서를 기반으로 aws_iot.CfnPolicy 명령어를 통해 AWS IoT 정책을 생성합니다. 이때, 주의할 것은 {Action: [iot:Publish, iot:Receive, iot:RetainPublish]} 에 해당하는 Resource와 {Action: iot:Subscribe} 에 해당하는 키워드가 topic과 topicfilter로 다르다는 점입니다. 이 정책 문서는 애플리케이션의 상황에 맞추어 수정하면 됩니다. testDevicePolicyJson.Statement[1].Resource = [ `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topic/$aws/rules/*`, `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topic/` + '${iot:ClientId}' ] testDevicePolicyJson.Statement[2].Resource = [ `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topicfilter/` + '${iot:ClientId}' ] let testDevicePolicy = new iot.CfnPolicy( this, Config.app.service + "-" + Config.app.environment + "device-policy", { policyDocument: testDevicePolicyJson, policyName: Config.app.service + "-" + Config.app.environment + "-device-policy", } ); 2.2 Role for pre-provisioning-lambda 사전 프로비저닝 훅에서 사용되는 lambda 함수의 AWS IAM Role입니다. let rolePreProvisioningLambda = new iam.Role( this, Config.app.service + "-" + Config.app.environment + "-pre-provisioning-lambda-role", { assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"), description: "AWS IAM role for pre-provisioning lambda", roleName: Config.app.service + "-" + Config.app.environment + "-pre-provisioning-lambda-role", } ); 2.3 Lambda function for verifying devices 사전 프로비저닝 훅을 통해 invoke 되는, 디바이스의 시리얼 정보를 검증하는 람다 함수입니다. 이 함수가 True를 반환하기 위해서는 디바이스의 시리얼 정보가 다른 시스템을 통해 조회 가능하거나, 다른 방법을 통해 유효함이 판정되어야 합니다. import json import logging import sys # Configure logging logger = logging.getLogger() for h in logger.handlers: logger.removeHandler(h) h = logging.StreamHandler(sys.stdout) FORMAT = "[%(asctime)s - %(levelname)s - %(filename)s:%(lineno)s - %(funcName)s - %(message)s" h.setFormatter(logging.Formatter(FORMAT)) logger.addHandler(h) logger.setLevel(logging.INFO) SERIAL_STARTSWITH = "297468" def verify_serial(serial_number): if serial_number.startswith(SERIAL_STARTSWITH): logger.info("serial_number {} verification succeeded - starts with {}".format(serial_number, SERIAL_STARTSWITH)) return True logger.error("serial_number {} verification failed - does not start with {}".format(serial_number, SERIAL_STARTSWITH)) return False def lambda_handler(event, context): response = {'allowProvisioning': False} logger.info("event: {}".format(json.dumps(event, indent=2))) if not "SerialNumber" in event["parameters"]: logger.error("SerialNumber not provided") else: serial_number = event["parameters"]["SerialNumber"] if verify_serial(serial_number): response = {'allowProvisioning': True} logger.info("response: {}".format(response)) return response lambda 함수의 리소스를 선언하기 전에. 먼저 실행할 함수를 device/verify-device-lambda.py 에 선언합니다. 위 예제 함수는 python으로 구성된 간단한 검증 함수입니다. 문제를 간단하게 만들기 위해 DB와 파일을 조회 대신 SerialNumber가 297468로 시작하는지 검증하고, 검증 결과에 따라 True/False 값을 반환하도록 구성합니다. let lambdaPreProvisioningHook = new lambda.Function( this, Config.app.service + "-" + Config.app.environment + "-pre-provisioning-hook-lambda", { code: lambda.Code.fromAsset(path.join(__dirname, "device")), handler: "lambda_function.lambda_handler", runtime: lambda.Runtime.PYTHON_3_9, role: rolePreProvisioningLambda, description: "Lambda for pre-provisioning hook", functionName: Config.app.service + "-" + Config.app.environment + "-pre-provisioning-hook-lambda", } ); lambdaPreProvisioningHook.addPermission("InvokePermission", { principal: new iam.ServicePrincipal("iot.amazonaws.com"), action: "lambda:InvokeFunction", }); AWS lambda 함수의 리소스를 선언할 때는, code 경로와 handler 경로에 유의합니다. code는 lambda.Code.fromAsset 메시지를 통해 파일로 구성된 코드를 그대로 들고 올 수 있습니다. handler는 lambda 내에서 handler: {python 파일 이름}.{실제 동작하는 함수의 이름} 과 같이 작성합니다. 마지막으로 AWS IoT service가 해당 lambda 함수를 invoke 할 수 있도록 허용합니다. 2.4 Role for provisioning template 프로비저닝 서비스의 역할입니다. 프로비저닝 서비스에 대한 역할(Role)을 생성합니다. 프로비저닝 서비스는 실제로 iot 서비스에서 동작하므로, assume의 주체는 iot.amazonaws.com로 설정합니다. let roleProvisioning = new iam.Role( this, Config.app.service + "-" + Config.app.environment + "-provisioning-template-role", { assumedBy: new iam.ServicePrincipal("iot.amazonaws.com"), description: "AWS IAM role for provisioning services", roleName: Config.app.service + "-" + Config.app.environment + "-provisioning-template-role", } ); roleProvisioning.addManagedPolicy( iam.ManagedPolicy.fromAwsManagedPolicyName( "service-role/AWSIoTThingsRegistration" ) ); 2.5 ProvisioningTemplate 프로비저닝 서비스를 정의하는 프로비저닝 템플릿입니다. 프로비저닝에서 가장 중요한 부분인 프로비저닝 템플릿을 정의해 보겠습니다. 프로비저닝 템플릿의 베이스 문서는 AWS 공식 개발자 안내서의 플릿 프로비저닝 템플릿 예 를 참고합니다. 이번 포스팅에서는 플릿 프로비저닝 시에 ThingName 패턴을 test-thing-{SerialNumber}와 같이 지정하는 템플릿을 구성합니다. 기본 템플릿에서 ThingName 섹션을 패턴과 일치하도록 다음 내용을 삽입합니다. "ThingName": { "Fn::Join": [ "", [ "test-thing-", { "Ref": "SerialNumber" } ] ] } device/provisioning-template.json { "Parameters": { "SerialNumber": { "Type": "String" }, "AWS::IoT::Certificate::Id": { "Type": "String" } }, "Resources": { "certificate": { "Properties": { "CertificateId": { "Ref": "AWS::IoT::Certificate::Id" }, "Status": "Active" }, "Type": "AWS::IoT::Certificate" }, "policy": { "Properties": { "PolicyName": "" }, "Type": "AWS::IoT::Policy" }, "thing": { "Type": "AWS::IoT::Thing", "OverrideSettings": { "AttributePayload": "MERGE", "ThingGroups": "DO_NOTHING", "ThingTypeName": "REPLACE" }, "Properties": { "AttributePayload": {}, "ThingGroups": [], "ThingName": { "Fn::Join": [ "", [ "test-thing-", { "Ref": "SerialNumber" } ] ] } } } } } 위에서 구성된 문서에 CDK 코드 내에서는 프로비저닝 서비스에 대한 정책을 연결하고, CfnProvisioningTemplate 명령어를 통해 프로비저닝 템플릿 리소스로 변환합니다. 사전 프로비저닝 훅은 CfnProvisioningTemplate 명령어 내부의 preProvisioningHook 파라미터를 통해 설정합니다. 프로비저닝 프로세스마다 매번 lambda 함수를 호출해야 하므로, preProvisioningHook` 옵션에는 간단히 payloadVersion 과 위에서 정의한 lambda의 targetArn을 파라미터로 설정합니다. testProvisioningTemplateJson.Resources.policy.Properties.PolicyName = testDevicePolicy.policyName! let testProvisioningTemplate = new iot.CfnProvisioningTemplate( this, Config.app.service + "-" + Config.app.environment + "-provision-template", { provisioningRoleArn: roleProvisioning.roleArn, templateBody: JSON.stringify(testProvisioningTemplateJson), enabled: true, preProvisioningHook: { "payloadVersion": "2020-04-01", "targetArn": lambdaPreProvisioningHook.functionArn }, description: "AWS IoT Provisioning Template", templateName: Config.app.service + "-" + Config.app.environment + "-provision-template", } ); 3. Claim Certificate와 관련된 리소스 3.1 CDK를 통해 구현되지 않는 리소스 AWS IoT Core의 경우 일반적으로 Console을 이용하여 Infra를 구축합니다. 리소스 요소가 많고, 서로 얽혀 있어 콘솔을 통해 직관적으로 구현하는 것이 가장 편하기 때문입니다. 또한 AWS IoT 가 다른 서비스에 비해 비교적 신생 서비스다 보니 CDK 공식 문서에도 설명이 충분하지 않는 아쉬움이 있습니다. 만일, 매뉴얼상의 콘솔 명령어와 CDK 명령어가 1:1로 매칭되지 않으며, 콘솔 명령어가 CDK Code 조합으로 구성되지 않을 경우에는 아래 리소스를 참고할 수 있습니다. ConstructHub AWS에서 운영하는 IaC를 위한 Hub로, AWS CDK 뿐만 아니라 Terraform 등 다양한 도구들의 construct 들을 찾을 수 있습니다. AWS custom resources CDK 에서 지원하는 custom 리소스 명령어가 좀 더 풍부한 SDK API를 활용하여 원하는 리소스를 생성 가능합니다. 이번 섹션에서는 CDK로 구현이 되지 않는 AWS IoT 인증서 생성에 대해서 AWS Custom resource를 활용해 보도록 하겠습니다. 3.2 S3 bucket 먼저, 클레임 인증서를 저장할 AWS S3 bucket 을 만듭니다. config.ts 에서 정의한 S3bucektName변수를 S3의 이름으로 사용합니다. 기존에 사용하던 bucket을 그대로 사용하려면 bucket class의 다른 method( fromBucketArn , fromBucketAttributes , fromBucketName )들을 활용하시면 됩니다. let cdkTestS3Bucket = new s3.Bucket(this, 'cdkTestS3Bucket', { blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, versioned: true, removalPolicy: RemovalPolicy.DESTROY, autoDeleteObjects: true, bucketName: `${Config.s3BucketName}` } ); 3.3 Policy for Claim Certificate 디바이스에서 영구 인증서 발급 전까지 임시로 사용하는 클레임 인증서에 대한 정책을 정의합니다. 클레임 인증서에 대한 정책도 기본적인 IoT 정책을 기반으로 합니다. (cf. device/device-policy.json) 클레임 인증서에 대한 정책 정의는 AWS 개발자 안내서의 클레임에 의한 프로비저닝 을 참고하시면 됩니다. device/cc-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["iot:Connect", "iot:RetainPublish"], "Resource": "*" }, { "Effect": "Allow", "Action": ["iot:Publish","iot:Receive", "iot:RetainPublish"], "Resource": [""] }, { "Effect": "Allow", "Action": "iot:Subscribe", "Resource": [""] } ] } 위에서 정의된 베이스 정책 문서에 필요한 내용을 업데이트하고, CfnPolicy 명령어를 통해 testDeviceClaimCertificatePolicy라는 이름의 정책을 생성합니다. 클레임 인증서를 통해 프로비저닝을 요청하기 때문에, provision과 같은 정책 정의가 필요합니다. let templateTopicCreate = `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topic/$aws/certificates/create/*` let templateTopicProvisioning = `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topic/$aws/provisioning-templates/${testProvisioningTemplate.templateName}/provision/*` testDeviceClaimCertificatePolicyJson.Statement[1].Resource = [templateTopicCreate, templateTopicProvisioning] let templateTopicFilterCreate = `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topicfilter/$aws/certificates/create/*` let templateTopicFilterProvisioning = `arn:aws:iot:${Config.aws.region}:${Config.aws.account}:topicfilter/$aws/provisioning-templates/${testProvisioningTemplate.templateName}/provision/*` testDeviceClaimCertificatePolicyJson.Statement[2].Resource = [templateTopicFilterCreate, templateTopicFilterProvisioning] let testDeviceClaimCertificatePolicy = new iot.CfnPolicy( this, Config.app.service + "-" + Config.app.environment + "-claim-certificate-policy", { policyDocument: testDeviceClaimCertificatePolicyJson, policyName: Config.app.service + "-" + Config.app.environment + "-claim-certificate-policy", } ); 3.4 Claim Certificate(CustomResource) 이제 클레임 인증서를 발급해 보겠습니다. AWS IoT Core Console에는 보안 - 인증서 탭을 통해 쉽게 인증서를 만들 수 있으나, 안타깝게도 CDK에는 콘솔 명령어와 매칭되는 명령어가 없습니다. 인증서는 Open SSL 등을 활용하여 생성하는 방법도 가능하나, IaC를 위한 통합이 어려운 점이 있습니다. 앞서 말씀드린 것처럼 AwsCustomResource를 활용하여 인증서를 생성하고, 이를 S3에 저장해 보도록 하겠습니다. AWS SDK의 CreateKeysAndCertificate API를 활용합니다. API를 호출함으로써 outputPath 에 정의되어 있는 네 가지 object certificateArn, certificatePem, keyPair.PublicKey, keyPair.PrivateKey 를 얻게 됩니다. let createKeysAndCertificateForClaimCertificate = new AwsCustomResource( this, Config.app.service + "-" + Config.app.environment + "-create-keys-and-certificate-for-claim-certificate", { onUpdate: { service: "Iot", action: "createKeysAndCertificate", parameters: {setAsActive: true}, physicalResourceId: PhysicalResourceId.fromResponse("certificateId"), outputPaths: ["certificateArn", "certificatePem", "keyPair.PublicKey", "keyPair.PrivateKey"], }, policy: AwsCustomResourcePolicy.fromSdkCalls({resources: AwsCustomResourcePolicy.ANY_RESOURCE}), } ); 3.5 Key Deployment to S3(CustomResource) s3에 object를 저장하는 과정입니다. 위 과정에서 얻은 Claim certificate object 들을 위에서 만든 S3 bucket에 저장합니다. CDK 상에서 bucket 리소스를 cdkTestS3Bucket 로 정의하였고, 이를 destinationBucket 의 claim-certificate key에 저장하도록 합니다. let keyDeploymentForDeviceClaimCertificate = new aws_s3_deployment.BucketDeployment( this, Config.app.service + "-" + Config.app.environment + "put-key-to-s3", { destinationBucket: cdkTestS3Bucket, sources: [ aws_s3_deployment.Source.data( "claim-certificate/claim.pem", createKeysAndCertificateForClaimCertificate.getResponseField( "certificatePem" ) ), aws_s3_deployment.Source.data( "claim-certificate/claim.public.key", createKeysAndCertificateForClaimCertificate.getResponseField( "keyPair.PublicKey" ) ), aws_s3_deployment.Source.data( "claim-certificate/claim.private.key", createKeysAndCertificateForClaimCertificate.getResponseField( "keyPair.PrivateKey" ) ), ], } ); 3.6 Policy attachment for claim Certificate 마지막으로, 생성한 클레임 인증서와 클레임 인증서 정책을 연결시켜 줍니다. let PolicyPrincipalAttachmentForClaimCertificate = new iot.CfnPolicyPrincipalAttachment(this, Config.app.service + "-" + Config.app.environment + "policy-principal-attachment", { policyName: testDeviceClaimCertificatePolicy.policyName!, principal: createKeysAndCertificateForClaimCertificate.getResponseField("certificateArn")}); 4. Rule engine을 통한 메세지의 S3 저장 Rule engine을 통한 메세지의 S3 저장 부분에서는 lib/aws-iot-core-rule-infra-stack.ts파일을 추가하고, 여기에 AwsIotCoreRuleInfraStack라는 이름의 Stack을 추가후 작업 진행하겠습니다. 여기서는 rulePolicyJson과 ruleKeysJson의 두가지 Json 파일을 사용할 예정입니다. 이들 파일은 미리 import 해두겠습니다. 파일 경로는 import 문에 명시되어 있습니다. import { Stack, StackProps, aws_iot as iot, aws_iam as iam, aws_s3 as s3, } from "aws-cdk-lib"; import { Construct } from "constructs"; import { Config } from "../config/config"; import rulePolicyJson from "./rule/rule-policy.json"; import ruleKeysJson from "./rule/rule-keys.json"; export class AwsIotCoreRuleInfraStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); } } 4.1 Role for rule Engine AWS IoT Core 내부 서비스 중 하나로 Rule engine 이 있습니다. Rule engine은 다른 서비스로의 메시지 전달이 가능하도록 해줍니다. 이 Rule engine을 위한 AWS IAM 역할을 만듭니다. IoT Core에서 사용할 역할로, assume 주체는 iam.ServicePrincipal(iot.amazonaws.com) 을 사용합니다. // Create role for Rule engine let roleRuleEngine = new iam.Role( this, Config.app.service + "-" + Config.app.environment + "-rule-engine-role", { assumedBy: new iam.ServicePrincipal("iot.amazonaws.com"), description: "AWS I AM role for IoT rule engine", roleName: Config.app.service + "-" + Config.app.environment + "-rule-engine-role", } ); 4.2 s3 bucket (revisited) 다음으로 S3 bucket을 불러옵니다. S3 bucket은 Claim Certificate를 저장하기 위해 AwsIotCoreProvisioningInfraStack에서 이미 생성되었습니다. 버킷을 그대로 사용하도록 하겠습니다. s3.Bucket.fromBucketName 메서드를 활용하여 bucket 이름으로부터 기존에 생성된 bucket 리소스를 불러옵니다. 여기서 ${Config.s3BucketName} 은 config/config.ts에서 정의한 대로 cdk-s3-test-bucket 입니다. // Get S3 bucket from bucket name let cdkTestS3Bucket = s3.Bucket.fromBucketName(this, "cdkTestBucket",`${Config.s3BucketName}`); 4.3 Policy for role for rule Rule engine에 필요한 역할의 정책을 정의합니다. s3 bucket으로 메시지를 저장하기 위해 s3:PutObject 권한이 필요합니다. 이 정책은 다음의 Json 문서를 기반으로 합니다. rule/rule-policy.json { "Version": "2012-10-17", "Statement": [ { "Action": "s3:PutObject", "Resource": [""], "Effect": "Allow" } ] } rule-policy.json 정의된 베이스 정책 문서에 S3 bucket 리소스를 업데이트하고, 정책을 만듭니다. 정책을 만든 뒤에는 정책을 앞서 만든 IAM 역할에 할당합니다. // Create policy and attach it to IoT Role. rulePolicyJson.Statement[0].Resource = [cdkTestS3Bucket.bucketArn + "/*"] let iotCoreRolePolicy = iam.PolicyDocument.fromJson(rulePolicyJson); new iam.Policy( this, Config.app.service + "-" + Config.app.environment + "-iot-core-role-policy", { document: iotCoreRolePolicy, policyName: "iotCoreRolePolicy", } ).attachToRole(roleRuleEngine); 4.4 Rule for pre-defined keys 이제 IoT Core rule을 만들어보겠습니다. 본 포스팅에서는 rule1, rule2, rule3 세 가지의 Rule을 만들려고 합니다. For 문을 통해 여러 개의 rule을 동시에 만들기 위해 다음의 Json 문서를 활용하겠습니다. rule/rule-keys.json { "testRules": [ "rule1", "rule2", "rule3" ] } 각각의 rule은 다음의 cdk 코드를 통해 test-rule/{key} 라는 이름으로 생성됩니다. AWS CDK 개발자 안내서 에서는 key 는 데이터가 기록되는 파일의 s3 경로로서, Timestamp 와 같이 고유한 식별자를 사용하는 것이 좋다고 안내하고 있습니다. 안내서대로 key에는 ${topic()}/${timestamp()} 를 사용하였습니다. 또한 rule einge이 조회할 sql의 구문은 각각의 토픽이 각자 맞는 key에 해당하는 데이터를 조회할 수 있도록 `SELECT * FROM 'test-rule/${key}'` 를 사용하였습니다. 이와 같은 과정을 testRules 에 나열되어 있는 룰에 대해 각각 생성하기 위해, for loop를 사용합니다. // Get rules from ruleKeysJson let testRuleKeys = ruleKeysJson.testRules; // Create Rules in IoT Core testRuleKeys.forEach((key) => { new iot.CfnTopicRule( this, Config.app.service + "-" + Config.app.environment + `-topic-rule-${key}`, { topicRulePayload: { actions: [ { s3: { roleArn: roleRuleEngine.roleArn, bucketName: `cdk-s3-test-bucket`, key: "${topic()}/${timestamp()}", }, } ], sql: `SELECT * FROM 'test-rule/${key}'`, }, // iot does not allow rule '-' (dash). ruleName: `test_rule_${key}`, } ); }); 이제 모든 과정이 완성되었습니다. IoT Device 에서 보내는 메시지를 topic-rule/${key} 토픽에 맞추어 메시지를 전송하면, AWS는 바로 S3 bucket 내의 ${topic()}/${timestamp()} 경로에 메시지를 저장하게 됩니다. 이와 같이 간단한 Rule 정의를 통해 다른 AWS 서비스로 메시지를 전달하는 기능을 Basic ingest라고 하며, 이는 AWS에서 과금되지 않습니다. log와 같이 단순 저장이 필요하거나, S3를 데이터 레이크로써 활용할 때, Basic ingest를 활용하면 과금에서 자유로운 메시지 라우팅이 가능한 장점이 있습니다. 5. 작업을 통해 구현된 cdk app의 구조 cdk init 후 이번 포스팅에서 작업한 파일들을 트리구조로 나타내보면 다음과 같습니다. cdk-test-project ├── README.md ├── bin │ └── aws-iot-infra.ts ├── cdk.json ├── config │ └── config.ts ├── jest.config.js ├── lib │ ├── aws-iot-core-provisioning-infra-stack.ts │ ├── aws-iot-core-rule-infra-stack.ts │ └── device │ │ ├── device/device-cc-policy.json │ │ ├── device/device-policy.json │ │ ├── device/provisioning-template.json │ │ └── device/verify-devices-lambda.py │ └── rule │ ├── rule/rule-keys.json │ └── rule/rule-policy.json ├── node_modules ├── package-lock.json ├── package.json ├── test ├── tsconfig.json └── yarn.lock 이번 포스팅에서는 AWS IoT Core를 기반으로 한 디바이스 데이터 수집 시스템을 구상하고, 다음과 같은 시나리오와 리소스를 구성해 보았습니다. 구성한 시나리오와 리소스를 요약하자면 다음과 같습니다. * 운영 시나리오 Device 에서 생성된 메시지를 AWS IoT Core로 전달 클레임에 의한 인증서 발급 방법으로 인증서를 발급하여 사용 디바이스 검증을 위해 사전 프로비저닝 훅을 사용 CDK 를 통해 IoT Core를 기반으로 한 서비스의 IaC를 구현함 + 디바이스를 이용해 검증 IoT Core는 Rule engine의 basic ingest 기능을 활용하여 S3에 메시지 저장 AWS CDK를 통해 생성한 리소스들 Provisioning template과 pre-provisioning hook 구현 디바이스 정책, 디바이스 검증용 람다 프로비저닝 서비스의 IAM 역할, 프로비저닝 템플릿 등 정의 Claim certificate의 생성 및 저장 S3 bucket, 클레임 인증서에 대한 정책, AwsCustomResource를 활용한 클레임 인증서 발급, 발급된 인증서의 저장, 인증서와 정책 연결 디바이스가 전달한 Message를 AWS IoT Core Rule Engine의 Basic ingestion을 통해 S3에 저장 Rule engine 역할, Rule engine 역할 정책 및 역할 연결, Rule 정의 결론 이번 포스팅에서는 AWS IoT Core system을 이용하여 디바이스 등록부터 데이터 저장까지 가능한 인프라를 AWS CDK를 이용해 구성해 보았습니다. 처음 서비스를 위한 인프라를 구축하려 할 때 EC2나 S3 등 개별 서비스 리소스의 기능들을 이해하고 나서, 리소스 생성과 관리 작업으로 넘어가게 됩니다. 이때 CDK는 AWS 가 제공하는 툴로써 가장 높은 호환성을 보장하며, AWS 아키텍처를 IaC로 구축하는데 기초적인 도구가 될 수 있습니다. IoT 서비스는 장비 운영자와 서비스 개발자가 눈으로 확인된 동작에 기반해 결정 및 변경되어야 할 사항이 많기 때문에 클라우드 인프라에서 미리 준비해 두어야 할 구성요소가 많고 변경 이력에 대해 민감한 편입니다. 이를 콘솔에서 편리하게 생성하는 것도 가능은 하겠으나, 코드를 기반으로 디테일하게 구현하며 기능을 더 엄밀하게 뜯어보고 클라우드 서비스의 구조를 살펴볼 수 있는 좋은 기회였습니다. 아쉬운 점으로는 AWS IoT Core는 AWS 서비스 내에서도 비교적 신생 서비스로, 공식적인 문서의 설명이 아직 채워지지 않은 부분이 있거나 혹은 순환 참조를 이루는 경우가 많았습니다. 이런 부분들로 인해 개발하는 데에 시행착오를 많이 겪었습니다. 또한 일부 명령어들은 Console이나 AWS CLI에서 실행되는 명령어가 CDK에는 존재하지 않는 경우도 있었습니다. 이 부분은 SDK의 기능을 CDK에서 활용할 수 있게 지원해 주는 AwsCustomResource 기능을 활용하여 이를 해결하였습니다. 이 부분을 AWS에서 개선해 주었으면 하는 바람이 있습니다. 이 포스팅을 통해 개발자 여러분들께 도움이 되기를 바랍니다. 감사합니다. 이승범 | Fleet Platform Fleet Platform 소프트웨어 및 IFS 솔루션 개발을 담당하고 있습니다. 김진형 | Fleet Platform Fleet Platform 소프트웨어 개발을 담당하고 있습니다. 알렉 지브릭 | Cloud Infrastructure 자율주행 기술 클라우드 인프라 구축 및 쿠버네티스 개발을 담당하고 있습니다. References 1) Official AWS CDK Documentation AWS CDK API reference AWS CDK Examples github 2) Blogs Managing Missing CloudFormation Support with the AWS CDK My experience on Infra as Code with AWS CDK + Tips & Tricks AWS CDK에서 Terraform으로 by 선비(sunB) IaC / 형상관리 / 이미지빌드 by hyun6ik 코드로 인프라 관리: AWS CDK by musma 기술블로그 AWS CDK 사용법 : 삐멜 소프트웨어 엔지니어 코드로 AWS 인프라 구축하기 - AWS CDK

42dot에서는 자율주행기술 개발을 위해 머신러닝 기술을 적극적으로 활용하고 있습니다. 머신러닝 개발의 경우 고도의 알고리즘, 대량의 데이터 그리고 복잡한 컴퓨팅 연산이 필요하고 이를 수행하기 위해서는 software 및 hardware의 효율적인 지원이 필요합니다. 이를 위에 42dot에서는 다양한 기술을 이용하여 machine learning&data platform을 개발하여 운영하고 있으며, 지금도 42dot의 머신러닝 개발자들이 이를 활용하여 효과적인 개발 업무를 진행하고 있습니다. Data Pipeline 머신러닝 개발에 있어서 데이터는 매우 중요합니다. 머신러닝 모델의 성능을 높이기 위해서는 많은 양의 데이터가 필요하고, 또한 많은 양의 데이터 중에서 성능 향상에 도움이 될 가능성이 높은 데이터를 골라내는 작업(data curation) 역시 중요합니다. 이러한 데이터 준비 작업의 경우 복잡성이 높고 시간이 많이 걸리는 작업입니다. 42dot에서는 자동화된 data pipeline을 개발 운영하고 있으며 머신러닝 개발자들이 데이터 관련 작업을 빠르고 효율적으로 수행할 수 있도록 지원합니다. Data pipeline은 다음과 같이 동작합니다. 1) 차량을 통해 도로에서 수집된 데이터는 각 사이트의 엣지 클러스터를 통해 클라우드와 데이터 센터로 전송됩니다. 2) 클라우드로 전송된 데이터는 검색을 위한 변환과 인덱싱 작업을 거쳐 데이터베이스에 저장됩니다. 3) 데이터 센터로 전송된 데이터는 GPU 서버를 이용하여 inference 작업을 거쳐 태그를 생성하고 data curation 작업을 위해 weakness detection pipeline을 거쳐 데이터베이스에 저장됩니다. 4) 저장된 데이터는 디버깅과 re-simulation을 통해 개발 과정에 사용되거나, data console을 통해 data curation 작업을 수행합니다. 5) 수집 데이터의 안전한 사용을 위한 개인정보 암호화, 비식별화 등의 보호 조치를 추가로 수행합니다. 6) 레이블링을 마친 데이터는 GPU 클러스터에 연결된 shared storage에 저장됩니다. 머신러닝 개발자는 Kubeflow 기반 ML workspace를 통해 접근하여 개발 작업을 진행합니다. ML Workspace 머신러닝 학습에는 많은 연산이 필요하고 일반적으로 GPU 서버를 사용하여 진행합니다. 머신러닝 개발팀의 경우 여러 대의 GPU 서버를 사용하여 개발하게 되는데, GPU 서버를 얼마나 효율적 사용하는가 또한 중요합니다. 동일한 자원일 경우 가능하면 모델 학습을 여러 사이클 돌릴수록 더 빠른 개발이 가능하기 때문입니다. 개발을 위해 필요한 각종 라이브러리 설치 등 개발 환경을 갖추는 작업 또한 필요한데요, 이러한 요구사항을 위해 42dot에서는 Kubeflow를 기반으로 한 ML workspace를 제공합니다. GPU 클러스터의 경우 여러 대의 GPU 서버를 Kubernetes 클러스터로 구성하고, 여기에 shared storage를 고속의 네트워크로 연결하여 직접 접근 가능하도록 구성하였습니다. 이렇게 구성된 클러스터에 Kubeflow 기반 시스템을 구축하여 개발자들이 쉽게 접근 가능하도록 지원하고 있습니다. 개발자들은 원하는 스펙(CPU, memory, GPU …)의 가상 서버 인스턴스를 요청하여 사용할 수 있으며 사용을 마치고 나서는 다시 반납할 수 있습니다. 할당받은 가상 서버 인스턴스의 경우 브라우저를 통해 접근 가능하며, 머신러닝 개발에 필요한 대부분의 기능을 제공하고 있어 편리하게 사용 가능합니다. ML Pipeline 머신러닝 개발 과정은 일반적으로 학습, 평가, 모델 변환, 통합 테스트, 배포 등의 과정을 반복적으로 수행하게 됩니다. 개발 속도를 높이기 위해서는 반복적으로 수행하는 작업을 최대한 자동화하여 개발자들이 개발 자체에 집중할 수 있도록 하는 것이 중요한데요, 저희 42dot에서는 다양한 기술을 활용하여 자동화를 지원하고 있습니다. 첫 번째로 MLFlow를 활용하여 training tracking과 model registry를 지원하고 있습니다. 모든 학습 과정은 클라우드에 설치된 MLFlow에 자동으로 기록되고 학습의 결과물은 model registry에 저장됩니다. 이를 통해 권한이 있는 사용자는 누구나 어떤 데이터와 어떤 파라미터를 사용한 모델이 가장 좋은 결과를 보여주는지를 손쉽게 검색 가능하며 테스트 및 배포 과정에서도 학습 결과물을 API를 통해 쉽게 접근 가능하도록 지원하고 있습니다. 두 번째로 ML pipeline입니다. model registry에 학습 결과물이 등록되면 평가, 모델 변환, 테스트를 위한 pipeline이 자동으로 수행됩니다. Kubeflow pipeline을 이용하여 수십여 개의 pipeline이 동작 중이며 하루에도 수백 번 이상 자동으로 수행되어 자율주행 기술 개발을 가속시키고 있습니다. ・ ・ ・ 지금까지 42dot 머신러닝 개발팀에서 사용하고 있는 ML data platform에 대해 소개 드렸습니다. 자율주행 기술 개발의 기나긴 여정을 조금이라도 앞당길 수 있도록 ML data platform 또한 지속적인 개발과 개선을 진행할 예정입니다. 양원렬 | Data & ML (Tech Lead) 자율주행 기술 성능 향상을 위한 Machine Learning & Data platform 개발을 담당하고 있습니다.

모든 것들이 스스로 움직이고 끊김 없이 연결된 세상을 만든다 42dot에서는 모든 것들이 스스로 움직이게 하기 위해서 자율 주행 제어 장치를 개발하고 있습니다. 이 장치는 다양한 센서(카메라, 레이더 등)를 활용해서 주변 상황을 인지/판단하고 지도/측위 기술 등을 조합해서 주행 경로에 따라 장치 스스로 조향 각과 가감속과 같은 다양한 이동 과정의 제어를 수행합니다. 자율주행 장치의 이동을 비용 효율적, 안정적으로 보장하기 위해서는 장치를 구동 시키는 운영 체제 및 애플리케이션들을 빠르고 지속적으로, 원격에서 신규 기능 적용뿐만 아니라 성능 개선, 버그 수정, 보안 패치 등의 소프트웨어 업데이트가 끊김 없이 이루어져야 가능합니다. 이것은 OTA 업데이트 기술을 통해 지속 가능하게 할 수 있습니다. OTA(Over-the-air)? Software 및 firmware를 update 하는 방식 중에 하나로, update를 하기 위해 유선으로 host machine에 연결하지 않고 무선으로 원격지의 device를 update 하는 방식입니다. OTA 방식에 따라 SOTA(Software-over-the-air)와 FOTA(Firmware-over-the-air)로 나누기도 하는데, 보통 SOTA는 다양한 software component들을 대상으로 하고 있고, FOTA는 특정 device에 국한된 update 방식으로 볼 수 있습니다. 1. OTA 업데이트 기술은 안정성과 보안이 핵심 잘못 설치되거나 네트워크 전송 오류로 인해 일부 파일 내용이 손상된 OTA 업데이트는 장치를 동작하지 않는 “벽돌"로 만들어서 이용자에게 상당한 불편을 초래할 뿐만 아니라 장치 공급자에 대한 평판 및 금전적인 손상까지 이어질 수 있습니다. 해커가 OTA 서버에 중간자 공격(man-in-the-middle attack) 통해 자율주행 제어 장치의 주요 운영체제 모듈 및 애플리케이션들의 바이너리를 확보하고 리버스 엔지니어링을 통해 악의적인 목적으로 위변조 된 소프트웨어를 해당 장치에 다시 배포할 수 있습니다. 또한 알려진 소프트웨어 보안 취약점을 악용해서 해당 장치에 원격으로 침입하여 민감한 데이터를 훔치거나 물리적인 자율 주행 이동의 제어권을 장악할 수 있습니다. 중간자 공격(Man-in-the-middle attack)? 네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법이다. 중간자 공격은 통신을 연결하는 두 사람 사이에 중간자가 침입하여, 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사람은 중간자에게 연결되어 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달합니다. 예를 들어, 위 그림처럼 해커가 클라우드에 연결된 차량의 모뎀에 가짜 기지국 연결과 같은 중간자 공격을 통해 셀룰러 통신 데이터를 가로채기 및 위변조가 가능합니다. OTA 업데이트 기능의 3가지 필수 사항 1. 전원 및 네트워크로 인한 오류 발생 시 이전 안정화 버전 롤백 자율 주행 장치는 이동을 제어하기 위한 목적의 장치이므로 네트워크 연결 및 전원 공급의 불량으로 인해 업데이트가 실패 되면 이전 안정화 버전으로 돌아가는 롤백 기능이 기본적으로 제공되어야 합니다. Dual A/B 파티션 전략을 이용하면 비활성 루트 파일 시스템 파티션에 변경된 소프트웨어 업데이트 파일들을 설치하고 재부팅 이후에 부트로더가 해당 파티션에서 부팅 되도록 구성하는 방식으로 가장 안정적이고 빠른 롤백 기능 구현이 가능합니다. 2. 변경된 부분만 다운로드하고 패치(Delta 업데이트 지원) 네트워크 대역폭이 제한된 환경에서 기가 단위인 대용량 자율주행 운영체제를 포함한 소프트웨어를 배포해야 하는 경우 해당 장치의 배터리 전력이 빠르게 소모되거나 네트워크 사용 비용 증가 등 여러 가지 문제점이 발생할 수 있습니다. 따라서 OTA 업데이트를 진행할 파일의 크기와 시간, 네트워크 대역폭을 크게 절약할 수 있는 변경된 부분만 업데이트하는 Delta 업데이트 기술 메커니즘 도입이 필요합니다. 3. 가짜 OTA 업데이트 요청 거부 및 위변조된 소프트웨어 배포 방지 신규로 설치될 소프트웨어는 설치 대상 기기의 고유한 하드웨어 식별자와 인증서 기반의 공개키로 상호 인증된 장치에서만 다운로드 및 설치되어야 합니다. 추가적으로 암호화 및 코드 사이닝 적용을 통해서 설치 대상 소프트웨어(bootloader, kernel, root filesystem 등) 무결성을 보장하고 주요 애플리케이션 파일 및 데이터 위변조 공격으로부터 보호해야 합니다. 자율주행 장치와 클라우드 간에 종단 간(E2E) 암호화 통신을 위한 secure channel을 통해 클라우드 서버와 상호 인증된 자율 주행 장치만의 네트워크 통신만 허용해서 외부 공격을 원천적으로 차단하고 장치 내에서 외부로 나가는 통신을 지속적으로 모니터링하여 비정상적인 네트워크 연결 트래픽이 있는지 모니터링해야 합니다. Safe and Secure Over-the-air(SOTA) Software Update 1. 소개 42dot은 모든 장치에 쉽고, 빠르게, 안정적이고 안전한 소프트웨어 업데이트 적용 및 운영이 가능하게 해 주는 SaaS 형태의 솔루션을 자체 개발하고 있습니다. 등록된 모든 장치의 소프트웨어 배포 작업은 원격에서 중앙 통합 관리되며, 다음과 같은 주요 기능을 제공해서 안정적이고 안전한 OTA 소프트웨어 구현의 핵심 기술을 대상 장치에 빠르고 손쉽게 적용이 가능합니다. 2 주요 기능 2.1 공개키(PKCS#11) 기반의 장치 등록 및 인증 솔루션에 연결을 위한 장치를 프로비저닝 하려면 장치 / 서버 간 상호 인증서(x.509)와 private key를 생성하고 전자 서명 유효성 체크해야 합니다. 이때 생성된 장치 인증서와 private key는 하드웨어 방식인 HSM (Hardware Security Module) 또는 소프트웨어 방식인 ARM TrustZone 기술을 사용해서 TEE(Trusted Execution Environment)와 같은 안전한 영역에 대상 장치에 주입하고 장치 등록 및 인증을 하기 위한 CLI 프로비저닝 도구를 제공합니다. TrustZone? TrustZone은 ARM에서 개발한 ARMv6 이상의 CPU에서 추가된 보안 확장 집합인데 CPU, 주소 공간, 메모리를 하드웨어 단위로 분리하여 기밀성과 무결성을 제공할 수 있는 보안 및 비 보안으로 격리된 환경을 제공하는 기술입니다. 42dot은 PKCS#11과 OP-TEE OS를 조합한 소프트웨어 방식으로 private key나 인증서를 TEE 영역에서 저장하고 다양한 암복호화 및 서명 알고리즘을 사용하는 방식을 제공함으로써, 일반적으로 I2C 또는 SPI 인터페이스를 통해 메인 프로세스에 연결된 전통적인 하드웨어 방식의 전용 보안 칩셋이 필요하지 않습니다. 또한 다양한 3rd-party 벤더가 제공하는 PKCS#11 인터페이스를 지원하는 HSM/Secure elements 등의 하드웨어 보안 엔진들을 OpenSSL로 추상화해서 SDK나 agent에서 사용 가능합니다. PKCS#11? PKCS#11(공개 키 암호 표준 #11)은 키(RSA, 대칭 키, 타원 곡선 암호화), 인증서(X.509) 와 같은 암호화 객체 관리를 위한 API를 지정하는 표준으로써 PKCS#11은 물리적인 장치의 특성에 관계없이 애플리케이션과 암호화 장치 간의 표준 인터페이스를 제공합니다. 2.2 Dual Copy(A/B) 및 Delta 업데이트 지원 소프트웨어 업데이트 실패 시에 이전 상태로 복원이 빠르게 가능하도록 Dual copy(A/B)를 유지하는 방식을 지원합니다. 이 방식은 A라는 루트파일시스템이 booting 상태에서는 B라는 루트 파일시스템 또는 B라는 루트 파일시스템으로 booting 상태에서는 A라는 루트 파일 시스템 전체를 업데이트하는 방식으로, 업데이트 프로세스 중에 배포가 불완전하거나 손상된 경우에 장치를 수 초 안에 빠르게 복구할 수 있는 장점이 있습니다. 추가로 시스템 수준의 부트로더, 커널 및 각종 드라이버 루트 파일시스템 포함해서 신규로 업데이트되는 버전과 이전의 stable 버전 간의 바이너리 차이만 교체하는 Delta 업데이트를 지원합니다. 2.3 중앙에서 원격 업데이트 진행 상황 및 장치 상태 모니터링 웹 UI 또는 REST API를 사용하여 운영자가 장치 이름, 유형 및 제조 연도, 인증서 및 액세스 정책과 같은 장치 속성 관리가 가능하며, 단일 장치 또는 장치 그룹으로 구성해서 해당 그룹에 대한 계층 구조로 액세스 및 업데이트 배포 정책 설정해서 운영할 수 있습니다. 2.4 안전한 네트워크 통신을 위한 Secure Channel 지원 솔루션에 접속하는 모든 장치는 자체 구축된 PKI를 통해 발급된 자격 증명(X.509 인증서) 기반해서 디바이스 간에 주고받는 네트워크 프로토콜(MQTT, HTTPS) 트래픽을 장치와 서버와의 Mutual TLS 을 이용한 종단 간 암호화를 통해 안전하게 전송합니다. mTLS (mutual TLS)? mTLS는 서버와 클라이언트 간 상호 인증의 방법 중에 하나이며, 서버 클라이언트 모두 인증서가 있고 양쪽 모두 private key 쌍을 사용하여 인증합니다. 일반적인 TLS 와 비교하여 mTLS는 양 당사자를 확인하는 단계가 추가된 형태입니다. 2.5 Artifact 파일 서명 및 암복호화 지원 대상 장치에 전달된 업데이트가 신뢰할 수 있는 소스에서 온 것인지, 아니면 해커 혹은 악성코드에 의해 위변조 되지 않았는지 무결성을 확인할 수 있는 기능을 제공합니다. 빌드 서버에서 생성된 artifact 파일은 CLI 도구로 배포시 마다 private key와 public key가 신규로 만들어지고, 생성된 private key로 서명된 artifact 파일과 public key가 함께 서버에 업로드됩니다. 이후 OTA 업데이트 시 클라이언트는 서버에서 public key와 서명 값을 전달받고 다운로드 되는 이미지의 서명 체크를 통해 설치 대상 파일들의 위변조 여부를 확인할 수 있습니다. 이러한 서명 확인 절차를 통과하면 클라이언트는 해당 OTA 업데이트가 신뢰할 수 있는 소스에서 온 것으로 간주하고 다운로드 된 소프트웨어 설치를 진행합니다. 그리고 CBC 모드에서 AES 블록 암호를 사용하여 artifact 파일을 대칭적으로 암호화된 이미지로 배포해서 Artifact 위변조 공격을 방어하는 기능을 지원합니다. 2.6 Chain of Trust 기반의 Secure Booting Secure boot는 De-face 공격(펌웨어 및 구동 페이지 변조로, 해킹 당한 표시 및 오작동을 일으키는 방식), 소프트웨어 업데이트 및 펌웨어 변조 공격 등에 대한 효과적인 대비 방법으로 CPU -> Bootloader -> Kernel -> Root FileSystem(RootFS)의 순서로 각각의 시그니처 & 무결성 정보를 확인하고, 설치된 이미지에 변조가 없다면 정상적으로 부팅이 완료 되게 하는 기술입니다. 위 단계별로 동일하게 신뢰점(개별 시스템 이미지를 읽어, 해시 함수를 통해 메시지 다이제스트 생성, 개별 검증 프로그램으로 시그니처를 검증하는 방식) 과정을 통해 순차적으로 수행합니다. ・ ・ ・ 이 글이 자율주행 제어 장치뿐만 아니라 다양한 임베디드 장치의 OTA 업데이트 구현을 시작하는 기업과 제품 개발자들에게 작은 도움이 되면 좋겠습니다. 우리는 임베디드 장치 관련 소프트웨어 개발 업체들의 제품 프로젝트에 매우 적은 노력과 낮은 비용으로 안정적이고 안전한 OTA 업데이트 기능과 위에서 소개한 보안 기능들을 통합 적용해서 빠른 제품 출시에 실질적인 도움을 줄 수 있는 SaaS(Software as a Service) 클라우드 기반으로 서비스 제공을 준비하고 있습니다. 관련해서 보다 자세한 기술 및 기능 설명이나 demo 버전 사용을 원하시면 언제든지 42dot으로 문의 부탁드립니다. 김성준 | SDV Security (Tech Lead) 스스로 움직이는 모든 장치들에 적용될 보안 기술을 개발 하고 있습니다.