Yocto에서 Go 프로젝트 관리에 추가하여 JavaScript 기반의 프로그램을 Yocto의 패키지로 관리하는 방법을 정리해 본다.
관련 사항은 Yocto Wiki 의 NPM 기반 패키지 관리 방법에 간략하게 설명되어 있다.
TipsAndTricks/NPM - Yocto Project Javascript 기반의 프로젝트도 Go 언어와 마찬가지로 패키지 관련한 문제가 있지만 이 부분은 어느정도 툴을 이용하여 해결된 상태이다.
임베디드 환경에서 Javascript NPM 를 사용하는 경우를 크게 보면 다음 두 경우가 있을 수 있다.
Node.js 기반의 프로젝트 Webpack/React와 같은 static page 생성 Node.
Yocto recipe를 작성하다 보면 대부분의 프로젝트가 C, C++ 로 작성된 것들이라 이들은 참조할 것들이 많다. 하지만 Go, Rust, NodeJS 로 작성된 프로젝트는 Yocto에 추가하려다 보면 참고할 자료가 많지는 않은 편이다. 이 글에서는 Go 언어로 작성된 프로젝트를 추가하는 방법을 정리한다.
Go Module우선 간단하게 Go 의 모듈 정책에 대해서 정리 해본다.
2009년에 Go 가 처음 나왔을때는 모듈관리는 단순했다. Go 프로젝트에서 참고하는 모듈은 go get 으로 다운로드하면 $GOPATH/src 디렉토리에 해당 모듈이 설치된다. 하나의 예를 들면 다음과 같이 src 디렉토리에 모듈 경로를 포함해서 설치가 된다.
일반 웹 환경에서는 이제는 사양화 되어 거의 사용하지는 않지만, CCTV 표준인 ONVIF나 관련 보안 인증에서는 아직까지 HTTP Digest Authentication 을 사용한다.
이 글에서는 HTTP Digest Authentication의 전반적인 사항을 정리한다. 목차는 다음과 같다.
HTTP MD5, SHA-2 (SHA-256) Digest 인증 절차 Digest Authentication 웹 환경에서 더이상 사용하지 않는 이유 브라우저에서 SHA-256 Digest Authentication 구현 방법 HTTP MD5, SHA-2 (SHA-256) Digest 인증 절차HTTP Authentication은 RFC 표준으로 다음과 같이 정의 되어 있다.
RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication RFC 7616 - HTTP Digest Access Authentication 웹 초창기에 사용자 인증이 필요한 페이지를 위하여 RFC 2617 로 표준이 정의 되었다.
이전글 에서 설명한 Digital Signature 를 사용하면 문서의 서명을 검증할 수 있다. 이 서명을 체이닝으로 이어 나가면 3자 인증 기반의 PKI(Public Key Infrastructure)를 구성할 수 있다. X.509 는 ITU-T 에서 정의한 PKI 표준이다. 우리가 흔히 사용하는 인증서는 X.509 표준을 따른다.
인증의 기본적인 방법은 다음과 같은 절차이다.
Root 인증 기관(Certificate Authority, CA)가 있다고 하자. Root CA는 자신의 public key 를 별도의 방법으로 공개를 한다. 일반적인 PC 환경에서는 웹브라우저나 OS에 검증된 CA 인증서들이 내장되어 있다.
이전 글에 이어 PlatformIO를 이용하여 STM32Cube SDK 로 개발환경을 구성하는 것을 정리해 본다.
PlatformIO (1) - 개요 및 특징 PlatformIO (2) - STM32Cube Platform 개발 PlatformIO (3) - STM32Cube FreeRTOS 적용 PlatformIO (4) - PlatformIO 디버깅 PlatformIO (5) - PlatformIO Unit Test PlatformIO로 STM32 platform 설치하기VSCode에서 아래와 같이 PlatformIO Home을 연다.
New Project 선택하여 다음과 같이 설정
Name은 stm32test 와 같이 적절히 설정 Board는 “ST Nucleo F103RB” 선택 Framework는 “STM32Cube” 선택 Finish 로 생성 우선 동작이 되는지만 확인키 위하여 다음과 같이 src/main.
Cortex-M series 급을 이용한 임베디드 시스템 개발을 하다 보면, 지속적으로 사용할 수 있는 통합 개발 환경이 마땅치 않다는 문제가 있다. Windows 나 Linux 라면 한번 익혀 두면 수년은 두고 두고 쓸수 있는 개발 환경들이 있지만 임베디드 개발 환경의 경우 MCU 가 바뀔 때마다 개발환경을 바꾸어야만 하는 경우가 생긴다. 개발 환경의 범위를 최소 셋인 컴파일, 다운로드 만이 아닌 디버깅, unit test 까지로 고려한다면 범위가 더 좁아 질 수 밖에 없다.
지금까지는 대부분의 프로젝트는 임베디드 Linux 와 마찬가지로 gcc, binutils, gdb, OpenOCD 을 이용하여 개발하였고, 디버깅을 지원하는 통합 개발 환경으로는 emacs를 사용하였다.
Yocto project에서 기본 설정으로 빌드하면 SysV Init를 사용한다. 개발하는 제품이 이더넷 네트워크로 연결되고, 부팅 이후에는 네트워크 환경이 변하지 않는다면 SysV Init를 이용하는 것이 구조도 단순해서 더 좋을 수 있다.
하지만 다음과 같은 사항을 고려하고 있다면 systemd를 적용하는 것을 검토해 볼 수 있다.
Daemon 이 죽는 경우를 검출하여 재시작 관리가 필요한 경우 Wi-Fi 와 같이 동적으로 변경될 수 있는 네트워크 관리가 필요한 경우 불규칙하게 네트워크가 끊길 수 있는 조건에서 시간 동기화가 필요한 경우 프로그램에 CPU 또는 메모리 자원을 제한하기 위하여 cgroups를 사용하려는 경우 효과적인 로그 관리를 위하여 journald를 사용하고 싶은 경우 부팅 직후 초기 프로세스의 실행 시간을 줄여 보려는 경우 물론 위의 기능을 사용하기 위해서 systemd만 가능한 것은 아니지만, systemd를 사용하는 경우 별도의 프로그램 없이 위 기능을 쉽게 적용할 수 있다.
대부분의 최신 linux 배포본에서 systemd를 적용하면서 로그 시스템도 syslog 에서 systemd 의 journald로 변경되었다.
PC급 이상의 linux 배포본에서는 journald와 기존 호환성을 고려하여 syslog 데몬이 같이 사용하도록 기본 설정되어 있고, 상대적으로 광활한 저장장치과 메모리를 가지고 있고, 적절한 용량 선에서 log rotate가 되도록 설정되어 있어, 사용자가 설치 후 로그에 대해서는 신경을 쓸 필요가 거의 없다.
하지만 용량이 작은 저장장치와 메모리를 가진 embedded linux 제품을 개발하는 경우에는 시스템 로그를 어떤 식으로 관리 할지 충분히 고민하고 설정하여야 한다.
지금까지 설명한 암호화 알고리즘을 조합하여 확장을 해보기로 한다.
이 글에서 설명할 내용은 다음과 같다.
MAC(Message Authentication Code) AE(Authenticated Encryption) AEAD(Authenticated Encryption with Associated Data) MAC (Message Authentication Code)MAC은 한마디로 정리하면 Hash에 비밀키를 추가한 버전이라고 볼 수 있다.
키를 사용한다는 것으로 보면 DSA 디지털 서명과 비슷한 기능을 수행하지만, 공유키를 사용한다는 것이 다르다.
DSA는 Alice의 공개키를 가진 다수의 사람이 검증을 위한 용도이고, MAC은 키를 공유한 사람 간에 검증을 하기 위한 용도이다. 물론 연산량도 DSA와 비교하여 더 적고 빠르다.
이전 글 Elliptic Curve Cryptography(ECC)에서는 타원곡선 암호의 특징 및 알고리즘을 알아보았다.
이번에는 이를 활용한 암호화 응용과 실제 사용 예를 살펴보기로 한다.
ECC vs. RSA공개키 암호화 방법으로 RSA와 비교하여 이야기 되나, 실제적으로 ECC는 RSA와 동일한 기능으로 사용하지는 않는다.
정확히는 RSA가 아니라 이산대수 문제를 이용한 DH 나 DSA 용도로 사용한다고 말할 수 있다.
RSA의 경우 아래와 같이 평문 $k$ 를 공개키 $e$로 모듈러 지수 연산을 하는 형식이다.
$$ E = k^e \pmod{n} $$