Warehouse of PKI

30 큐브 구피 음성 수초항 만들기

JayKim — Wed, 17 Dec 2025 09:35:28 +0900

딸내미가 구피를 키우고 싶다고 해서 오랜만에 예전에 쓰던 30 큐브 어항을 셋팅해 봤다^^

2025년 12월 17일 일단 셋팅을 끝내고 기록 해본다.

아무래도 딸이 키우기 쉬운 환경을 고려해서 바닥제는 흑사로 그리고 수초는 빛이나 양분이 적게 사용하는 음성 수초로 꾸몄다.

물고기는 한국구피에서 구입한

알비노 네온 블루 턱시도 구피 7마리 (암4 숫3)

팬더 코리 4마리 (원래 5마리인데 한마리 어항 탈출로 용궁감)

그리고 이끼 제거를 위해 오토싱 2마리이다

내부 장식은 화산석과 조그만 유목으로 음성 수초를 부착해 주었다.

수초는 어떤게 키우기 쉬운지 몰라서 종류 별루 하나씩 부착했다.

아누비아스 나나, 콩나나, 골든나나, 미니골든나나, 부세(말라위핑크), 미크로소리움(원델롭)을 한 벌브씩 활착 해주었다.

[BerEditor] X509 데이타 비교 하기

JayKim — Fri, 24 Oct 2025 10:13:25 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 프로그램 키 발급 페이지에서 30일 라이선스 발급 가능합니다

PKI 기술에서 중요한 데이타이며 자주 사용하는 데이타는 X.509 형식인 인증서, CRL 그리고 CSR 이다.
이 데이타를 주로 파일로 저장을 하는데 저장하는 경우 DER 형식으로 바로 저장 하기도 하고 PEM 형식으로 저장하기도 한다.
가끔 이 파일들로 저장 할때 동일한 X.509 데이타인지 아닌지 확인이 필요할때가 있다
사실 저장 형식이 달라도 X.509 데이타가 동일하다.

이것을 눈으로 파악하기 어려울 때 이 기능을 사용하면 쉽게 구별 할 수 있다.

비교 메뉴

이 기능은 BerEditor -> Service -> X509 Compare 메뉴를 실행 해보면 아래 그림 처럼 창이 난온다.

X509 비교 화면

1 : 비교 대상 타입을 지정 하기
2 : 비교 대상 두개의 파일을 선택 하기
3 : 비교 하기 실행
4 : 두개의 파일에 대상을 자동으로 지정 ( 1번 지정 필요가 없다 )

비교 결과

X509 비교 결과 ( 왼쪽: 다른경우 오른쪽: 동일 경우 )

비교 실행을 하였을 때 두가지 경우 가 나오게 된다.
즉 두개가 다르거나 동일한 경우이다.
위 그림에서 왼쪽은 다른 경우를 나타내고 오른쪽은 동일한 경우를 나타낸다.

1 : 비교 결과 메세지
2 : 각 세부 항목 값을 표시 한다 ( 동일과 다른때 왼쪽 아이콘 표시 해줌 )
3 : 각 세부 항목을 클릭시 표현 이다 ( 같으면 검은색, 다른 경우 빨간색 표시 )

마무리

X509 형식으로 대표 되는 인증서 CRL CSR 경우 동일 사용하다
파일을 빠르게 동일 한지 파악하거나 어떻게 다른지 비교 하기 위해 이 기능을 활용하면 된다.

[BerEditor] DER BER 데이타 형식 체크

JayKim — Thu, 23 Oct 2025 13:47:37 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 프로그램 키 발급 페이지에서 30일 라이선스 발급 가능합니다

ASN.1 형식으로 파일을 DER 또는 BER 형식으로 인코딩을 하여 ASN.1 데이타를 보관한다.
사실 ASN.1 의 인코딩 데이타를 보구 어떤 형식인지 알기 위해서는 실제 인코딩 데이타에 대한 이해도가 필요하다

하지만 이 형식자체를 잘 모르는 경우가 많아서 일반적으로 형식을 잘 모르지만 형식을 파악하는 기능의 필요하다고 생각해서 이 기능을 제공한다.
형식을 알아도 금방 확인하기 어려울때도 맞는 형식인지 확인하기 위해서 사용 할 수 있다.

사실 모든 형식 파악에는 한계가 있지만 여기서는 주요 데이타 중에서 데이타 형식을 찾는 기능이다.

체크 형식 리스트

Certificate : X.509 형식으로 만들어진 인증서 형식
CRL : X.509 형식으로 만들어진 인증서 폐기 목록 형식
CSR : 인증서 발급 요청시 만들어진 X.509 형식은 인증서 발급 요청 형식
PublicKey : 공개키 정보를 가지고 있는 공개키 형식
PrivateKey : 개인키 정보를 가지고 있는 개인키 형식
PrivateKeyInfo : 개인키에서 PKCS#8 형식의 암호화가 되지 않는 PrivateKeyInfo 형식
EncPrivateKey : 개인키에서 PKCS#8 형식으로 암호화 된 개인키 형식
CMS : Cryptography Message Syntax 로 암호화 메시지 구문 형식
PKCS7 : PKCS7 형식으로 CMS 형식과 동일 하다고 보면 된다

형식 체크 방버

이 기능을 수행 하기 위해서 BerEditor -> Tool -> Check BER 메뉴를 선택 하면 아래 화면이 나온다

Check BER 실행 화면

1 : 체크 할 파일을 지정 해주거나 또는 값을 Source 부분에 입력한다.
2: BER Type Check 버튼을 클릭 하면 형식 메세지가 나오거나 에러를 표시 해준다.
3: 데이타 타입 체크후 형식을 한번 더 확인 한다.
여기서 "V" 마크는 상세 보기 기능이고 "D" 마크는 해당 데이타를 디코딩 해주는 기능이다.

아래 화면은 인증서 파일을 검색한 결과 화면이다.

실행 결과 화면

1 : 인증서 형식 알려줌
2: V 버튼 클릭 결과
3: D 버튼 클릭 결과

마무리

PKI 관련 기술을 다루다 보면 다양한 DER 형식의 데이타를 다루게 된다.
그리고 필요한 데이타를 파일이나 다른 형식으로 저장을 하게 되는데
이 저장된 데이타가 많아지거나 오래 되면 확인이 필요할 때 사용하는 기능이다.

[BerEditor] SHA3 SHAKE 다이제스트 구하기

JayKim — Sat, 18 Oct 2025 21:22:58 +0900

[이 기능은 라이선스 버전 기능입니다]

라이선스가 필요한 분은 프로그램 키 발급 페이지에서 30일 라이선스 발급 가능합니다
이 기능은 BerEditor 2.5.0 버전 이상에서 테스트가 가능 합니다.

PQC 알고리즘에서 사용하는 Digest 인 SHA3 와 SHAKE 값을 BerEditor 을 이용해 구해보자

SHA3 경우 SHA3-224, SHA3-256, SHA3-384 그리고 SHA3-512 이렇게 4가지 방식이 있다.
각각의 결과 길이는 SHA2 와 동일하게 24, 32, 48, 64 바이트의 결과를 만들게 된다.

그리고 SHAKE 경우는 SHAKE128 과 SHAKE256 두가지 방식을 지원한다.

그럼 BerEditor 에서 Hash 를 구하기 위해서 BerEditor -> Cryptography -> Hash 메뉴를 선택하자
그러면 Hash 값을 구하는 창이 나오게 되니다.

SHA3-256 계산하기

SHA3-256 해시를 구하려면 Input 에 원하는 입력값을 넣구 알고리즘에서 SHA3-256 을 선택하고
Digest 버튼을 입력하면된다.

입력후 결과 값이 Digest Value 에 표시된다.
예제 입력값은 헥사값 11223344 의 결과가 32 바이트가 나온 화면이다.

SHA3-256 실행 화면

실제 Digest 값을 구하는 방식은 두가지 인데
첫번째는 Init Update Final 방식을 이용하는데 이 방식은 입력 값을 여러번 나누어서 넣기 위한 방식이고
Digest 는 현재 입력값에 대한 결과를 얻기 위한 것이다.

SHAKE128 계산하기

SHAKE128 인경우는 원하는 입력 값을 넣구 알고리즘에서 SHAKE128 을 선택 해주어야한다.
SHAKE 경우는 다른 옵션이 있는데 결과 길이를 지정해 주어야 한다. 아레 예제 화면에서는 64 바이트를 지정한 방식이다.

SHAKE128 실행 화면

SHAKE128 과 SHAKE256 은 둘다 Request Length 값을 지정해 주어야 한다.

마무리

PQC 알고리즘에서는 해시 알고리즘 경우 SHA2 SHA3 SHAKE 를 사용하게 된다.
SHA2 경우는 PQC가 아니어도 현재 주력으로 사용하고 있고 여기서는 간단히 SHA3와 SHAKE 값을 구해 보았다.

여기서는 단지 입력값을 넣는 예제를 설명 하였지만 파일에 대한 값을 구하려면 Input File 탭을 선택하여 파일에 대한 해시도 구할 수 있다.

[BerEditor] ML-KEM 키 쌍 생성 및 키 암호화(Encapsulation)

JayKim — Sat, 18 Oct 2025 12:34:56 +0900

[이 기능은 라이선스 버전 기능입니다]

라이선스가 필요한 분은 프로그램 키 발급 페이지에서 30일 라이선스 발급 가능합니다
이 기능은 BerEditor 2.5.0 버전 이상에서 테스트가 가능 합니다.

BerEditor 툴을 이용해 PQC 알고리즘인 ML-KEM 키 쌍 생성 및 대칭키 암/복호화를 해보자
여기 예제로 실행 환경은 언어가 영어로 되어 있다. 한글 경우는 메세지가 한글로 나오게 된다.

ML-KEM 키쌍 생성

먼저 전자 서명을 생성하기 위해서는 ML-KEM 키 쌍을 생성해야 한다.
키 쌍 생성하기 위해서는 BerEditor -> Service -> KeyPair Manager 를 실행한다.
KeyPair Manager 에서 Gen KeyPair를 선택 한다

키 쌍 생성 선택 화면

KeyPair 창에서 키쌍 이름을 입력하고 PQC 부분의 ML KEM 를 선택하고
KeyLength 는 3( KEM_512, KEM_768, KEM_1024 ) 개 중에 하나를 선택하면 된다

MK-KEM 키 쌍 생성

키 쌍이 생성 되면 KeyPair Manager 에서 입력한 이름으로 키 쌍을 확인 할 수 있다.
상세 키 값을 볼려면 해당 키를 더블클릭하면 키 값을 볼 수 있다.

ML-KEM 개인키 보기

사실 KeyPair Manager 에서 생성한 키 쌍은 테스트용이라 특별히 개인키에 대해서는 순수한 값으로 PEM형식으로 저장이 된다.
KeyPair Manager 는 안전한 보관 보다는 테스트 용으로 생각해야 한다.

ML-KEM 암호화 (Encapsulation)

생성한 ML-KEM 키 쌍으로 키 암호화 하기 위해서는 BerEditor->Cryptography->Key Manage 메뉴를 선택 한다.

해당 창이 열리면 KEM 탭을 선택하자
그리고 해당 창에서 Encapsulate 라디오 버튼을 클릭하자 (디폴트로 선택 되어 있다).

특별히 입력 데이타는 없고 keyPair Manager에서 이전에 생성한 키를 ML-KEM 키를 선택 하자 (더블클릭)
해당 키를 선택하면 Wrapped Key 와 생성된 키 값이 나타난다.
내부적으로 KeyPair Manager 에서 공개키를 읽어서 암호화를 하게 된다.

KEM Encapsulation

여기서 Wrapped Key 가 암호화 데이타이므로 이 값을 개인키가 있는 쪽에 보내주는 값이고
생성 키 값은 자신이 사용하는 개념이다.

ML-KEM 키 복호화 (Decapsulation)

생성한 ML-KEM 키 쌍으로 키 복호화 하기 위해서는 BerEditor->Cryptography->Key Manage 메뉴를 선택한다.

열린 창에서 KEM 탭을 열어 주자
그리고 해당 창에서 Decapsulate 라디오 버튼을 클릭 하자

입력 데이타에는 Wrapped Key 값을 입력하고 Run 버튼을 누르면 검증할 키를 선택하는 KeyPair Manager 창이 나타난다.
이 KeyPair Manager 에서 기존에 생성한 ML-KEM 키를 선택하면 복호화 된 키가 나온다.
내부적으로 KeyPair Manager 에서 개인키를 읽어서 복호화 하게 되는 것이다.

KEM Decapsulation

마무리

현재 PQC 알고리즘에서 대칭키를 양쪽이 공유 하기 위해서는 ML-KEM 키를 이용하여 공유 하게 된다.
이때 결과로 나오는 32바이트 키를 가지고 서로 키 공유를 하게 되는 방식이다.

[BerEditor] ML-DSA 키쌍 생성 그리고 전자 서명

JayKim — Fri, 17 Oct 2025 11:53:01 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 프로그램 키 발급 페이지에서 30일 라이선스 발급 가능합니다
이 기능은 BerEditor 2.5.0 버전 이상에서 테스트가 가능 합니다.

BerEditor 툴을 이용해 PQC 알고리즘인 ML-DSA 키 쌍 생성 및 전자 서명을 해보자
여기 예제로 실행 환경은 언어가 영어로 되어 있다. 한글 경우는 메세지가 한글로 나오게 된다.

ML-DSA 키쌍 생성

먼저 전자 서명을 생성하기 위해서는 ML-DSA 키 쌍을 생성해야 한다.
키 쌍 생성하기 위해서는 BerEditor -> Service -> KeyPair Manager 를 실행한다.

KeyPair Manager 에서 Gen KeyPair를 선택 한다

KeyPair Manager 실행 화면

KeyPair 창에서 키쌍 이름을 입력하고 PQC 부분의 ML DSA 를 선택하고
KeyLength 는 3(DSA_44, DSA_65, DSA_87) 개 중에 하나를 선택하면 된다

ML-DSA 키 쌍 생성 화면

키 쌍이 생성 되면 KeyPair Manager 에서 입력한 이름으로 키 쌍을 확인 할 수 있다.
상세 키 값을 볼려면 해당 키를 더블클릭하면 키 값을 볼 수 있다.

생성한 ML-DSA 키 쌍 상세 값 화면

CertMan 경우는 인증서와 개인키를 저장하는데 CertMan 에서는 인증서가 함께 사용이 되므로 좀더 안전을 위해서 개인키 저장을 PKCS8 형식으로 암호화 하여 저장하고 사용시 개인키 암호를 묻는 형식이다.

ML-DSA 전자서명 생성하기

생성한 ML-DSA 키 쌍으로 전자 서명을 하기 위해서는 BerEditor->Cryptography->Sign/Verify 메뉴를 선택 한다.
그리고 해당 창에서 Sign 라디오 버튼을 클릭하자 (디폴트로 선택 되어 있다)

참고로 ML-DSA경우는 특별히 Hash 알고리즘 콤보값은 무시하게 된다.
특히 EDDSA ML-DSA SLH-DSA 경우는 Hash 알고리즘 지정이 아닌 내부적으로 고정 된 값을 사용하기 때문에 Hash 값의 지정이 필요하지 않다. ML-DSA 내부적으로 해시 알고리즘으로 SHAKE 사용한다.

입력데이타를 넣고 Sign 버튼을 클릭 하면 keyPair Manager에서 이전에 생성한 키를 ML-DSA 키를 선택 하자 (더블클릭)
해당 키를 선택하면 Signature 값에 서명값이 나타난다.
내부적으로 KeyPair Manager 에서 개인키를 읽어서 서명을 하게 되는 것이다.

ML-DSA 전자서명 생성

참고로 상단에 Use CertMan 은 체크가 되면 안된다.
Use CertMan 을 체크 하면 실제로 keyPair Manager 창이 나타나지 않고 CertMan 창이 나타나기 때문이다.
물론 CertMan에서 ML-DSA 키와 인증서가 들어가 있다면 동일 하게 테스트가 가능하지만
여기서는 keyPair Manager 을 사용하는 예제이기 때문이다.

그리고 여기서 만든 키 쌍이 아니라 개인키와 공개키가 파일로 테스트를 하고 싶다면
select each cerificate and private key 를 체크해서 해당 파일을 선택해서 테스트도 가능 하다.

ML-DSA 전자서명 검증하기

생성한 ML-DSA 키 쌍으로 전자 서명을 검증하기 위해서는 BerEditor->Cryptography->Sign/Verify 메뉴를 선택한다.
그리고 해당 창에서 Verify 라디오 버튼을 클릭 하자

입력 데이타와 Signature 값을 입력하고 Verify 버튼을 누르면 검증할 키를 선택하는 KeyPair Manager 창이 나타난다.
이 KeyPair Manager 에서 기존에 생성한 ML-DSA 키를 선택하면 서명 검증 결과를 알려준다.
내부적으로 KeyPair Manager 에서 공개키를 읽어서 서명을 검증 하게 되는 것이다.

아래 그림에서는 Signature 부분에 네모 표시가 빠졌지만 Signature 값이 입력 되어야 한다.

ML-DSA 전자서명 검증

서명 검증경우도 서명 생성과 동일 하게 Use CertMan은 체크가 되면 안된다.

마무리

현재 PQC 알고리즘 필요성 및 변경에 대하여 빠르게 요구 되구 있는거 같다
그리고 OpenSSL 3.5 LTS 버전에 ML-DSA, ML-KEM, SLH-DSA 가 포함이 되었다.
이제 PQC 에 익숙해지고 값을 확인 해보기 위해 BerEditor 에서 지원 하게 되었다.

참고로 SLH-DSA 경우는 키 쌍 선택시 SLH-DSA 만 선택 하고 키 쌍생성 전자서명 및 검증 모두 동일하다.

[OpenSSL] ML-KEM ML-DSA SLH-DSA 키 사용

JayKim — Fri, 10 Oct 2025 12:17:49 +0900

ML-KEM encapsulation / decapsulation

openssl pkeyutl -encap -inkey mlkem768_pub.pem -secret secret.bit -out ciphertext

openssl pkeyutl -decap -inkey mlkem768_priv.pem -in ciphertext -secret decapsulated_secret.bin

ML-DSA sign / verify

openssl pkeyutl -sign -in test.txt -inkey mldsa65_priv.pem  -out sig

openssl pkeyutl -verify -in test.txt -inkey mldsa65_pub.pem -pubin -sigfile sig

참고로 BerEditor 를 사용하여도 생성 할 수있다.
https://jykim74.tistory.com/295

SLH-DSA sign / verify

openssl pkeyutl -sign -in test.txt -inkey slhdsa_priv.pem  -out sig

openssl pkeyutl -verify -in test.txt -inkey slhdsa_pub.pem -pubin -sigfile sig

[OpenSSL] PQC 알고리즘 ML-KEM ML-DSA SLH-DSA 키 쌍 생성

JayKim — Fri, 10 Oct 2025 11:00:59 +0900

ml-kem 키 쌍 생성

# 개인키 생성
openssl genpkey -algorithm ML-KEM-768 -out mlkem768_priv.pem

# 공개키 추출
openssl pkey -in mlkem768_priv.pem -pubout -out mlkem768_pub.pem

# ASN.1 데이타 보기
openssl asn1parse -in mlkem768_priv.pem -dump

ml-dsa 키 쌍 생성

# 개인키 생성
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_priv.pem

# 공개키 추출
openssl pkey -in mldsa65_priv.pem -pubout -out mldsa65_pub.pem

slh-dsa 키 쌍 생성

# 개인키 생성
openssl genpkey -algorithm SLH-DSA-SHA2-128S -out slhdsa_priv.pem

# 공개키 추출
openssl pkey -in slhdsa_priv.pem -pubout -out slhdsa_pub.pem

[OpenSSL] SHAKE SHA3 다이제스트 명령

JayKim — Fri, 10 Oct 2025 09:44:47 +0900

먼저 OpenSSL 명령어에서 SHAKE 와 SHA3 지원 유무 확인

openssl dgst -list
Supported digests:
-blake2b512                -blake2s256                -md4
-md5                       -md5-sha1                  -mdc2
-ripemd                    -ripemd160                 -rmd160
-sha1                      -sha224                    -sha256
-sha3-224                  -sha3-256                  -sha3-384
-sha3-512                  -sha384                    -sha512
-sha512-224                -sha512-256                -shake128
-shake256                  -sm3                       -ssl3-md5
-ssl3-sha1                 -whirlpool

SHA3-256 값 구하기

openssl dgst -sha3-256 test.txt
SHA3-256(test.txt)= 3338be694f50c5f338814986cdf0686453a888b84f424d792af4b9202398f392

SHAK128 테스트 값 구하기

openssl dgst -shake128 -xoflen 32 test.txt
SHAKE-128(test.txt)= 8eb4b6a932f280335ee1a279f8c208a349e7bc65daf831d3021c213825292463

openssl dgst -shake128 -xoflen 16 test.txt
SHAKE-128(test.txt)= 8eb4b6a932f280335ee1a279f8c208a3

SHAKE 경우 결과 길이를 요구하는데 -xoflen 옵션을 통해 지정한다.

이 기능은 BerEditor 툴을 이용해서 구할 수 있다.
[BerEditor] SHA3 SHAKE 다이제스트 구하기

RSA 알고리즘에서 CRT 사용 하는 이유 (ChatGPT 설명)

JayKim — Tue, 17 Jun 2025 14:40:07 +0900

RSA 암호화에서 CRT (Chinese Remainder Theorem, 중국인의 나머지 정리) 알고리즘은 RSA 서명/복호화 속도를 빠르게 하기 위해 사용됩니다. 기본 RSA 연산은 매우 큰 수에 대한 모듈러 지수 연산(modular exponentiation)을 포함하므로 계산량이 많습니다. CRT를 활용하면 이 계산을 두 개의 더 작은 수 위에서 나눠서 수행할 수 있기 때문에 성능이 약 4배까지 향상됩니다.

RSA 복호화 기본 방식

기본 RSA 복호화(또는 서명)는 다음과 같이 계산됩니다:

여기서 n=p⋅q는 두 개의 큰 소수의 곱입니다.

CRT를 이용한 빠른 복호화 (RSA-CRT)

다음은 CRT를 이용한 복호화 절차입니다:

사전 계산 (한 번만 필요)

이 값들은 개인키에 함께 저장됩니다.

복호화 과정

✅ 왜 더 빠른가요?

일반 RSA 복호화는 큰 수 n (2048비트 이상)에 대한 연산이지만,
CRT는 작은 수 p,q (1024비트 이하)로 나눠 연산함 → 각각 4배 빠른 연산을 2번 하면 전체적으로 약 4배 빠른 결과.

보안 유의사항

CRT는 성능을 크게 개선하지만, CRT 기반 RSA는 파워 분석 공격 같은 부채널 공격에 취약할 수 있습니다. 따라서:

CRT를 사용할 때는 블라인딩(blinding) 기법 등을 통해 보안을 강화해야 합니다.
OpenSSL 등 실무 라이브러리는 대부분 CRT를 사용하되, 보안 대비도 함께 고려합니다.

[BerEditor] 데이타 변환 (Data Converter) 하기

JayKim — Mon, 20 Jan 2025 15:14:41 +0900

BER 데이타는 실제로 바이너리 데이타이다.
하지만 우리가 이 데이타를 사용하기 위해서 실제로 읽어서 입력 하거나 사용하기 위해서는 해당 데이타를 문자로 변환하게 된다. 실제 데이타가 문자인 경우는 그냥 값을 읽고 쓰는게 가능하지만 그 외에 읽을 수 없는 데이타이다.

그래서 값을 읽고 쓰기 위해서 사용하는 방법은 16진수 인코딩 이나 Base64 인코딩 방식이다.
BerEditor에서는 이렇게 바이너리를 변환하기 위해 데이타 변환기 기능이 있다.
해당 메뉴는 도구->데이타 변환기 를 실행하면 된다.

이 데이타 변환기에서는 5가지 변환을 지원 한다.

문자열 (String) : 일반 ASCII 문자들이다.
16진수(Hex) : 헥사 인코딩 문자들이다. 한바이트의 데이타를 앞4비트 뒤 4비트를 0~8와 A-F 로 16진수 표기 방식이다.
Base64 : 총 64개의 ASCII 문자(A-Z, a-z, 0-9, +, /)를 사용하여 데이터를 표현
URL : URL에 포함될 수 없는 특수 문자나 비-ASCII 문자를 안전하게 전송하기 위해 인코딩하는 방식
Base64URL : Base64와 유사하지만, URL에서 특별한 의미를 가지는 문자를 피하기 위해 일부 문자를 대체하거나 제거한 것이 특징

사용자 UI 설명

Data Converter 화면

1) 입력할 데이타 타입을 말한다.
2) 입력 데이타의 길이 바이트를 표시한다.
3) 변환을 실행한다.
4) 변환 데이타 타입을 지정한다.
5) 변환된 데이타 길이 바이트를 표시한다.
6) 4번에서 정해진 형식에 따른 결과를 표시한다.

참고) 길이 표시경우 문자열은 입력 문자 개수이고 16진수와 Base64 경우는 디코딩 된 데이타 길이를 표시한다.
16진수 덤프는 결과 값에 대한 16진수 표기와 텍스트 경우 텍스트 표기를 보여준다.

길이 경우 16진수에서는 입력값 길이의 반값이다. 왜냐하면 16진수는 한바이트를 두개의 헥사값의 표시이다.
Base64경우는 대체로 입력한 길이보다 4분의 1정도 길이가 작은 정도로 보면 된다.
Base64경우는 3개의 문자를 나열해서 6비트 단위로 표시를 하다 보니 인코딩 길이는 약 3분의1정도의 길이가 늘어 나기 때문이다

아래 화면은 Hello 문자열에 대한 16진수값 변환 예제이다

데이타 변환 화면

데이타 변환 16진수 덤프 화면

마무리

사실 BER 데이타를 사용할때 데이타 변환은 16진수 또는 Base64 인코디을 사용하게 된다.
여기서 URL이나 Base64URL 의 경우 BER 데이타에는 사용하지 않지만 가끔 해당 데이타로 변환 이 필요 할때가 있어서 기능을 추가 하였다.

수학 빅넘 연산에서 LCM( P-1, Q-1) 값 구하는 법

JayKim — Wed, 16 Oct 2024 10:07:09 +0900

LCM은 두수의 최소 공배수 이다. 이건 간단한 산수 이지만 실제로 적용할때는 어려워 보여서 한번 정리한다

RSA 암호에서 소수 P와 Q를 사용하여 개인키 D를 구할 때,
P−1과 Q−1의 최소공배수(LCM)을 이용한다.

빅넘 연산을 할때 아래 공식을 이용하여 계산 한다

$$ LCM(P-1,Q-1) = \frac { (P-1) \times (Q-1) } { GCD( P-1, Q-1) } $$

여기서:

P와 Q는 두 개의 소수입니다.
P−1과 Q−1은 각각 P와 Q에서 1을 뺀 값입니다.
GCD(P−1,Q−1) 는 P-1과 Q-1 의 최대공약수(Greatest Common Divisor)를 의미한다.

예를 들어, P=11, Q=7일 때:

P−1=10, Q−1=6
GCD(10,6) = 2 (최대공약수)
LCM(10,6) = (10 x 6 ) / 2 = 30

따라서 LCM(P−1,Q−1) = 30 이다

RSA에서 P와 Q는 개인키 생성에 사용되며, LCM(P−1,Q−1)은 모듈러 연산을 설정하는 데 활용된다.

PKI 기반 보안 시스템

JayKim — Fri, 27 Sep 2024 15:51:14 +0900

강의 자료로 사용할 문서 올려 봅니다.

한살림 논학교 방문기 (2024-09-21)

JayKim — Mon, 23 Sep 2024 09:22:39 +0900

무더운 여름이 가고 날씨가 많이 시원 해진 오늘 논학교를 둘째와 함께 방문했어요

오전에 비가 온후라 땅이 많이 젖어 있네요.

그동안 논에 심은 쌀은 잘자라고 있었어요. 가끔 참석한 논학교 이지만 벼들이 무척 잘 자라는걸 보니 기특하네요^^

저는 어릴깨 농사 짓는 부모님에게 자라서 사실 농사일 하러 굳이 가는게 별루 였지만 와이프 때문에 아이들과 가게 되었어요.

하지만 이렇게 아이들과 같이 자연속에서 논학교에 참석을 해보니 옛날 생각도 나고 둘때도 좋아하는걸 보니 좋은 경험이 되네요^^

오늘은 논학교 선생님이 채집통이랑 곤충 잡는 채도 만들고 아이들과 같이 허수아비 만들기 놀이를 했어요.

잡아온 벌레랑 곤충들을 아이들이 만지고 잘 노네요. 처음에는 조금 징그럽기도 했는데.. 사실 곤충들이 자연 생태게에 많은 도움을 주는걸 생각해보니 예쁘게 보이네요^^

아이들도 많이 좋아하네요. 둘째도 곤충 채집을 열심히 하네요^^

그리고 만든 통이랑 채로 곤충을 잡았어 아이들과 같이 서로 설명을 들었어요.

그동안 복잡한 도시 생활에서 나와서 이렇게 아이들과 같이 벼가 자라는 모습도 관찰 하고 허수아비를 만들어서 논에다 세우기도 하고 이렇게 다양한 곤충들을 채집도 하고 관찰도 할 수 있는 좋은 시간이 되었네요^^

몬테 카를로 테스트 ( Monte Carlo Test )

JayKim — Tue, 3 Sep 2024 13:07:11 +0900

Monte Carlo Test 검사는 대칭키 암호 또는 해시 알고리즘의 안전성과 무작위성을 검증하기 위해 사용하는 통계적 방법 중 하나입니다. 대칭키 암호 알고리즘은 동일한 키를 사용하여 데이터를 암호화하고 복호화하는 방식인데, 이러한 알고리즘의 보안성을 평가하는 중요한 절차 중 하나가 Monte Carlo Test입니다.

다음은 몬테카를로 테스트를 위한 psedo 코드이다.

참고 자료 [Cipher] [Hash]

해시 함수의 몬테 카를로는 두가지 방식이 있다 Standard 와 Alternate 방식이다.

SHA-1 and SHA-2 Standard Monte Carlo Test

For j = 0 to 99
    A = B = C = SEED
    For i = 0 to 999
        MSG = A || B || C
        MD = SHA(MSG)
        A = B
        B = C
        C = MD
    Output MD
    SEED = MD

SHA-1 and SHA-2 Alternate Monte Carlo Test:

INITIAL_SEED_LENGTH = LEN(SEED)
For j = 0 to 99
    A = B = C = SEED
    For i = 0 to 999
        MSG = A || B || C
        if LEN(MSG) >= INITIAL_SEED_LENGTH:
            MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
        else:
            MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
        MD = SHA(MSG)
        A = B
        B = C
        C = MD
    Output MD
    SEED = MD

대칭키 암호화의 몬테 카를로 방식은 운영 모드마다 각각의 방식이있다.
그리고 암호화 / 복호화 각각의 방식을 사용하다.
참고로 복호화 경우 암호화에서 PT->CT 로 대응 되며 암호화->복호화를 대칭된다구 보면 된다.

AES Monte Carlo Test - ECB mode

Encrypt

Key[0] = KEY
PT[0] = PT
For i = 0 to 99
    Output Key[i]
    Output PT[0]
    For j = 0 to 999
        CT[j] = AES_ECB_ENCRYPT(Key[i], PT[j])
        PT[j+1] = CT[j]
    Output CT[j]
    AES_KEY_SHUFFLE(Key, CT)
    PT[0] = CT[j]

AES Monte Carlo Test - CBC mode

Encrypt

Key[0] = KEY
IV[0] = IV
PT[0] = PT
For i = 0 to 99
    Output Key[i]
    Output IV[i]
    Output PT[0]
    For j = 0 to 999
        If ( j=0 )
            CT[j] = AES_CBC_ENCRYPT(Key[i], IV[i], PT[j])
            PT[j+1] = IV[i]
        Else
            CT[j] = AES_CBC_ENCRYPT(Key[i], PT[j])
            PT[j+1] = CT[j-1]
    Output CT[j]
    AES_KEY_SHUFFLE(Key, CT)
    IV[i+1] = CT[j]
    PT[0] = CT[j-1]

AES Monte Carlo Test - OFB mode

Encrypt

Key[0] = Key
IV[0] = IV
PT[0] = PT
For i = 0 to 99
    Output Key[i]
    Output IV[i]
    Output PT[0]
    For j = 0 to 999
        If ( j=0 )
            CT[j] = AES_OFB_ENCRYPT(Key[i], IV[i], PT[j])
            PT[j+1] = IV[i]
        Else
            CT[j] = AES_OFB_ENCRYPT(Key[i], PT[j])
            PT[j+1] = CT[j-1]
    Output CT[j]
    AES_KEY_SHUFFLE(Key, CT)
    IV[i+1] = CT[j]
    PT[0] = CT[j-1]

AES Monte Carlo Test - CFB128 mode

Encrypt

Key[0] = Key
IV[0] = IV
PT[0] = PT
For i = 0 to 99
    Output Key[i]
    Output IV[i]
    Output PT[0]
    For j = 0 to 999
        If ( j=0 )
            CT[j] = AES_CFB128_ENCRYPT(Key[i], IV[i], PT[j])
            PT[j+1] = IV[i]
        Else
            CT[j] = AES_CFB128_ENCRYPT(Key[i], PT[j])
            PT[j+1] = CT[j-1]
    Output CT[j]
    AES_KEY_SHUFFLE(Key, CT)
    IV[i+1] = CT[j]
    PT[0] = CT[j-1]

마무리

몬테카를로 테스트는 암호 또는 해시 함수의 구현을 검증 하기 위해 사용된다.
CMVP 또는 FIPS 인증을 받기 위해서는 MCT 테스트를 요구 하기 때문에 필수로 구현이 필요하다.

블록 암호 운영 모드 ( Block Cipher mode of operation )

JayKim — Wed, 28 Aug 2024 23:05:29 +0900

그림 출처 [위키]

Electronic codebook (ECB)

ECB Encryption

ECB Decryption

Cipher block chaining (CBC)

CBC Encryption

CBC Decryption

Cipher feedback (CFB)

CFB Encryption

CFB Decryption

Output feedback (OFB)

OFB Encryption

OFB Decryption

Counter (CTR)

CTR Encryption

CTR Decryption

Galois/counter (GCM)

GCM

Counter with cipher block chaining message authentication code (CCM)

[BerEditor] 클라이언트 기능에 관하여

JayKim — Tue, 27 Aug 2024 16:49:55 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

BerEditor가 제공 하는 클라이언트 기능이 있습니다.

OCSP, TSP, CMP, SCEP 이렇게 클라이언트 기능은 해당 프로토콜 사용 하는 서버와 연동 하여서

주고 받는 BER 데이타를 인코딩/디코딩을 위한 기능입니다.

현재 연동하는 서버는 자체 개발한 서버와 연동 테스트를 하였습니다.

자체 서버가 아닌 다른 서버는 연동 해 본적이 없어서 연동이 안될 가능성이 많습니다.

해당 프로토콜들이 물론 표준 프로토콜이라 다른 서버와 연동이 될 수도 있지만 보장 할 수는 없네요.

언제가 될지 모르겠지만 서비스를 제공할 수 있는 서버가 있으면 설치 해서 연동을 할 수 있지만..

아직은 서비스를 제공할 서버를 설치 할 곳이 없어서.. 연동 테스트를 할 수 없습니다.

그리고 추후에 서버들도 배포를 통해 설치 지원 할 생각은 있지만 아직 기능도 많이 부족하고

안정화가 오래 걸릴것으로 보이네요.

이 부분은 참고 하세요.

버그가 너무 많다..

JayKim — Fri, 26 Jul 2024 13:15:56 +0900

오래전 부터 PKI 관련 일을 하면서 필요한 기능의 툴을 사이드로 계속 만들어 왔다.

지금까지는 계속 내가 만들고 싶고 필요하다고 생각하는 기능을 추가 하는데 집중하고 있어서

안정화나 버그에 신경을 많이 쓰지 않았다..

사이드 프로젝트로 짬짬이 하다 보니 기능 구현 만하고 테스트를 거의 하지 못했다.

하지만 이 툴들을 공유하게 되면서 기능도 중요하지만 오류가 아닌 정확히 작동 되는 신뢰가 필요한데 이 부분을 소홀히 한거 같다.

신뢰가 없는 툴을 누가 쓰겠냐고ㅡㅡ;;

많이 쓰는 기능은 대체로 잘 돌아 가지만.. 그외 버그가 너무 많다.. 그러다 보니 쓰는 사람도 별루 없는거 같아 ...

쓰는 사람이 적어서.. 딱히 피드백도 별루 없구 나도 만들어 놓고 당장 업무에 사용 하지 않음 쓰지 않다 보니

문제가 있어도 인지를 못하고 있었다 ㅡㅡ;;

그래서 일주일간 기존 기능 테스트와 UI 개선 집중을 해서 업데트를 했는데..

이렇게 오류가 많나? 그리고 UI 는 왜이렇게 체계가 없나 내가 봐도 문제가 많구나 하는데..

가져다 쓰는 사람은 더 어렵지 않았을까 ㅡㅡ;;

당분간은 기능을 만들기 보다는 안정화나 오류 수정에 집중해야 할꺼 같다...

혹시나 제가 만든 툴을 사용하시는 분은 항상 최신으로 업데이트 사용하기를 권장 합니다^^

사용하다가 이상하거나 버그라고 생각하면 문의를 주시거나 알려 주세요.(Please)

요청이나 피드백도 환영합니다

그래도 지금까지 확인된 버그는 수정 하였으니 많이 이용해 주세요^^

KMIP 에 사용 되는 TTLV 포맷

JayKim — Wed, 10 Jul 2024 09:58:47 +0900

이글은 ChatGPT 문의 내용에 일부 수정 하였습니다.

KMIP( Key Management Interoperability Protocol)은 다양한 키 관리 시스템과 클라이언트 사이의 상호 운용성을 보장하기 위해 OASIS(Organization for the Advancement of Structured Information Standards)에서 개발한 표준 프로토콜입니다. KMIP는 여러 메시지 형식을 지원하지만, 특히 TTLV(Tag, Type, Length, Value) 형식은 매우 중요합니다.

KMIP TTLV 포맷

KMIP의 TTLV 형식은 메시지를 구성하는 각 필드에 대해 다음과 같은 구조를 따릅니다:

Tag (태그)
- 각 필드의 유형을 식별합니다.
- 보통 3바이트(24비트)로 구성됩니다.
- 예를 들어, Tag가 0x4200이면 이는 "Request Message"를 의미합니다.
Type (타입)
- 값의 데이터 유형을 식별합니다.
- 1바이트(8비트)로 구성됩니다.
- 예를 들어, Type이 0x05이면 이는 "Integer"를 의미합니다.
Length (길이)
- Value 필드의 길이를 바이트 단위로 나타냅니다.
- 4바이트(32비트)로 구성됩니다.
Value (값)
- 실제 데이터 값이 포함됩니다.
- 길이는 Length 필드에 의해 결정됩니다.

TTLV 예제

아래는 KMIP TTLV 포맷의 예제입니다.

Tag:    0x420078 (Request Message)
Type:   0x01 (Structure)
Length: 0x00000020 (32 bytes)

Value:
  Tag:    0x420077 (Request Header)
  Type:   0x01 (Structure)
  Length: 0x00000018 (24 bytes)

  Value:
    Tag:    0x420085 (Protocol Version)
    Type:   0x01 (Structure)
    Length: 0x00000008 (8 bytes)

    Value:
      Tag:    0x420086 (Protocol Version Major)
      Type:   0x02 (Integer)
      Length: 0x00000004 (4 bytes)
      Value:  0x00000001 (1)

      Tag:    0x420087 (Protocol Version Minor)
      Type:   0x02 (Integer)
      Length: 0x00000004 (4 bytes)
      Value:  0x00000000 (0)

예제 1: KMIP Request Message

주요 타입(Type) 값

0x01: Structure
0x02: Integer
0x03: Long Integer
0x04: Big Integer
0x05: Enumeration
0x06: Boolean
0x07: Text String
0x08: Byte String
0x09: Date-Time
0x0A: Interval

주요 태그(Tag) 값

0x420078: Request Message
0x420077: Request Header
0x420085: Protocol Version
0x420086: Protocol Version Major
0x420087: Protocol Version Minor

TTLV 포맷을 사용하면 KMIP 메시지를 구조적으로 표현할 수 있으며, 각 필드가 어떤 데이터인지 명확히 식별할 수 있습니다. 이를 통해 키 관리 시스템과 클라이언트 간의 상호 운용성을 효과적으로 유지할 수 있습니다.

TTLV 예제 화면

TTLV 특성

KIMP (Key Information Management Protocol)의 TTLV (Tag-Length-Value) 형식에서, 길이는 8의 배수로 정의되어 있습니다. 이는 KIMP 표준의 특정 요구사항으로, 데이터 구조의 정렬을 보장하고 효율적인 처리를 가능하게 하기 위함입니다. TTLV 형식에서 Tag는 3바이트, Type은 1바이트 Length는 4바이트로 고정되어 있으며, Value의 길이는 8바이트의 배수로 패딩됩니다. 이를 통해 전체 TTLV 구조의 길이는 항상 8의 배수가 됩니다.

DH 알고리즘이란

JayKim — Fri, 28 Jun 2024 17:36:27 +0900

이글은 ChatGPT 문의 내용에 일부 수정 하였습니다.

디피-헬만(Diffie-Hellman) 알고리즘은 두 파티가 안전하지 않은 채널을 통해 비밀 키를 공유할 수 있게 해주는 암호학적 프로토콜입니다. 이는 키 교환 알고리즘의 한 종류로, 주로 공개키 암호 시스템에서 사용됩니다. 이 알고리즘은 Whitfield Diffie와 Martin Hellman에 의해 1976년에 제안되었습니다.

주요 개념 및 원리

수학적 기초:
- 디피-헬만 알고리즘은 이산 로그 문제의 어려움에 기반합니다. 이 문제는 큰 소수 p와 원시근 g가 주어졌을 때,
  $$ g^a \, mod \, p $$
  값을 아는 것이 a를 찾는 것보다 계산적으로 훨씬 쉽다는 점을 이용합니다.
작동 원리:
- 두 파티 A와 B가 있다고 가정합니다. A와 B는 다음과 같은 과정을 통해 비밀 키를 공유합니다:
  1. 공개 파라미터 선택: p (큰 소수)와 g (원시근)를 공개적으로 선택합니다.
  2. 개인 키 선택: A와 B는 각각 비밀 개인 키 a와 b를 선택합니다.
  3. 공개 키 계산:
    - A는
      $$ g^a \, mod \, p $$
      를 계산하여 공개합니다.
    - B는
      $$ g^b \, mod \, p $$
      를 계산하여 공개합니다.
  4. 공유 비밀 키 계산:
    - A는
      $$ (g^a \, mod \, p)^a $$
      를 계산합니다.
    - B는
      $$ (g^b \, mod \, p)^b $$
      를 계산합니다.
  - 두 계산은 동일한 값을 가지며, 이 값이 두 파티가 공유하는 비밀 키가 됩니다.

디피-헬만 알고리즘 단계

공개 파라미터: p와 g 선택
- p는 큰 소수입니다.
- g는 p에 대한 원시근입니다.
개인 키 생성:
- A는 개인 키 a를 비밀리에 선택합니다.
- B는 개인 키 b를 비밀리에 선택합니다.
공개 키 교환:
- A는 공개 키
  $$ A = g^a \, mod \, p $$
  를 계산하고 B에게 보냅니다.
- B는 공개 키
  $$ B = g^b \, mod \, p $$
  를 계산하고 A에게 보냅니다.
공유 비밀 키 계산:
- A는
  $$ (B^a \, mod \, p) = (g^b \, mod \, p)^a = g^{ab} \, mod \, p $$
  를 계산합니다.
- B는
  $$ (A^b \, mod \, p) = (g^a \, mod \, p)^b = g^{ab} \, mod \, p $$
  를 계산합니다.
- 결과적으로, A와 B는 동일한 공유 비밀 키
  $$ K=g^{ab} \, mod \, p $$
  를 얻게 됩니다.

장점

보안성: 디피-헬만 알고리즘은 이산 로그 문제의 계산적 어려움에 기반하므로, 충분히 큰 숫자를 사용할 경우 안전합니다.
비대칭적 접근: 이 알고리즘은 두 파티가 서로의 개인 키를 알 필요 없이 안전하게 비밀 키를 공유할 수 있게 해줍니다.

단점

중간자 공격(MITM): 기본 디피-헬만 알고리즘은 인증 절차가 없기 때문에 중간자 공격에 취약할 수 있습니다. 이를 방지하기 위해 추가적인 인증 메커니즘이 필요합니다.
긴 키 길이: 충분한 보안을 위해서는 긴 키 길이가 필요하며, 이는 계산 복잡성을 증가시킵니다.

응용

SSL/TLS: 웹 브라우저와 서버 간의 안전한 통신을 위해 디피-헬만 키 교환이 자주 사용됩니다.
VPN: 가상 사설망(VPN)에서 두 지점 간의 안전한 키 교환을 위해 사용됩니다.
메시지 암호화: PGP와 같은 시스템에서 디피-헬만 알고리즘을 사용하여 메시지를 안전하게 암호화하고 키를 교환합니다.

디피-헬만 알고리즘은 현대 암호학에서 매우 중요한 역할을 하며, 다양한 보안 프로토콜과 시스템에서 널리 사용되고 있습니다.

[BerEditor] 큰수(Big Num) 계산기로 RSA 키쌍 및 암복호화 연산

JayKim — Thu, 27 Jun 2024 17:51:58 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

RSA 기술에서 암호화 연산에는 아주 큰 숫자 연산 및 모듈라 연산이 주로 사용된다.
이 연산을 하기 위해서 BerEditor 메뉴에서 BN Calculator 를 이용하면 된다.

계산기에서 지원 하는 Base Group 에서 연산 방식은 3가지 이다.

- Number : 일반 정수 연산
- Modular : 모듈라를 이용한 연산
- GF2m : 갈루아 필드를 이용한 GF(2^m) 연산

이렇게 3가지 메뉴가 있다.
여기서 RSA 키상을 만드는것은 Number와 Modular 방식을 사용한다.
그리고 테스트로 사용하는 숫자 값은 헥사 표기이다.

계산기에서 입력값의 길이(오른쪽 읽기 표시)는 단순 문자의 개수이다.

보통 RSA 키 쌍은 두개의 큰 소수 P와 Q 를 만들고 이 값을 가지고 개인키와 공개키를 얻을 수 있다.
즉 큰 소수 P 와 Q를 노출은 곧 개인키를 노출되는 것으로 보면 되다.
그리고 공개로 PublicExponent 는 e = 010001 ( 10진수 65537) 을 사용한다.

여기 예제에서는 이해를 위해 짧은 키 길이 P와Q 256 비트를 사용한다.
즉 P와Q가 256 비트를 사용한다는 것은 P*Q 의 결과인 N이 512비트가 되어서 RSA 512 비트 키를 사용하는 것이다.

큰 소수 P와 Q 생성 및 공개키 구하기

A : P 소수 생성 값
B : Q 소수 생성 값
A x B 버튼 : N값 구하기

그럼 N 값을 만들기 위해서는 P * Q 이므로 A * B 버튼을 눌러 주자
생성된 값

P (A 값) = D957E9E5E313B9E6EF0A112875037F227015BF81D235C61316E0F1CA10E5DFFD

Q (B 값) = C5C989AF683037D7D8D40BD1C47D2DAB5BFBF5B55CC5423E73804AC036C4B65B

N ( Result 값 ) = A7EBC1E984F70A21D8C3B8298D67B56CF10B796531FDBC8C096A0E97EFB33893FCF08CAFC79A3389B010F68447AC8A86D55BFB211FB5E28A90C827D64AA87CEF

여기서 계산된 ( e, N ) 값이 RSA 공개키 값이 된다.
만약 이미 만들어지 P와 Q값을 이용시는 A와 B영역에 복사해서 넣어 주어도 된다.

RSA 개인키를 구해 보자

개인키를 구하는 공식은 다음과 같다
$$ d ≡e^{-1} \, mod \, (n) $$
먼저 개인키를 구하기 위해서 ϕ(n)=(p−1)×(q−1) 값을 구하자

참고로 실제 2048 Bits 이상의 개인키를 구하는 공식은 FIPS-186-4 에서는 아래 공식을 사용해야 한다.
$$ d ≡e^{-1} \, mod \, LCM(p-1, q-1) $$

LCM 구하기 참고

여기서는 예제로 위의 방식을 사용하였다.

A 값에서 -1 버튼 을 누르면 (p-1) 계산
B 값에서 -1 버튼 누른면 (q-1) 계산
A x B 클릭 : ϕ(n) 값을 구하게 된다.

(P-1) = D957E9E5E313B9E6EF0A112875037F227015BF81D235C61316E0F1CA10E5DFFC

(Q-1) = C5C989AF683037D7D8D40BD1C47D2DAB5BFBF5B55CC5423E73804AC036C4B65A

ϕ(n) 결과값 = A7EBC1E984F70A21D8C3B8298D67B56CF10B796531FDBC8C096A0E97EFB338925DCF191A7C5641CAE832D98A0E2BDDB9094A45E9F0BADA390666EB4C02FDE698

개인키 d 값을 구하기

위 ϕ(n) 값을 M에 입력 그리고 A 에는 e값인 010001 입력후 A^-1 Mod M 버튼을 클릭 하면 개인키 d 값이 나온다.

E (A값) = 010001 ( 10진수 65537 )

ϕ(n) (M값) = A7EBC1E984F70A21D8C3B8298D67B56CF10B796531FDBC8C096A0E97EFB338925DCF191A7C5641CAE832D98A0E2BDDB9094A45E9F0BADA390666EB4C02FDE698

d (결과값) = 030E869C22A0809DB71D70F7C8AC2FA0490F0569B32C444764507AED871E83141F030B18F1547CA41DEFF707CD543D18063444EB8A474C7BA7432E5B56DE9A59

RSA 암호화

암호화 공식은 C = M^e mod N 이다.
RSA 암호화는 공개키 값만으로 만드는 값이다. 일반적으로 수신자의 공개키를 이용해 암호화 한다.
예제로 사용하는 메세지로 헥사 값 12345678 을 사용해서 암호화 해 보자

Message (A값) = 12345678  
e (B값) = 010001  
N 값 (M값) = A7EBC1E984F70A21D8C3B8298D67B56CF10B796531FDBC8C096A0E97EFB33893FCF08CAFC79A3389B010F68447AC8A86D55BFB211FB5E28A90C827D64AA87CEF

Cipher값 (Result값) = 50325882778093FD69C8A37D1B1FFCD8D60099D2DCEFBC3A6EADFF0EBD7B27320CAF505E81F8660C9534A49E2ECED3EC2EE928A7AC446FE5AA237CAEA0360F55

RSA 복호화

복호화 공식은 M = C^d mod N 이다.
RSA 복호화는 개인키를 이용해 복호화 하게 된다.
그럼 암호문을 가지고 원문을 구해 보자.

Cipher (A값) =50325882778093FD69C8A37D1B1FFCD8D60099D2DCEFBC3A6EADFF0EBD7B27320CAF505E81F8660C9534A49E2ECED3EC2EE928A7AC446FE5AA237CAEA0360F55

d (B값) = 030E869C22A0809DB71D70F7C8AC2FA0490F0569B32C444764507AED871E83141F030B18F1547CA41DEFF707CD543D18063444EB8A474C7BA7432E5B56DE9A59

N ( M값) = A7EBC1E984F70A21D8C3B8298D67B56CF10B796531FDBC8C096A0E97EFB33893FCF08CAFC79A3389B010F68447AC8A86D55BFB211FB5E28A90C827D64AA87CEF

Plain (결과값) = 12345678

위 공식대로 값을 계산하게 되면 결과인 원문 12345678 을 구할 수 있다.

마무리

빅넘 연산기를 이용하여 간단히 RSA 키 쌍을 만들어 보았다.
이렇게 큰 소수 P 와 Q를 값을 알게 되면 개인키와 공개키를 구해지므로 p와 q값은 개인키와 같은 노출 되어서는 안되는 값이 된다.
여기서는 설명을 위해 512 비트의 짧은 길이를 사용 하였지만 실제에서는 2048 비트를 사용한다.
2048 비트로 테스트 할려면 위 설명에서 소수값 P와 Q생성 시 1024 비트를 선택 하여서 똑같이 하면된다.

RSA 개인키 특성

JayKim — Fri, 31 May 2024 14:18:58 +0900

RSA 키 쌍에서 개인키 파일을 알아 보자
일반적으로 개인키는 암호화 되어 있지만 암호화 되지 않은 형식은 PKCS#1 에서 정의 된 형식을 가지고 만들어져있다.

보통 RSA 연산에서 사용 되는 키 값은 n, e, d 이다.
여기서 보통 (n, d) 값이 개인키 이고 (n, e) 값을 공개키로 흔히들 말한다.

그럼 PKCS#1 형식의 개인키를 BerEditor로 보면 다음 그림과 같다.

RSA 개인키 화면

보통 개인키 파일에는 개인키와 공개키 값이 모두 들어가 있는데
왜 n, e, d 값 왜에 다른 값이 더 있는 것을 볼 수 있다.
이 값들은 PKCS#1 에 정의 된 ASN.1 값을 참조 하면 아래와 같다.

RSA 개인키 ASN.1

         RSAPrivateKey ::= SEQUENCE {
             version           Version,
             modulus           INTEGER,  -- n
             publicExponent    INTEGER,  -- e
             privateExponent   INTEGER,  -- d
             prime1            INTEGER,  -- p
             prime2            INTEGER,  -- q
             exponent1         INTEGER,  -- d mod (p-1)
             exponent2         INTEGER,  -- d mod (q-1)
             coefficient       INTEGER,  -- (inverse of q) mod p
             otherPrimeInfos   OtherPrimeInfos OPTIONAL
         }

위 ASN.1 값을 보게 되면 p, q, d mod (p-1), d mod (q-1), inverse of q mod p 값이 더 있다.
그럼 각각의 값에 대해서 알아 보자.

RSA 개인키 값

version : 0 으로 고정 값
modulus (n) : p * q 값
publicExponent (e) : 소수 공개키 값
privateExponet (d) : 개인키 값
prime1 (p) : 임의의 소수 p
prime2 (q) : 임의의 소수 q
exponent1 ( d mod (p-1) ) : CRT 지원값
exponent2 ( d mod (q-1) ) : CRT 지원값
coefficient ( ( inverse of q ) mod p ) : CRT 지원 값

이렇게 구성 된다.
사실 exponent1, exponent2, coefficient 값은 없어도 암/복호화는 가능하다.
하지만 이 값들이 존재 하는 이유는 중국인의 나머지 정리 이론을 적용하여 연산을 하기 위한 것이다.
즉 중국인의 나머지 정리 (Chinese Remainder Theorem) 연산을 하면 그만큼 암호화 복호화 연산에 빠른 계산을 할 수 있기 때문이다.

보통 2048 bit 의 RSA 키라고 말하면 n 값의 길이를 말한다.
그래서 n 값읜 길이는 p * q 이므로 p 와 q는 값의 길이는 n 길이의 1/2 이 된다.

사실 RSA 개인키에서 p 와 q 값이 알려지면 개인키를 쉽게 구할 수 있어서 p 와 q의 값은 개인키와 같이 노출이 되면 안되는 값이다.
공개키에서 사용하는 e 값의 경우 거의 모든 인증서들이 65537 고정 소수를 사용한다.
그러니 e 값과 n 값은 쉽게 구할 수 있다.

개인 키 d는

$$ d×e≡1 \, mod \, ϕ(n) $$
$$ d ≡e^{-1} \, mod \, (n) $$

이렇게 계산 할 수 있다.
확장 유클리드 호제법을 통하여 개인키를 구할 수 있다.
여기서 ϕ(n)=(p−1)×(q−1) 이다.
즉 p와q를 알면 이렇게 개인키를 구 할수 있다.

사실 n 값은 공개 키로 공개된 n = p * q 값이지만 사실 n 값만 알 때 소수인 p 와 q 값을 구하기는 어렵다
이것이 RSA 의 인수 분해 어려움의 문제이다.

마무리

여기서 RSA 개인키 파일에서 기록되어진 값들에 대한 정리를 하여 보았다.
RSA 개인키에는 실제 개인키 값 뿐만 아니라 공개키 값이 존재 한다는 것과
CRT 연산을 위한 값을 가지고 있어서 RSA 암/복호화를 좀 더 빠르게 하기 위한 값이 있다는 것이다.

혹시나 RSA 개인키 파일을 문제가 없는지 알기 위해서는 어떤 값들이 사용 되는지 알 필요가 있다.

무료 라이선스(30일) 발급 하기

JayKim — Sun, 21 Apr 2024 23:28:52 +0900

BerEditor, CertMan 그리고 CryptokiMan은 온라인으로 30일 단기 라이선스 발급을 지원합니다.
온라인 단기 라이선스 발급을 지원하는 버전은 모두다 Version 1.8.0 이상에서만 지원 합니다.

이미 라이선스를 발급 후 만료 되어도 계속 다시 받을 수 있습니다 (많이 써주세요^^)
사이드 프로젝트로 만들다 보니 비용 문제로 코드 서명은 안되어 있지만 악성코드 프로그램은 아닙니다.
입력한 메일 주소는 라이선스 발급 정보에만 사용되며 다른 용도로는 사용 되지 않습니다.

온라인 라이선스를 발급 받기 위해서는 이메일등록, 메일에서 발급키 확인, 발급키 적용 단계로 이루어 집니다.

1.이메일 등록 하기

[라이선스 발급] 여기서 메일 주소와 사용 프로그램을 선택 요청 합니다.
요청 시 바로 등록한 메일 주소로 라이선스 발급키를 보내니 메일을 확인 해주세요

2. 메일 발급키 확인

등록한 메일 내용에서 라이선스 발급키를 확인 합니다.
혹시 스팸으로 갈지도 모르니 안오게 되면 스팸 상자 확인 해보세요

3. 발급키 프로그램 적용

프로그램 라이선스 정보에서 이메일과 키 정보를 입력 후 가져오기 실행 합니다.
이렇게 하면 30일간 라이선스 적용된 기능을 사용할 수 있습니다.
기간이 지나면 다시 요청도 가능 합니다.

라이선스 적용 하기

Email 에 등록한 메일 주소
License Key : 는 메일 내용에 나오는 license key 값을 입력 후 가져오기(Get) 버튼을 누르면 된다.

마무리

그동안 라이선스를 요청하면 개인적으로 전달 해주었는데..
이제 온라인 라이선스 발급 기능을 구현하여서 이제 수동으로 메일로 보낼 필요가 없어져서
누구든 필요 하면 바로 발급 할 수 있게 되었습니다

KMIP 프로토콜에 관하여

JayKim — Thu, 4 Apr 2024 16:46:04 +0900

PKI 관련 개발을 하다 보면 가장 중요하게 관리 되어야 하는게 키 관리이다.
이 키 관리를 하기 위해서 키 관리 시스템이라고 부르는 KMS를 두고 키를 관리 한다.
키 관리 시스템경우 다양하게 만들어져 있다 보니 키 관리 시스템에 대한 표준이 필요하다고 생각하여서 알게 된것이 KMIP 이다.

[자료 출처] https://stormagic.com/resources/beginners-guides/kmip-beginners-guide

아래 글은 위의 자료 출처의 글을 번역 한것이다.

KMIP 란 무엇인가?

간단히 말해서, KMIP(Key Management Interoperability Protocol)는 플랫폼 전반에 걸쳐 안전한 데이터 관리를 위한 표준 프로토콜입니다. 이는 키 관리 시스템과 암호화 지원 애플리케이션(예: 이메일, 저장 장치, 데이터베이스) 간의 통신을 가능하게 하기 위한 목적으로 OASIS(Organization for Advancement of Structured Information Standards)에서 만들게 되었습니다.

많은 조직의 암호화 키 관리를 표준화 간소화하여 중복되고 호환되지 않는 키 관리를 하지 않기 위해서 만들어 졌습니다.
KMIP는 대칭 키, 비대칭 키, 디지털 인증서 및 기타 공유 비밀을 지원하는 기존 및 새로운 암호화 지원 애플리케이션을 모두 지원합니다.

KMIP 는 어떻게 작동하나?

KMIP는 저장된 데이터의 암호화 및 암호화 키 관리를 위한 개방형 표준 기반 방법입니다.
KMIP 이전에는 서로 다른 플랫폼과 공급업체가 서로 다른 언어를 사용하는 경우가 많았으므로 이러한 환경 간의 다양한 보안 통신 회선을 관리하기 위해 인프라, 운영 및 교육 비용이 증가해야 했습니다.
KMIP는 성능에 영향을 주지 않고 특정 애플리케이션의 키 관리를 추상화하고 관리 시스템을 중앙 집중화함으로써 다양한 키 관리 환경이 공통 언어를 사용할 수 있도록 보장합니다. 균일한 인터페이스를 활용하면 암호화가 활성화된 다양한 애플리케이션 간의 통신이 가능해지며 키 관리가 단순화되고 불필요하고 호환되지 않는 프로세스가 제거됩니다.

IBM, Dell, HPE 및 Oracle과 같은 기술 부문의 리더들은 KMIP를 채택했으며 다른 벤더 및 플랫폼도 이를 따랐습니다.
이 모든 것이 KMIP를 사실상의 업계 표준으로 만들었습니다. 그러나 KMIP는 업계 표준 그 이상으로 조직의 요구 사항을 충족할 수 있는 보다 효율적이고 호환 가능한 도구를 제공합니다. 실제로 이는 조직 데이터의 무결성을 유지하는 것뿐만 아니라 플랫폼과 공급업체 전반에 걸쳐 여러 키 관리 시스템을 통합하고 기술 인프라의 비용 효율성을 유지하는 데 핵심입니다.

KMIP 의 장점은?

KMIP는 암호화와 키 관리 시스템 간의 통신을 표준화합니다. KMIP를 지원하는 암호화 키 관리 솔루션을 구현하는 조직은 다음과 같은 이점을 실현합니다.

Simplicity

오늘날 조직은 IT 보안 구성을 구현하는 데 있어 여러 가지 과제에 직면해 있습니다. 여러 공급업체와 기술이 관련되면 보안 인프라가 빠르게 복잡해지고 관리가 어려워집니다. 이는 암호화 및 키 관리의 경우 특히 그렇습니다. 때로는 개별 암호화 애플리케이션마다 다른 키 관리자가 필요한 경우가 있습니다. KMIP는 단일 키 관리 시스템이 KMIP를 채택한 모든 암호화 시스템의 키를 관리할 수 있도록 하여 이 문제를 해결합니다. 이를 통해 기업은 IT 보안 시스템에 집중하는 시간을 줄이고 중요한 비즈니스, 즉 비즈니스에 더 많은 시간을 할애할 수 있습니다.

Cost-Effective

오늘날 많은 기업은 딜레마에 직면해 있습니다. 제한된 예산으로 조직의 귀중한 데이터를 어떻게 충분히 확보하고 보호할 수 있습니까? 여러 공급업체의 다양한 기술을 구현해야 하면 비용이 빠르게 추가되고 엄청난 비용이 들 수 있습니다. KMIP를 지원하는 암호화 키 관리자를 활용함으로써 조직은 자산을 안전하게 유지하는 데 필요한 장비와 소프트웨어의 양을 줄이고 비용도 절감할 수 있습니다. KMIP를 사용하면 환경 내의 중복성을 제거하고 단일 인터페이스를 통해 모든 암호화 애플리케이션을 관리할 수 있습니다.

Flexibility

KMIP 이전에는 조직의 IT 환경 내에서 각각의 개별 암호화 애플리케이션을 관리하기 위해 다른 독점 KMS가 필요했습니다. 기업은 특정 환경 및 구성에 맞게 특별히 설계된 암호화 공급업체와 협력하도록 제한되었습니다. KMIP는 조직이 원하는 핵심 관리 공급업체를 활용할 수 있는 유연성을 제공했습니다. 조직의 인프라가 KMIP를 지원하는 한 하나의 핵심 관리자를 통해 엣지, 클라우드 또는 온프레미스 전반에 걸쳐 통합을 지원할 수 있습니다.

마무리

KMIP 는 키 관리 시스템의 표준 프로토콜이다. TTLV 인코딩 방식을 이용하여 표준 프로토콜을 만든것이다.
사실 키 관리 시스템이 다양해서 키관리시스템마다 연동을 해야 하는 복잡한 부분이 있어서
이 부분의 표준이 필요하다고 생각한다.
그리고 그 표준이 KMIP 이다.

[KMIP 표준 Version 2.1]

[OpenSSL] ECDH 키 유도 (Derive Key) 명령어

JayKim — Wed, 3 Apr 2024 11:14:07 +0900

OpenSSL 명령어를 사용해 ECDH 공유 키를 만들어 보자

ECDH 값을 생성 하기 위해서는 두 쌍의 ECDSA 용 키 쌍이 필요하다.
키 쌍의 이름을 alice 와 bob 이라는 이름 으로 만들어 보자

그럼 ECDH 공유 키를 만든는것은 alice 의 개인키와 Bob의 공유키를 이용해서 만들고
또 bob의 개인키와 alice 의 공유키를 가지고 만들게 되는데
이때 서로 만든 공유키 값이 같은 값이 나오게 되는 것이다.

Alice ECDSA 용 키 쌍 만들기

// ECDSA 용 alice의 개인키 만들기
openssl genpkey -out alice.pem -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -pkeyopt ec_param_enc:named_curve

// alice 의 개인키에서 공개키 구하기
openssl pkey -pubout -in alice.pem -out alice.pub

algorithm : EC 알고리즘 사용
ec_paramgen_curve : EC 커브 알고리즘 P-256 사용
ec_param_enc : 파라미터의 네임드 방식의 인코딩

이렇게 하면 alice.pem 개인키 파일과 alice.pub 의 공개키가 PEM 형식으로 만들어 진다.

Bob ECDSA 용 키 쌍 만들기

// ECDSA 용 bob의 개인키 만들기
openssl genpkey -out bob.pem -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -pkeyopt ec_param_enc:named_curve

// bob 의 개인키에서 공개키 구하기
openssl pkey -pubout -in bob.pem -out bob.pub

Alice 와 동일하게 bop.pem 개인키 파일과 bob.pub 공개키가 PEM 형식으로 만들어 진다.

Alice 공유키 계산하기

openssl pkeyutl -derive -out alicebob.key -inkey alice.pem -peerkey bob.pub

alice 는 bob의 공개키와 alice 개인키를 이용하여
alicebob.key 파일이 바이너리로 공유 키 값이 생성 된다.

Bob 공유키 계산하기

openssl pkeyutl -derive -out bobalice.key -inkey bob.pem -peerkey alice.pub

bob 은 alice 의 공개키와 bob 개인키를 이용하여
bobalice.key 파일에 바이너리 공유 키 값이 생성 된다.

공유키 비교

cmp alicebob.key bobalice.key

두 파일을 비교시 동일한 내용의 바이너리 이므로 아무 표시가 없다.
만약 다른 점이 있다면 다른 부분에 대한 내용을 표시 하게 된다.

마무리

ECDH 알고리즘은 ECDSA용 키 쌍을 이용하여 공유키를 구하는 알고리즘이다.
보통은 이렇게 ECDH 공유 값을 구해서 KDF 를 이용해 서로의 비밀키를 만들어 사용된다.

[BerEditor] VID 생성 및 검증 하기

JayKim — Wed, 20 Mar 2024 15:15:47 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

일반적 인증서에서는 사용 하지 않지만 우리 나라에서 사용하는 공동 인증서만의 고유 필드가 있는데
그것이 VID 값이다. 이 값은 인증서의 주체 대체 이름 필드에 들어 가는 값이다.

VID 관련 기술 스펙은 [X509] 공동인증서 본인확인 식별번호 ( VID ) 란? 페이지를 참조 하면 된다.

VID 생성 하기

BerEdior 에서 Cryptogram -> VID 메뉴를 선택 하면 아래 그림 처리 VID 창이 뜬다

VID 생성 화면

VID 값을 생성 하기

SSN 값 입력 ( SSN 은 보통 주민번호 같은 고유 구별 값 )
Random 값 입력 ( VID 생성에 같이 사용 되어지는 랜덤 값 )
VID 생성 버튼 입력 ( 이때 VID 생성을 위해서는 해쉬가 사용 되는데 사용 해시를 선택 해야 함 )

여기서 보여주는 HashContent 값은 내부적으로 만들어 진 값이다.(입력 값 아님)

BerEditor 로그 메세지

== Make VID Information
SSN : 12345678abcdefgh
Random : 112233445566778899AA112233445566778899AA
Hash : SHA256
HashContent: 3029131031323334353637386162636465666768031501112233445566778899AA112233445566778899AA
VID : 3031300B0609608648016503040201A0220420ED56F9A5CF5AD8550D22BC4FCB57DDB8D5A02899636319726FC4A8554BCAF1CD

이렇게 VID 생성을 하면 VID 값이 만들어 진다.
일반적으로 Random 값 경우 검증 대상자가 생성시 만들어지 값을 알고 있어야 한다. 검증시에서도 동일 하게 필요하기 때문이다.

VID DER 데이타 화면

VID 정보에는 사용 해시 알고리즘과 해시 값이 있다.

VID 생성에 사용되는 Hash Content 화면

VID 해시값을 만들때 사용하는 해시에 사용된 값을 보면 SSN (PrintableString) 값과 Random (BitString) 값을 DER 형식으로 인코딩 되어 있다.

VID 검증 하기

VID 검증 하기

SSN 값 입력
Random 값 입력
VID 값 입력
Verify VID 버튼 클릭

VID 검증에서는 특별히 Hash 선택은 사용 안한다. VID 값에 Hash 대한 OID 값을 읽어서 해당 해시 알고리즘을 사용한다.
여기서 보여주는 HashContent 값은 내부적으로 만들어 진 값이다.(입력 값 아님)

BerEditor 로그 메세지

== Verify VID Information
SSN : 12345678abcdefgh
Random : 112233445566778899AA112233445566778899AA
VID : 3031300B0609608648016503040201A0220420ED56F9A5CF5AD8550D22BC4FCB57DDB8D5A02899636319726FC4A8554BCAF1CD
HashContent: 3029131031323334353637386162636465666768031501112233445566778899AA112233445566778899AA
VID verification successful

사실 VID 검증을 위해서는 SSN, Random, VID 값 모두 필요하다.
왜냐하면 VID 검증을 하기 위해서 SSN 과 Random 값을 이용해 VID 에 사용한 해시 알고리즘을 읽어서 VID 를 다시 만들어 결과가 동일 한지 판단하는 것이기 때문이다.

마무리

공동인증서에는 주민등록 번호나 회사 법인 번호를 SSN 으로 사용하여 Random 값을 이용해 만든 VID 값이 들어가 있다.
이 VID 값을 검증 하기 위해서는 해당 SSN 값은 개인이 알지만 Random 값 경우는 공동인증서의 해당 개인키 파일에 같이 들어가 있다.
그래서 VID 검증이 가능한 것이다. 일반적으로 SSN 값 만으로는 VID 검증은 할 수 가 없다.
즉 VID 값은 SSN 값을 알고 랜덤값을 가진 사람이 자기 인증서인지 확인 할 수 있는 것이다.

오픈소스 사용에 대한 라이선스 처리

JayKim — Mon, 11 Mar 2024 14:53:13 +0900

여기서 만든 내 프로그램들(BerEditor, CertMan, CryptokiMan) 은 오픈소스를 이용하여 만들었다.
오픈소스의 경우 소스를 자유롭게 참조 하고 사용 할 수 있지만 프로그램을 만들어서 배포하는 경우
해당 라이선스에 따라 지켜야 하는 의무 사항이 존재 하는 프로그램이다.
(물론 개인적으로만 사용하는 경우는 의무 사항이 없다. 하지만 배포 하는 경우 지켜야 한다)

사이드 프로젝트로 만든 여기 프로그램 경우 일부 소스는 공개를 하였지만
전체 소스 공개를 요구하는 GPL 라이선스 모듈은 배포시 포함 하지 않았다.
즉 소스 공개에 대해서는 개인적으로 제한 받지 않기 위해서이다.
( 테스트 용도로만 GPL 라이브러리는 사용중이다^^)

그리고 자체 개발한 소스에 대해서는 저작권 표시를 해주는게 필요하여 저작권 표시를 해주었다.
내 프로그램 개발 시 가장 많이 사용되는 오픈 소스는 OpenSSL 과 QT 라이브러리이다.

OpenSSL 경우 Apache-2.0 라이선스를 이용하고
QT 경우 LGPLv3 or GPLv3 버전을 이용하는데 가능한한 GPLv3 기능은 내부 테스트용으로 이용하고 배포에는 배제 하였다.
( GPLv3 을 사용하면 소스 공개에 대해서 의무 사항이기 때문)

그 외에 다양한 오픈소스도 참조 하였는데 수정 및 변경 사용에 문제가 없는 MIT 라이선스 또는 Public 라이선스를 사용하였다.
(이들 라이선스 경우 사용 고지는 해야 한다)

OpenSSL 사용시 지켜야 할 사항

기본적으로 OpenSSL 경우 Apache 2.0 라이선스는 자유롭게 수정 및 소스공개 없이 사용 가능하다.
그리고 LGPL-3.0 라이선스와 같이 사용에 문제가 없다.
하지만 해당 오픈소스를 사용하는것을 고지 해 주어야 한다.

OpenSSL 경우 개인적으로 소스를 패치 하여서 사용하였지만 현재 OpenSSL 의 패치 없이 사용하도록 변경을 하고
About 창에서 OpenSSL 을 동적링크를 이용하여 사용한다는 것을 표시 하였다.
Apache-2.0 라이선스에서 변경 사용하는 경우 변경 내용에대한 고지는 하여야 한다.

QT 사용시 지켜야 할 사항

QT 경우 GPL 또는 LGPL 라이선스를 요구하는데 사용하는 모듈이 모두 LGPL 이면 LGPL 라이선스 요구 사항에 따라 소스를 공개 하지 않아도 된다. 하지만 사용하는 모듈 중에 GPL 이 존재 한다면 소스를 공개해야 하는 의무 사항이 따른다
GPL 라이선스중 대표적인게 QtChart 모듈 경우이다.(물론 상용으로 사용하면 소스 공개 제한은 없다^^)

그래서 BerEditor, CertMan 그리고 CryptokiMan 은 사실 UI 개발에 LGPL 라이선스용 모듈만을 이용하여 개발 하였다.
QT 또한 About 창에서 QT를 동적링크를 이용하여 사용한다는 것을 표시 하였다.

사실 LGPL 경우 소스를 변경하게 되면 LGPL 소스 변경에 대한 공개의 의무가 있다.
하지만 QT 에서 제공하는 동적라이브러리 상태로 소스 변경 없이 사용하게 되면 소스 공개 없이 사용 할 수 있다.
(만약 정적 라이브러리로 개발 하면 소스를 변경 하지 않아도 추가적으로 제공 해야 하는 의무 사항이 더 있게 된다)

MIT 또는 공개 라이선스

내부적으로 SSS 또는 Sparkle 등 MIT 라이선스 모듈등 여러가지 공개된 오픈소스가 사용되었는데
필요한 경우 소스를 변경 하였지만 소스내에 저작권 표시는 그대로 유지 하여 변경 하였다.
그리고 이들 라이선스에서는 자유롭게 소스 변경을 하여 사용 할 수 있지만 사용하고 있다는 고지는 해야한다.
그래서 이들 모두 About 창에서 사용하는 저작권 표시를 해주었다.

내프로그램에 대한 저작권

다음 내용이 해당 프로그램 저자권에 대한 고지 사항 내용이다.
해당 프로그램 사용시 저작권 및 보증에 대한 책임이 없음을 명시하는 내용이다.
(개인적으로 아래 영어 문구 해석하기 너무 어렵네요)

내프로그램 저작권 및 고지 의무 사항

- 자체 개발 소스 저작권 표시

만든 소스 저작권 표시

사용한 오픈소스에 대한 저작권 표시

아래 내용이 사용된 오픈소스와 해당 저작권 정보 및 링크를 표시 하였다.

오픈소스 사용 고지 사항

프로그램 패키지 고지 의무

현재 배포한 프로그램을 설치 하면 COPYRIGHT 파일과 thirdparty_license 폴더에 사용한 오픈소스 라이선스 정보 파일을 모두 같이 패키지 하였다.

내프로그램 오픈소스 처리 요약

Apachec-2.0 과 LGPL-3.0 모듈은 변경 없이 동적 링크 사용
GPL 라이선스 모듈 사용 안함
MIT 라이선스 경우 소스 변경 사용 및 소스내 저작권 표시 유지
자체 개발 소스 내 저작권 표시
About 창에 프로그램 저작권 표시 및 사용 오픈 소스 출처 및 저작권 표시
해당 패키지에 COPYRIGHT 및 사용 오픈 소스 라이선스 파일 포함

마무리

지금까지 개인적으로 프로그램을 아무 제한 없이 사용할때는 라이선스 의무 사항을 고려하지 않았지만
최근에 배포를 하다 보니 오픈소스에 대한 준수 사항를 검토 하여서 처리를 하였다.
사실 검토 하다 보니 오픈소스 고지 의무가 생각보다는 어렵다는 생각이 든다 특히 라이선스 충돌 문제 같은경우
나름 판단해서 준비를 하였지만 혹시 더 필요한게 있는지는 모르겠다.

혹시라도 부족한게 있음 알려주세요^^

QT 및 윈도우 개발(MSYS2) 환경 설정

JayKim — Wed, 6 Mar 2024 09:31:44 +0900

QT 설치

다운로드 : https://www.qt.io/download-open-source
이곳에서 화면 아래 "Download the Qt Online Installer" 를 클릭 후 OS 환경에 맞는 온라인 설치 파일을 다운 받아 설치 하면 된다.

QT 설치시 오류가 나면 미러링 이용 설치

일반적으로 QT 설치 파일을 실행하여 가입 후 설치를 할 때 네트워크 오류가 나타나는 경우에는
아래 처럼 --mirror 옵션을 주어서 다운로드 사이트를 변경 하면 된다.

QT 온라인 설치 에러 화면

위와 같은 오류가 발생 하면 아래 처럼 --mirror 옵션을 통해 설치 하면 된다.

./qt-unified-linux-x64-4.5.1-online.exe --mirror https://qt.mirror.constant.com

QT 인스톨 참고 링크 https://wiki.qt.io/Online_Installer_4.x

msys2 설치 후 개발 환경 구축

다운로드 : https://www.msys2.org

윈도우에서 리눅스나 유닉스 환경처럼 shell 을 사용하고 gcc 나 make 를 이용해 개발 하기 위해서 필요한 프로그램이다.
해당 프로그램을 설치 한후 개발 환경 구축을 하기 위해서는 아래 명령어를 추가 한다.

그리고 리눅스나 맥에서 gcc 컴파일러를 사용하다 보니 윈도우도 소스 변경을 최소화 하기 위해 msys2 를 설치해 gcc를 사용하기 위해서 이다.

설치 후 여러가지 실행 아이콘 나오는데 자기가 원하는 아이콘을 선택 하면 된다.
나는 MSYS2 MINGW64 환경을 사용한다.

참고로 ) libtool 과 openldap 의 경우는 필요 한 경우 설치 하면 된다.

pacman -Syu
pacman -S base-devel 

pacman -S mingw-w64-x86_64-gcc
pacman -S mingw-w64-x86_64-make
pacman -S perl
pacman -S zlib-devel

# pacman -S mingw-w64-x86_64-toolchain
// 참고로 개발 패키지는 호환성 충돌로 위 명령어 실행 하지 않게 해야 함

pacman -S libtool
pacman -S mingw-w64-x86_64-openldap
pacman -S cmake git vim
pacman -S make

// 혹시나 설치시 오류가 나면 하나씩 설치 해보면 됨

- msys2 를 이용해 컴파일 환경을 사용하려면 toolchain 을 설치를 해주어 하는 경우 아래 처럼 문제 처리르 해 주면 된다.

toolchain 을 설치 하면 아래 처럼 레퍼런스 오류 경우

crtexe.c:-1: error: undefined reference to `__mingw_init_ehandler'
crtexe.c:-1: error: undefined reference to `__security_init_cookie'
crtexe.c:-1: error: undefined reference to `__security_init_cookie'
crtexe.c:-1: error: undefined reference to `mingw_app_type'
crtexe.c:-1: error: undefined reference to `mingw_initcharmax'
crtexe.c:-1: error: undefined reference to `mingw_initltssuo_force'
crtexe.c:-1: error: undefined reference to `mingw_initltsdyn_force'
crtexe.c:-1: error: undefined reference to `mingw_initltsdrot_force'
:-1: error: collect2.exe: error: ld returned 1 exit status
:-1: error: ninja: build stopped: subcommand failed.

아직 정확한 이유는 알 수 없지만 아마도 사용된 링킹 라이브러리간에 호환성 문제로 보인다.
즉 QT 에서 사용하는 mingw 환경과 msys2 설치로 사용하는 mingw 간에 호환성 문제로 보인다.
현재 이럴 경우 msys2 에서 사용하는 라이브러리 파일만 별도로 복사 해서 msys2 시스템 경로를 제거 해 주면 발생 하지 않음

내부적으로 라이브러리 경로에 옮겨서 설정 경로를 msys2 경로를 보지 않게 해주면 된다.
물론 헤더 파일 경로는 문제가 되지 않는다.

../../lib/win64  <-- 이렇게 별도 폴더를 만들어 경로 설정 함

#"C:/msys64/mingw64/lib"  <-- msys2 에서 해당 경로를 주석으로 막아 줌

# 참고로 별도 폴더에 .a 파일과 .dll.a 파일 모두 복사 해줌

복사한 폴더 명 예제

pacman 사용법


# 시스템 업데이트
$ pacman -Su

# 패키지 검색
$ pacman -Ss [검색단어]

# 설치된 패키지 검색
$ pacman -Qs [갬색단어]

# 패키지 정보 확인
$ pacman -Qi [패키지명]

# 패키지 설치
$ pacman -S [패키지명]

# 패키지 삭제
$ pacman -Rs [패키지명]

마무리

PC용 프로그램을 사용하는 주요 환경은 리눅스, 맥 그리고 윈도우 이다.
사실 리눅스나 맥은 기본적으로 gcc 컴파일 환경이 쉽게 구축이 되구 일반적으로 사용이 된다.

하지만 윈도우에서 gcc 지원과 make 또는 cmake 같은 환경을 쉘로 지원하기 위해 msys2를 사용한다.
이렇게 윈도우도 msys2를 이용해 개발 환경을 가져가게 되면 이 3가지 플랫폼을 지원하기기 용이 하다.
QT의 경우 3가지 플랫폼 모두 지원한다.
이러다 보니 더이상 Visual Studio 더이상 사용 하지 않고 gcc 랑 QT를 이용하여 개발 하게 되었다.

SSL 인증서 및 코드 서명 인증서 용도 확인 방법

JayKim — Tue, 30 Jan 2024 18:26:53 +0900

PKI 시스템에서 사용하는 인증서는 인증서 마다 사용하는 용도가 있다.
그중에서 많이 사용하는 대표적인 인증서의 용도가 SSL 인증서와 코드 서명용 인증서가 있다.

SSL 인증서는 일반적으로 웹서버에서 HTTPS 통신을 하기위해 사용하는 인증서이다.
코드서명 (Code Sign) 인증서는 앱이나 프로그램 또는 라이브러리 같은 바이너리 파일에 위변조를 방지 하기위해
전자 서명을 하기 위해 사용하는 인증서이다.

그럼 SSL 인증서와 코드 서명용 인증서가 맞는지 구별 하기 위해서는
인증서에는 용도별로 인증서가 가져야 하는 필드가 존재한다.
여기서 인증서 정보의 필드를 보기 위해서 BerEditor 를 사용하였다.

인증서 용도 구별 필드

SSL 인증서와 코드 서명 인증서 용도를 구별 하기 위해 확인이 필요한 주요 필드는 2가지 인데
키 용도( keyUsage ) 와 확장 키 사용( Extended Key Usage ) 두 필드 확인을 하면 된다.

키 용도, 확장키 사용 같은 용어는 문서나 프로그램에 따라 조금씩 다르게 표현이 되기도 한다.

기본적으로 SSL 인증서와 코드 서명용 인증서의 KeyUsage 필드에서 Digital Signature 는 필수적으로 있어야 한다.
이 확장 필드는 critical 로 설정 되어야 한다.
SSL 인증서 경우 keyEncipherment 또는 KeyAgreement 값이 설정 되어야 한다.
RSA 인증서 경우 SSL 에서 KeyEncipherment를 사용하고 ECDSA 인증서 경우 KeyAgreement 가 사용되는 것으로 보면 된다.

그리고 ExtendedKeyUsage 필드에서 해당 인증서의 용도가 나와야 하는데
SSL용 서버 인증서는 서버 인증(TLS Web Server Authentication) 필드가 있어야 한다.
코드 서명용 인증서에는 코드 서명( Code Signing) 필드가 있어야 한다.
실제로 해당 값은 용도별 OID 값으로 만들어져 있다.

ExtendedKeyUsage 실제 OID 값 예제

SSL 인증서 구별 요소

KeyUsage : Digital Signature 그리고 Key Encipherment 또는 Key Agreement
Extended Key Usage : 서버 인증 ( TLS Web Server Authentication )

코드 사인 인증서 구별 요소

KeyUsage : Digital Signature
Extended Key Usage : 코드 서명 ( Code Signing )

SSL 인증서 예제

아래 예제는 BerEditor -> File -> Open Certificate 메뉴을 이용해 연 SSL 인증서 화면이다.

SSL 서버 인증서 예제

위 그림에서 파란색으로 표시한 KeyUsage 에 DigitalSignature 가 있음이 확인 된다.
그리고 빨간색 느낌표 마크는 critical 설정이라는 것이다.
그리고 extendedKeyUsage 에서 TLS Web Server Authentication 을 보여주는데 이 값이 SSL 서버용 인증서 임을 나타낸다.

참고) TLS Web Client Authentication 은 SSL 에서 상호인증 하는 경우 클라이언트에서 사용하는 용도를 나타낸다.

코드 서명 인증서 예제

코드 서명용 인증서도 Open Certificate 메뉴를 이용해 연 코드 서명 인증서 화면이다.

코드 사인 인증서 예제

위 그림에서 파란색으로 표시한 KeyUsage 에 DigitalSignature 가 있음이 확인 된다.
그리고 빨간색 느낌표 마크는 critical 설정이라는 것이다.
그리고 extendedKeyUsage 에서 Code Signing 을 보여주는데 이 값이 코드 서버용 인증서 임을 나타낸다.

마무리

인증서는 용도별로 모두 프로파일 정의가 있고 필수적으로 인증서 필드에서 사용되어야 하는 값이 있다.
보통 웹서버 인증서를 설치 하거나 프로그램에 코드 서명을 하기 위해 인증서와 개인키를 사용한다.
이때 사용하는 인증서가 용도가 맞는지 확인이 필요 할 때가 있다.
이 두가지 용도를 확인할때 BerEditor 또는 윈도우 상에서 인증서를 열어서 KeyUsage 와 Extended Key Usage 확인을 해 보면 된다.

개인키 암호화하는 두가지 표준 기술( PKCS#8, PKCS#12)

JayKim — Mon, 29 Jan 2024 11:45:36 +0900

PKI 시스템에서 가장 중요하게 관리 되어야 하는것이 개인키이다.
그래서 개인키는 암호화를 해서 보관하는것이 일반적이다.
물론 좀더 안전하게 보관하기 위해 HSM 장치를 이용하는 방법도 있다.

그러면 이 개인키를 암호화에 사용되는 두가지 기술 표준이 있다.
그 두가지 기술 표준이 PKIX 에서 PKCS#8 과 PKCS#12 두가지 기술이 있다.

그럼 PKCS#8 과 PKCS#12 에 대해서 알아 보자

PKCS#8

PKCS#8 은 개인키 만을 암호화 하기 위해 사용 되는 표준 기술이다 [ RFC5208 ]
개인키 암호를 위해서 PrivateKeyInfo 와 EncryptedPrivateKeyInfo 두가지 ASN.1 형식이 사용된다.
먼저 개인키를 암호화 하기 전에 PrivateKeyInfo 형식으로 개인키 값을 만들고 이 값을 PKCS#5 의 암호화 방식을 사용하여
암호화 한후 저장하는것이 EncryptedPrivateKeyInfo 형식으로 저장을 하는 것이다.

즉 EncryptedPrivateKeyInfo 에서 EncryptedData 값으로 사용되는것이 PrivateKeyInfo 의 값을 암호화 하여 만들어지는 값이다.
일반적으로 저장하여 사용하는 개인키 암호화는 EncryptedPrivateKeyInfo 형식을 사용한다.

Private-Key Information Syntax

      PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL }

      Version ::= INTEGER

      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier

      PrivateKey ::= OCTET STRING

      Attributes ::= SET OF Attribute

Encrypted Private-Key Information Syntax

      EncryptedPrivateKeyInfo ::= SEQUENCE {
        encryptionAlgorithm  EncryptionAlgorithmIdentifier,
        encryptedData        EncryptedData }

      EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

      EncryptedData ::= OCTET STRING

PEM 에서 Encrypted Private Key 는 "BEGIN ENCRYPTED PRIVATE KEY" 를 사용하여 저장이 되니 이렇게 헤더가 있는 개인키는 PKCS#8 의 암호화된 키로 보면 된다.

아래 그림에서 보면 OctetString 영역의 값이 PrivateKeyInfo 의 암호화된 데이타 값이다.

PKCS#8 EncryptedPrivateKeyInfo Raw 데이타

그럼 PKCS#8 형식의 RSA 파일을 OpenSSL 명령어로 만들기 위해서는 아래 글을 참조 하자

[OpenSSL] RSA 개인키 (PrivateKey) 생성 명령어

PKCS#12

PKCS#12는 사실 개인키 만을 위한것이 아니리 보통 인증서와 인증서 경로검증에 필요한 체인 까지 모두 저장을 위한 기술 표준이다[RFC7292].
즉 CA, Root 인증서등 신뢰 체인을 만들기 위한 모든 요소를 하나의 파일로 저장하기 위한 형식인 것이다.

PKCS#12 는 Personal Information Exchange Syntax 로서 확장자를 PFX 또는 p12 를 사용하는 것이다.
즉 PFX 는 Personal Information Exchange 의 약자이다.

일반적으로는 많이 사용하는것은 개인키와 개인키에 맞는 인증서를 같이 하나의 파일로 저장하기 위해 사용한다.

PFX PDU Syntax

   PFX ::= SEQUENCE {
       version     INTEGER {v3(3)}(v3,...),
       authSafe    ContentInfo,
       macData     MacData OPTIONAL
   }

   MacData ::= SEQUENCE {
       mac         DigestInfo,
       macSalt     OCTET STRING,
       iterations  INTEGER DEFAULT 1
       -- Note: The default is for historical reasons and its
       --       use is deprecated.
   }

   AuthenticatedSafe ::= SEQUENCE OF ContentInfo
       -- Data if unencrypted
       -- EncryptedData if password-encrypted
       -- EnvelopedData if public key-encrypted

아래 그림을 보면 Content-specific[0] 영역에 개인키와 인증서 정보들이 저장이 된다.

PKCS#12 Raw 데이타

그럼 PKCS#12 형식의 파일을 OpenSSL 명령어로 만들기 위해서는 아래 글을 참조 하자

[OpenSSL] PKCS#12 (PFX) 파일 만들기 명령어

마무리

보통 개인키를 안전하게 저장하고 사용할 때는 PKCS#8 의 암호화 방식을 사용하여 저장을 하고
개인키와 인증서를 같이 전달 하거나 가져올때 사용하는 기술이 PKCS#12 이다. 즉 PFX 파일을 사용하면 된다.

개인키, 공개키 그리고 인증서

JayKim — Wed, 24 Jan 2024 10:24:07 +0900

PKI 시스템을 접하다 보면 항상 듣게 된는 단어가 있다.
PKI 시스템에서 전자 서명을 하기 위해서 주로 나오는 단어가 인증서, 공개키 그리고 개인키 이다.
물론 이 용어를 PKI 를 접하게 되면 기본적으로 이해를 하고 있다고 본다.
하지만 좀더 쉽게 이야기를을 해 보자.

사실 개인키 공개키와 그리고 인증서는 전자 서명을 위해서 사용하는 용어이다.
전자 서명값 만든는 키는 개인키
전자 서명값을 검증하는 키는 공개키
공개키에 대한 소유자에 대한 증명서가 인증서 이다.

전자 서명에 대한 개념은 [전자서명과 인증서 이야기] 부분을 참고하자.

개인키란?

개인키는 전자 서명값을 만들기 위한 키 이다.
그 말은 개인키가 절대 소유자가 아닌 다른 사람에게 전달 되어서는 안된다.
PKI 시스템의 주요 핵심 보안 요소인 개인키의 안전한 보관이 되는것이다.
그러다 보니 개인키를 노출을 너무나 중요시 하고 개인키는 암호화 저장도 하고 아니면 더 안전한 HSM 장치를 사용하기도 하는 것이다.

공개키란?

공개키는 전자 서명이 맞는지 검증을 하기 위한 키이다.
전자 서명을 만들기는 개인키를 가진 사람이 하지만 이 만들어진 전자 서명을 검증 해야하는 것은 누구인가?
그것은 서명 내용에 대한 검증을 하는 대상인것이다.
즉 전자서명은 개인키 소유자만 하지만 전자 서명 검증은 전자 서명을 만든 사람이 아닌 내용 검증을 위해 필요한 키이다.

전자 서명 검증은 기본적으로 원문이 함께 제공 되어야 하여서 기밀성 하고는 무관하고
단지 개인키를 가진 사람이 만들었다는 것을 증명하기 위한것이다.
그래서 검증을 위한 키는 공개 되어야 하고 서명을 검증을 하기 위해서 제공이 되어야 하는 키이다.

이름에서 알 수 있듯이 목적이 공개 되어야 하는 키의 값인 것이다. 그래서 공개키 이다.
공개키는 개인키와는 달리 별로도 암호화 저장을 하지 않는 이유이다.

인증서란?

사실 개인키와 공개키는 누구나 만들 수 있다.
그말은 누구나 전자 서명을 만들 수 있고 공개키를 가지고 검증을 할 수있다.
하지만 여기서 중요한게 해당 개인키와 공개키에 대한 소유자의 증명 문제가 필요하다.
그래서 이 개인키와 공개키의 소유자에 대한 증명을 하기 위해 만들어진게 인증서 이다.

이때 증명서를 발급 해주는 기관이 CA ( Certificate Authority ) 에서 인증서를 발급 하는 것이다.
즉 인증서는 공개키 값을 가지고 CA 의 개인키로 전자 서명을 해서 CA 에서 공개키에 대한 증명을 해준다는 증명서 이다.
즉 인증서에는 CA 의 전자서명이 있어서 CA 의 공개키로 인증서 검증을 통해 해당 인증서가 유효 한지를 판단 하는 것이다.

CA 의 주요 기능은 인증서를 만들기와 해당 인증서를 누구나 받을 수 있는 공개된 장소에 해당 인증서를 공개한다.
인증서는 공개키 값을 포함하여 누구나 가져 갈 수있기 때문에 인증서를 통해 공개키 값은 누구나 구할 수 있게 해준다.

마무리

PKI 시스템에서 전자 서명에 대한 검증에 대한 개념은 간단하지만 인증서에 대한 검증이 복잡한 기술이다.
인증서와 CA 그리고 최상위 인증기관 까지 검증 및 인증서가 유효한지 판단하는 경로 검증( Path Validation ) 같은 부분이 복잡하다.

복잡한 PKI 시스템의 이해를 위해서 일단은 기본 용어의 개념부터 이해가 필요해서
전자 서명에 사용되는 용어에 대해서 간단히 정리를 해보았다.

OpenSSL 함수에서 ASN1_EMBED 와 ASN1_SIMPLE 차이

JayKim — Fri, 19 Jan 2024 18:34:35 +0900

OpenSSL 에서 ASN.1 인코더 디코드 생성시 먼저 구조체를 정의하고 ASN.1 인코딩 디코딩을 사용한다.
이때 구조체 변수에서 포인트를 사용하면 ASN1_SIMPLE 를 사용하고 포인터가 아니면 ASN1_EMBED 를 사용 한다.

아래 예제를 를 보자

/*
Signature ::= SEQUENCE {
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
*/

struct ocsp_signature_st {
    X509_ALGOR signatureAlgorithm;
    ASN1_BIT_STRING *signature;
    STACK_OF(X509) *certs;
}OCSP_SIGNATURE;

이렇게 정의된 구조체에서 signatureAlgorithm 은 일반 구조체 변수이고 signature 는 포인터 변수 이다.
그럼 ASN.1 인코딩/디코딩 구현은 아래와 같다.

ASN1_SEQUENCE(OCSP_SIGNATURE) = {
    ASN1_EMBED(OCSP_SIGNATURE, signatureAlgorithm, X509_ALGOR),
    ASN1_SIMPLE(OCSP_SIGNATURE, signature, ASN1_BIT_STRING),
    ASN1_EXP_SEQUENCE_OF_OPT(OCSP_SIGNATURE, certs, X509, 0)
} ASN1_SEQUENCE_END(OCSP_SIGNATURE)

여기서 보면 signatureAlgorithm 은 ASN1_EMBED(OCSP_SIGNATURE, signatureAlgorithm, X509_ALGOR)
그리고 ASN1_SIMPLE(OCSP_SIGNATURE, signature, ASN1_BIT_STRING) 는 이렇게 사용한다.

OpenSSL 은 특별히 ASN.1 컴파일을 사용하지는 않고 매크로를 이용해 ASN.1 인/디코더를 지원 한다.
그중에 가장 기본인 ASN1_EMBED 와 ASN1_SIMPLE 에 대해 알아 보았다.

[CertMan] 개인키 공개키 내보내기

JayKim — Tue, 9 Jan 2024 18:56:20 +0900

CertMan 을 이용해 생성한 개인키 공개키를 내보내기 해보자

개인키 공개키 내보내기를 하기 위해서는 먼저 키 쌍을 만들어져 있어야 하는데

비대칭키 쌍 만들기는 [CertMan] 비대칭 키 쌍 ( RSA, ECDSA, SM2 ) 만들기 메뉴를 참조 하자
여기서는 이미 만들어진 쌍을 내보내기를 해보자

생성한 공개키 개인키를 내보내기 위해서는 CertMan 에서 DB파일을 읽어 온후 KeyPair 메뉴를 선택 하자
그럼 화면 우측편에 생성된 키 목록이 나온다.
내보내는 키를 선택후 마우스 우클릭을 해보자

그럼 다음 처럼 메뉴 화면을 볼 수 있다.

여기서 개인키 공개키를 내보내기 위해서는

Export PublicKey, Export PrivateKey Exprot EncryptedPrivate 키 3가지 메뉴를 사용한다.

Export PublicKey : 공개키 내보내기
Export PrivateKey : 개인키 내보내기
Export EncryptedPrivate : 개인키 암호화 내보내기 (PKCS#8 형식)
- PFX 형식의 파일이다.
- PBE Type : PKCS#8 암호화에 사용하는 암호화 방식의 타입

개인키 암호화에서는 패스워드를 입력 해야 한다.

다음 그림은 내보내기 화면이다.

이렇게 저장 위치를 지정하고 OK 를 눌러 주면 해당 키를 저장한다.
이때 Save as PEM file 을 체크 하면 PEM 형식으로 저장을 하게 된다.

실제로 Export PublicKey 와 Export PrivateKey 메뉴를 사용하면 순수 키 값을 저장하게 된다.

공개키 경우는 원로 공개를 목적이라 키 값이 그대로 저장을 하는게 일반적이지만
개인키 경우는 가능한 Export EncryptedPrivate 메뉴를 사용해 암호화 저장 하는것을 권장 한다.

CertMan 툴을 이용해 실제 공개키 개인키의 값을 볼려면 View PrivateKey 메뉴를 선택 하면
아래 화면 처럼 키 쌍의 상세한 값을 확인 할 수 있다.

위 그림에 나오는 RSA 형식의 개인키 값을 보여주는 예제이다.

마무리

보통 우리가 개인키를 암호화 저장 하게 되는데 여기서 개인키 내보낼때 암호화 하면서 내보내기가 이 형식을 사용한 것이다.
pfx 형식도 암호화 저장을 하는데 pfx 형식은 인증서와 같이 저장을 하고 개인키는 PKCS#8 형식의 저장 방식을 사용하는 것이다.

[PKCS#11] CK_SESSION_INFO 구조체 설명

JayKim — Thu, 4 Jan 2024 15:34:43 +0900

PKCS#11 API 를 사용에서 현재 연결 상태 정보를 확인 하기 위한 구조체가 있다.
즉 현재 세션에 대한 구조체 정보를 확인 하기 위한 구조체가 CK_SESSION_INFO 구조체 이다.

CK_SESSION_INFO 정의

typedef struct CK_SESSION_INFO {
 CK_SLOT_ID slotID;
 CK_STATE state;
 CK_FLAGS flags;
 CK_ULONG ulDeviceError;
} CK_SESSION_INFO;

이 정보를 얻기 위한 API 가 C_GetSessionInfo 함수를 이용한다.
각각의 구조체 정보의 정의를 보면

slotID : 토컨 인터페이스 슬롯의 ID
state : 세션에 대한 상태
flags : 비트 플래그로 CKF_RW_SESSION 과 CKF_SERIAL_SESSION 여부를 나타내다.
( 즉 읽기 전용 또는 읽고 쓰기 세션을 비트 플래그 정보 )
ulDeviceError : 장치에서 에러가 발생시 에러 정보를 나타낸다

참고로 flags 는 비트 셋팅이로 중복 상태를 나타지만 state 는 단일 상태를 나타낸다.

state 값의 종류

#define CKS_RO_PUBLIC_SESSION   0UL
#define CKS_RO_USER_FUNCTIONS   1UL
#define CKS_RW_PUBLIC_SESSION   2UL
#define CKS_RW_USER_FUNCTIONS   3UL
#define CKS_RW_SO_FUNCTIONS     4UL

이렇게 4가지 상태 값이 존재한다.

CKS_RO_PUBLIC_SESSION : C_OpenSession 에서 CKF_SERIAL_SESSON 플래그로 연 상태
CKS_RW_PUBLIC_SESSION : C_OpenSession 에서 CKF_SERIAL_SESSION | CKF_RW_SESSION 플래그로 연 상태
CKS_RO_USER_FUNCTIONS : CKS_RO_PUBLIC_SESSION 으로 연결된 세션에 C_Login 을 User 타입으로 한 상태
CKS_RW_USER_FUNCTIONS : CKS_RW_PUBLIC_SESSION 으로 연결된 세션에 C_Login 을 User 타입으로 한 상태
CKS_RW_SO_FUNCTIONS : CKS_RW_PUBLIC_SESSION 으로 연결 된 세션에 C_Login 을 SO 타입으로 한 상태

참고) CKF_SERIAL_SESSION 은 C_OpenSession 에서 디폴트로 설정이 되어야 한다.
즉 CKF_RW_SESSION 단독으로는 쓸 수 없다.
CKS_RW_SO_FUNCTIONS 는 CKS_RO_PUBLIC_SESSION 에서는 사용 할 수 없다.
즉 SO 경우는 읽기 전용은 사용 하지 않는다.

CK_SESSION_INFO 특성

이 구조체에서 flags 의 정보는 C_OpenSession 으로 설정 하고 C_CloseSession 으로 값을 지우게 된다.
그리고 state 정보는 C_OpenSession 과 C_Login 을 통하여 만들어진 값이구
값의 상태 제거는 C_Logout 과 C_CloseSession 으로 이루어 진다.

마무리

CK_SESSION_INFO 는 사실 HSM 장치의 인증 상태 정보를 제공하는 기능이다.
이 구조체의 정보를 확인 하여 현재 장치 연결 상태 정보를 확인 할 수 있다.

동영상 강의를 만들어 볼까?

JayKim — Fri, 22 Dec 2023 16:20:57 +0900

요즈음은 유튜브나 유데미 인프런 등 다양한 동영상 시대인거 같다.

동영상을 통하여 기술에 대한 설명을 전달하는게 아무래도 문자로 쓰는 것보다는 훨씬 전달력이 높은거 같다.

사실 내가 오랫동안 해온 PKI 기술 사실 아직도 어려운거 같은데 이 것을 블로그 같은 문자로 설명하기 보다는

웬지 동영상으로 만들면 어떨까? 좀 더 기술 이해 전달이 잘 되지 않을까?

그리고 여기서 만들 툴에 대해서 좀더 활용도가 높아지지 않을까 생각이 든다.

하지만 나서기를 별로 좋아하지 않는 성격상 왠지 동영상은 먼가 어색하다..

동영상을 만들면 얼굴도 온라인으로 나오게 되는게 왠지 부담스럽기도 하네.

사실 개발자로 오랫 동안 지내다 보니 이제는 먼가 새로운것을 배우고 익히는 것보다는

내가 해온것에 대한 정리 및 깊이를 더 가지고 싶다.

그리고 동영상으로 만들어서 좀 더 쉽게 내가 만들고 아는 기술을 전달 하고 싶은 욕구가 있다.

하지만 아직은 꺼려지네...

왠지 만들었는데 보는 사람도 반응도 없으면 부끄러울꺼 같네 ㅎㅎ...

그래도 한번 시도는 해볼까나?.....

[BerEditor] 인증서, CRL 그리고 CSR 파일 정보 보기

JayKim — Fri, 22 Dec 2023 13:40:15 +0900

PKI 관련 기술을 하다 보면 주로 접하게 되는 파일이 있다.
즉 인증서, CRL(인증서 폐기 목록) 그리고 CSR( 인증서 서명 요청서 파일이다)

BerEditor 에서는 이 3가지 파일 정보 기능을 제공한다.
이 기능은 BerEditor Version 1.6.0 이상에서 지원 한다.

인증서 보기

File -> Open Certficate 를 선택 한다.

인증서 보기

X.509 인증서에 상세 정보 값을 확인 할 수 있다.

Save : 해당 인증서를 PEM 형식으로 저장 한다.

인증서 경로 검증은 라이선스 모드에서 지원 합니다.

인증서 경로 검증

Path Validation 탭을 클릭해보면 위 화면 처럼 나온다.
어떤 경우는 아래 버튼들이 비활성화 상태로 나오는 경우도 있다.
사실 아래 모든 기능의 경우 Authority Info Access 확장 필드와 CRLDP 확장 필드를 이용해서 아래 버튼 기능을 사용하는데
만약에 해당 인증서가 Authority Info Access 정보와 CRLDP 가 존재 하지 않으면 비활성화 상태로 되는 것이다.

MakeTree : 해당 인증서의 최상위 까지 인증서 경로를 만들기
Verify Cert : 해당 인증서의 CA로 인증서 서명 검증 하기
Decode Certificate : 해당 인증서를 BER 디코딩을 한다.
Path Validation : 해당 인증서의 경로 즉 루트까지 인증 경로 검증을 한다.
(참고로 여기서는 최상위 인증서(SelfSign 인증서)를 신뢰 상태로 가정한다)
cf) SSL Verify 에서는 수동으로 넣어 주어야 함
GetCA : 해당 인증서의 CA 인증서를 가져와서 보여준다.
GetCRL : 해당 인증서 폐기 목록을 가져와서 보여 준다.( 폐기가 안되어도 CRL은 존재 한다)
OCSP Check : OCSP 로 상태 검증을 하는데 일반적으로 접근 제한이 있어서 값을 못 구할 수 있다.
대부분 OCSP 서버가 요청서 전자 서명을 요구 하는데 ( 여기서는 서명 없이 요청 함)
CRL Check : CRL 파일에 해당 인증서가 폐기 되었는지 확인 한다.

참고로 MakeTree 를 했을 시 Root 가 안나오는 경우가 있는데
이유는 CA 인증서에 Authority Info Access 정보에 CA Issuers 정보가 없는 경우에는 Root 인증서 까지 만들지 못한다.
CA Issuers 가 없어서 경로 검증이 안되지만 이것은 경로 검증 오류는 아니다.

SSL Verify 에서는 Root 인증서까지 다 가져오는것은 인증서가 아닌 SSL Handshake 과정에서 전달 해주기 때문이다.

CRL 보기

File -> Open CRL 을 선택한다.

CRL 정보 보기

Save : 해당 CRL을 PEM 형식 저장 한다.

폐기 목록을 확인 한다.

Verify CRL : 이 버튼을 실행 하면 CA 인증서를 수동으로 선택 해서 CRL 서명 검증을 한다.
Decode CRL : CRL 파일의 BER 디코딩을 한다.

CSR 보기

File -> Open CSL 을 선택한다.

CSR 정보 보기

Save : CSR 파일을 PEM 형식으로 저장 한다.
Verify CSR : CSR 은 자신의 키로 서명 하므로 CSR 내에 공개키로 서명 검증 한다.
Decode CSR : CSR 에 대한 BER 디코딩을 한다.

이렇게 주요 PKI 에서 사용 되는 포멧에 대한 상세 보기가 가능 하다.

마무리

사실 이 3가지 파일( Certificate, CRL, CSR )을 자주 접하지만
상세 보기를 통하여 좀더 이해를 가져 가기 위해서 이 기능을 만들었다.
사실 윈도우 경우 인증서랑 CRL 보기가 참 잘 만들어져 있지만
MacOS 나 리눅스 경우는 이들 파일 보기가 필요해서 BerEditor 에서 지원 하게 되었다.
(아님 MacOS라 리눅스도 잘 되었있는데 내가 모르고 있을수도 있다 ㅎㅎ)

[BerEditor] SSL 또는 TLS 서버 검증 하기

JayKim — Thu, 21 Dec 2023 11:01:58 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

SSL 이나 TLS는 암호화 통신을 하기 위한 프로토콜이다.
일반적으로 많이 사용하는 SSL 통신이 웹서비스이며 웹서비스는 HTTP와 HTTPS 주소를 사용하다.
이때 HTTPS 경우가 SSL 또는 TLS 방식의 암호화 통신을 하는데
SSL 통신을 할 때 서버 인증서 기반의 핸드쉐이크 과정이 이루어 진다.
이 핸드쉐이크 과정에서 서버 인증이 되고 이때 인증서 경로 검증이 이루어지게 된다.

BerEditor ( 버전 1.6.0 이상 ) 는 SSL 또는 TLS 핸드쉐이크 과정에서 보내오는 인증서 정보를 보여주는 기능을 제공한다.
BerEditor 에서 SSL Verify 기능을 사용하기 위해서는 Cryptogram -> SSL Verify 메뉴를 선택 하면 된다.

URL 주소 서버 검증 하기

SSL Verify 창에서 URL 주소 부분에 웹사이트나 SSL 서비스 제공하는 URL 주소를 입력하고 Connect 버튼을 누르자
예제 화면은 https://www.naver.com 을 사용하였다.

위에 URL 연결 후 URL Tree 부분을 보면 해당 인증서에서 부터 최상위 인증서의 트리 를 볼 수 있다.
이 때 해당 인증서의 정보를 볼려면
URL Tree 내에서 해당 인증서 마우스 우클릭을 통해 View Cert 로 인증서 정보를 상세히 볼 수 있다.

인증서 보기

인증서 보기에 대한 기능은 인증서 CRL 및 CSR 정보 보기 페이지를 참조 하면 된다.

그리고 URL Log 탭을 보게 되면 검증 결과에 대한 메세지를 확인 할 수 있다.
이때 결과 메세지는 SSL 프로토콜 버전 CipherSuite 및 검증 결과 및 해당 인증서 DN 값을 보여 준다.

SSL 결과 로그 메세지

여기 화면에서는 검증 결과가 V_OK 로 나오지만 사용자 환경에 따라 검증 실패에 대한 메세지를 볼 수도 있다.
그 이유는 Trust List 에 최상위 인증서를 저장에 결과는 달라 지기 때문이다.

SSL 검증 옵션 설정

SSL 프로토콜 설정은 SSL_OP 관련 옵션을 체크해서 사용 하지 않는 프로토콜을 제한 할 수 있다.
Fix Cipher 값을 통하여 사용할 TLS Cipher Suite를 제한 할 수 있다.
Check Host Name : 호스트명을 인증서내 체그 유무
Verify Mode 에서 SSL 서버 인증서에 대한 검증을 할 지 안 할지 결정 한다.
- SSL_VERIFY_NONE : 서버 인증서 검증 안함, SSL_VERIFY_PEER : 서버 인증서 검증함

Trust 인증서 등록 하기

최상위 인증서는 일반적으로는 브라우저나 PC경우는 내부적으로 등록 되어 있지만
BerEditor 경우는 수동으로 등록을 해주어야 한다.
실제로 최상위 인증서를 등록 하지 위해서는 두가지 방식이 있다.

View List 화면에서 추가 하기

URL Tree 에서 루트 인증서 마우스 우클릭후 신뢰목록 저장 하기 기능 사용

이렇게 두가지 방식으로 최상위 인증서를 등록해서 Refresh 를 해서 로그 메세지를 확인 해보면
정상적인 인증서 경로인 경우 V_OK 가 나오게 된다.

마무리

사실 HTTPS를 자주 접하게 되지만 실제로 어떤 인증서가 사용 되는지 그리고 정상 검증이 되는지 확인이 필요할때 해당 인증서 목록을 구하려면 손이 많이 가서 쉽게 SSL Verify 기능으로 인증서 보기와 검증을 테스틀 할 수 있게 만든 기능이다.

URI 와 URL 에 대한 개념 정리

JayKim — Wed, 20 Dec 2023 15:48:12 +0900

일반적으로 웹 주소등 인터넷상 위치를 표시 하기 위해 URI 와 URL 두가지 용어가 사용한다.
쓰다 보니 둘다 용어가 비슷하여 이 개념을 좀더 정리 해보자

URI 개념

URI 는 Uniform Resource Identifier 의 약자 이다.
네트워크 상에서 리소스를 구별하는 식별자를 의미한다.

URL 개념

URL 은 Uniform Resource Locator 의 약자이다.
용어를 해석 해보면 네트워크 상에서 리소스 구별하는 위치자를 의미한다.
즉 URL 은 URI 의 서버 타입이다. URI의 서브 타입에는 URN( Uniform Resource Name ) 과 URL 이 있다고 보면 된다.

URL 형식

scheme:[//[user[:passowrd]@]host[:port]][/path][?query][#fragment]

이런 형식을 사용한다.

URL 구성 요소

scheme : 프로토콜을 의미 ex) http, ftp, ldap 등
user : 계정 사용자
password : 사용자 패스워드
host : 서버 DNS 네임 또는 IP 주소
port : 서버의 서비스 포트
path : 서버에서 위치 경로
query : 요청하는 메세지 정보
fragment : 해당 리소스에 대한 식별자 정보

즉 URL 예제로서

ldap://ldap.test.com:389/ou=dp7p27928,ou=crldp,ou=AccreditedCA,o=KICA,c=KR

scheme : ldap
host : ldap.test.com
port : 389 
path : ou=dp7p27928,ou=crldp,ou=AccreditedCA,o=KICA,c=KR

마무리

개발 업무를 하다 보면 URI 나 URL 용어를 자주 접하게 되는데
실제 우리가 사용하는 http 나 ftp 또는 ldap 주소등은 URL 값이 된다.
그리고 URI 경우 URL 외에 URN 을 포함하니 URI 라는 용어도 맞지만 URL 이 좀 더 정확한 단어이다.

[CryptokiMan] YubiHSM2 장치 테스트 ( Windows 환경 )

JayKim — Wed, 22 Nov 2023 11:39:56 +0900

YubiHSM2 하드웨어 장치는 PKCS#11 API 를 제공한다.
이 장치에 대한 정보는 Yubico 홈페이지를 참조 하면 된다.

현재 USB형식의 소형 하드웨어 HSM 장치로서는 가장 PKCS#11 을 잘 지원하는 장치로 보인다.
참고로 USB 형 HSM 장치인데 RSA 4096 키 생성이 지원 된다.
서버용 HSM 장치가 아닌 소형 USB 형 HSM에서 RSA 4096 키 생성 지원은 처음 본다.
그리고 Network HSM 기능도 지원한다.
http 프로토콜을 이용하여 사용하는 앱과 HSM 이 네트워크로 연결 사용도 가능하다.

여기서 관련 드라이버 설치는 Yubico 홈페이지를 참조 하고 CryptokiMan 을 이용하여 PKCS#11 기능을 사용 해보자.
해당 PKCS11 파일은 yubihsm_pcks11.dll 파일이다.

환경 설정

이 장치를 윈도우즈 환경에서 사용하기 위해서는 다음 환경 변수를 잡아주고
YUBIHSM_PKCS11_CONF 를 yubihsm_pkcs11.conf 파일 위치로 설정 해주어야 한다.
윈도우 시스템 설정에서 다음 그림 참조 하면 된다.

yubihsm_pkcs11.conf 예제

# URL of the connector to use. This can be a comma-separated list
connector = http://127.0.0.1:12345    
# Enables general debug output in the module
debug
# Enables function tracing (ingress/egress) debug output in the module
dinout
# Enables libyubihsm debug output in the module
libdebug
# Redirects the debug output to a specific file. The file is created
# if it does not exist. The content is appended
#  
debug-file = hsm_dbg.txt

실제 작동에 필요한 부분은 connector 부분만 설정하면 정상 작동 한다.

관련 YubiHSM 라이브러리를 CryptokiMan 실행 파일에 있는 경로에 추가해 주어야 작동 한다.
처음에는 yubihsm_pkcs11.dll 을 읽어 오기 조차 안되어서
관련 라이브러리른 yubihsm_pkcs11.dll 위치로 가져왔지만 장애가 나서
CryptokiMan 실행 파일 위치로 관련 라이브러리를 넣어 주니 정상 작동 했다.

작동 테스트

다음 화면이 YubiHSM2 장치를 실행하여 캡쳐 한 화면이다.
이 장치를 처음 설치하고 실행 했을 시 이미 장치에 대한 초기화화 패스워드가 설정 되어 있다.

YubiHSM2 실행 화면

이 화면은 YubiHSM2 장치를 PKCS#11 함수를 이용하여 작동 시킨 화면이다.

YubiHSM2 펌웨어 버전 2.3 이상에서만 AES 키 생성, 암/복호화를 지원하니 가능한 펌웨어 2.3 이상을 사용하는게 좋다.

마무리

YubiHSM2 장치는 PKCS#11 기능을 USB 장치로 지원하는 작은 HSM 장치로서는 가장 좋은 장치로 보인다.
다양한 OS 지원 뿐만아니라 KSP 등 윈도우 표준 포맷도 지원한다.
그리고 자체 명령어 및 API도 제공한다.

주로 CryptokiMan 을 가지고 개발 테스트는 SoftHSM2 를 이용하였는데
YubiHSM2 하드웨어 장치로 테스트 하는게 진정한 HSM 테스트라고 생각한다.

개인적으로 하나 가지고 사용하고 싶지만 가격이 너무 비싸네 ..

QT 리눅스 Deploy 방법

JayKim — Mon, 20 Nov 2023 12:08:06 +0900

QT에서 리눅스 환경에서 패키지를 설치 하기 위해서는 특별히 deploy 기능이 지원 되지 않는다
하지만 별도의 QT 툴을 이용하여 Deploy 를 할 수 있다.

여기서 사용하는 툴은 cqtdeployer 를 사용하여 패키지 하였다.
(참고로 cqtdeployer 는 리눅스와 윈도우 환경 모두를 지원한다.)

해당 github 소스 위치는 https://github.com/QuasarApp/CQtDeployer 이다

cqtdeployer 설치

설치 방법은 소스를 직접 설치 할 수도 있지만 여기서는 Snap Store 를 이용하면 명령어 하나로 간단히 설치 된다

https://snapcraft.io/cqtdeployer

링크 방문후 Install 을 클릭 하면 나오는 다음 명령어 실행 하면 된다 (snap 지원 리눅스에 한하여)

$ sudo snap install cqtdeployer

설치 snap 목록 확인

$ snap list

일부 생략
cqtdeployer        1.6.2323.dd027b2  272    latest/stable    quasarrapp    -

로 확인 해보면 cqtdeployer 를 확인 할 수 있다.

리눅스 패키지

이제 실제로 Qt 로 빌드한 바이너리를 생성 하고 해당 폴더로 이동을 해보자
여기서 예제로 BerEditor 라는 실행 파일이 생성 되면 해당 폴더에서 cqtdeployer -bin BerEditor 만 실행 하면 된다.

$ cd [바이너리 생성 폴더]
$ cqtdeployer -bin BerEditor

만약 실행 중에 설정 관련 경로 에러가 나면 qmake 위치를 지정해 주자.

cqtdeployer 명령어 에러시 qmake 위치 지정

명령 예제 임

cqtdeployer -bin BerEditor -qmake ~/Qt/5.13.2/gcc_64/bin/qmake

여기서 "~/Qt/5.13.2/gcc_64/bin/qmake" 는 사용자 환경에 맞제 지정해 주어야 한다.
위 명령어 실행을 하면 DistributionKit 폴더가 생성 됨

생성후 DistributionKit 폴더에 들어가 보면

cd DistributionKit
ls -l
total 20
-rwxrwxr-x  1 jykim jykim 1640 11월 20 15:46 BerEditor.sh
drwxrwxr-x  2 jykim jykim 4096 11월 20 15:45 bin
drwxrwxr-x  2 jykim jykim 4096 11월 20 15:45 lib
drwxrwxr-x 10 jykim jykim 4096 11월 20 12:02 plugins
drwxrwxr-x  2 jykim jykim 4096 11월 20 15:46 translations

이런게 관련 패키지 목록이 생겨 있다. 여기서 BerEditor.sh 파일을 실행 하면 된다.
실행 시 GLIBC XX 관련 에러가 나타나면 BerEditor.sh 파일을 열어서 아래 내용을 수정 하자

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"$BASE_DIR"/lib/:"$BASE_DIR"

LD_LIBRARY_PATH 값을 앞으로 조절 해주면 됨
그리고 BerEditor.sh 을 실행 하면 된다.
cqtdeployer 로 명령어를 실행 하여 나온 파일들은 실행 파일에 대한 관련 라이브러리등의 파일을 묶어 주는 역활을 하는 것이다.
이렇게 생성 된 DistributionKit 폴더를 zip 으로 묶어서 배포하면 된다.

마무리

윈도우나 MacOS 경우 패키지 방식이 거의 정해진 방식이 있다.
하지만 리눅스는 아직 패키지 지원이 여러가지라서 일단 이렇게 관련 파일 묶음으로 패키지를 하였다.
사실 리눅스에서 rpm 또는 deb 같은 방식이 있지만 이 방식들은 지원하는 리눅스의 의존성이 있어서
zip으로 만들어서 사용하게 하였다.

여기서 Deploy 실행은 우분투 20 대 버전 64비트 모드에서 테스트 하였다.

[BerEditor] 2진수 10진수 16진수 숫자 변환

JayKim — Thu, 16 Nov 2023 09:52:10 +0900

프로그램을 짜다 보변 숫자를 표시 하고 처리 하는 경우가 자주 만나게 된다.
일반적으로 사람들이 쉽게 사용하는 것은 10 진수 이다.
하지만 메모리를 직접 보거나 컴퓨터가 이해 하기 위한 숫자는 16진수 2진수이다.

그리고 이 16진수나 2진수를 10진수로 변환을 해야 하는 경우가 있다.
이 변환을 해보기 위해서 BerEdior 에서 Number Transmission 을 사용하면 된다.

먼저 각각의 진법에 대한 간다히 개요이다.

2, 10, 16 진법 개요

2진법

0과 1이라는 두 개의 숫자만을 사용하여 수를 나타내는 진법을 말한다

10진법

10을 기수로 쓰는 실수의 진법이다. 10개의 숫자를 가지고 수를 표현하며, 열배마다 자릿수가 하나씩 올라간다

16진법

자릿수 하나가 0부터 15까지 표현할 수 있다. 하지만 우리가 흔히 사용하는 아라비아 숫자는 0부터 9까지 밖에 없기 때문에 나머지 10은 A, 11은 B, 12는 C, 13은 D, 14는 E, 15는 F로 로마자를 사용해 표현한다.

그럼 Number Transmission 기능을 이용하여 숫자를 변환 해보자
해당 기능은 BerEditor -> Tool -> Number Transmission 을 선택하면 된다.

Number Transmission 사용

예제로 숫자 십진수 1000 에 대해 16진수와 2진수에 대해 변환 해보자

위에 그림 처럼 10진수 1000은 16진수 03E8 값이고 2진수는 1111101000 값을 얻을 수 있다.
예제 그림은 작은 숫자인 1000을 하였지만 실제로 아주 큰 숫자인 경우 툴을 사용하여 얻을 수도 있다.

마무리

사실 2진수 10진수 16진수를 간단히 사용 할때는 특별히 툴이 없이 도 이해 할 수 있다.
하지만 암호화 관련 수학이나 큰 숫자를 다루게 되면 숫자를 10진수 또는 16진수등 다양하게 지원이 되어야 한다.
이때는 이 Number Transmission 을 이용하여 원하는 진법으로 변경 하여 사용 할 수 있다.

PKCS#11 서명에서 C_SignUpdate C_SignFinal 사용 못하는 메커니즘

JayKim — Tue, 7 Nov 2023 10:57:03 +0900

일반적으로 전자 서명은 원문에 대한 해쉬값을 개인키로 암호화 하게 된다.
그래서 PKCS#11 함수에서 C_SignInit -> C_SignUpdate (반복) C_SignFinal 과정을 사용하여 값을 구한다.
참고로 C_SignUpdate 경우에 본문을 여러개로 나누어서 보내 경우 반복을 하게 된다.

즉 C_SignInit 에서는 어떤 키와 메커니즘을 알려주고
C_SignUpdate 에서는 원문 내용을 받게 되고
C_SignFinal에서 원문에 대한 해쉬 값을 구하여 서명 값을 얻게 되는것이다.

그리고 원문을 한번에 보내는 C_SignInit 과 C_Sign 함수로 바로 구할 수도 있다.

하지만 다음 메커니즘 경우는 C_SignInit 다음 바로 C_Sign 함수 만 호출 해야 한다.
즉 C_SignUpdate 와 C_SignFinal 함수를 사용하면 안되는 메커니즘이다.

CKM_RSA_PKCS, CKM_RSA_PKCS_PSS, CKM_ECDSA, CKM_DSA

위의 메커니즘이다.
이 메커니즘 경우는 보통은 해쉬 된 값을 개인키로 암호화 형식에 맞게 만들어서 바로 암호화 하기 때문이다.

즉 원문 전체를 보내는 경우가 아닌 원문의 해쉬값을 사용하는 경우이다.
그러므로 C_SignInit -> C_Sign 함수로 바로 서명 값을 구하는 것이다.

마무리

보통 원문을 전체 다 보내게 되면 데이타 전송에 부담되는 경우가 많다.
이때는 원문에 대핸 해쉬 값을 구해서 이와 같은 메커니즘을 사용 하는 것이다.
물론 이 특성은 전자서명 검증에서도 동일한 것이다.

[CryptokiMan] ECDH 를 이용 대칭키 생성 하기

JayKim — Tue, 31 Oct 2023 12:03:58 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

PKCS#11 기능에서 ECDH 알고리즘을 이용한 대칭키 생성을 할 수 있다.
PKCS#11 에서 대칭키를 생성 하려면 ECDSA 용 키 쌍이 있어야 하고 이 키 쌍을 이용하여 C_DeriveKey 기능을 이용하여
ECDH 메커니즘을 실행 하면 된다.

이 때 생성한 대칭키는 결과 값으로 나오는 것이 아니라
HSM 장치내에 생성 및 되고 결과로 생성된 키의 핸들을 얻을 수 있다.

그럼 ECDH 생성을 위해서는 기본적으로 체크 사항이다.

ECDSA 키를 먼저 생성 하는데 이 키 의 속성에서 CKA_DERIVE 를 TRUE 로 설정 해 주어야 한다.
여기서 ECDSA 키를 생성 시 파라미터를 지정해 주어야 하는데 여기서는 prime256v1 파라 미터를 사용하자.
ECDH 값을 구하기 위해서는 C_DeriveKey 함수를 이용하는데 실제 키를 사용하기 위해
C_Initialize -> C_OpenSession -> C_Login 까지 먼저 이루어 져야 한다.
즉 라이브러리 호출과 로그인 까지의 과정은 여기 문서에서는 생략 하였지만 이 과정은 필수 이다.

이 문서 작성을 위하여 사용한 PKCS#11 라이브러리는 SoftHSM2 를 사용하였다.

ECDSA 키 쌍 생성

CryptokiMan에서 Objects -> Generate KeyPair 를 실행 하자

그럼 아래 그림 처럼 General 정보 창이 나온다.

Mechanism 을 CKM_ECDSA_KEY_PAIR_GEN 을 선택
NamedCurve 는 prime256v1 파라미터를 선택

그리고 Private Key 탭을 선택 하자

라벨명을 기억 하기 쉽게 적어 주면 된다.
Derive 속성을 필수로 TRUE 를 선택 해주어야 한다.

그리고 OK 를 누르면 ECDSA 키 쌍이 생성 된다. 생성된 키는 Objects 에서 Private Key 메뉴로 확인 가능 하다.
이 때 입력한 라벨명을 확인 하면 된다.

참고로 공개키 정보도 기록이 되는데 실제 사용은 개인키 이어서 특별히 설명을 하지 않았다.

ECDSA 공유 키를 생성 해보자

공유키를 생성 하기 위해서는 Tools -> Derive Key 를 선택 하자
ECDH 키를 생성 하기 위해서는 HSM 내에 생성한 개인키와 상대방의 ECDSA 공개키 값을 가지고 생성 하므로 상대방 공개키는 아래 예제 값을 사용하였다.

# ECDSA 상대방 공개키 예제
04CABF3F1100F2D2B2E7D7DC21DB96B3C8833AFD91AAA78A3C30F3E6EEC1963272B38C5933F65D927B2FCA0D8A226D4BEA8AA1F609312546D766CC6B3D9334F73C

참고로 ECDSA 공개키의 첫 바이트는 04 로 고정 값을 사용하여야 한다.
이 값은 특별히 공개키 값이 압축 되지 않았음을 알려주는 값이다.

그럼 아래 그림 처럼 General 탭을 설정 하자

기존에 생성한 ECDSA 용 라벨을 선택 한다.
CKM_ECDH1_DERIVE 를 선택한다. 이것이 ECDH 알고리즘 사용을 알려 주는 것이다.
기본 방식인 CKD_NULL 방식을 선택 한다.
Public Data 에 상대방 ECDSA 공개키 값을 넣어 준다.

참고로 EC_KDF_T 에서 CKD_SHA1_KDF 방식을 사용하면 이때에는 Shared Data 를 사용한다.
이것은 양쪽에 공유된 데이타의 해쉬값을 내부적으로 사용하는 방식이다.
여기서는 기본 방식인 CKD_NULL 을 사용하였다.

그리고 Key 탭을 설정 하자.
여기서 Key 탭을 추출된 키의 속성을 설정 하는 것이다.

기본적으로 디폴트 값에서 생성 키 길이랑 라벨명을 지정 해 주었다.
그리고 OK 를 누르면 키 생성이 된다.
생성 된 키를 확인 하기 위해서는 Secret Key 메뉴에서 생성에 사용한 라벨명을 확인 하면 된다.

마무리

PKCS#11 API 를 이용하여 ECDH 키 쌍 및 대칭키 추출을 해보았다.
ECDH 알고리즘은 대칭키를 추출 하기 위해서 사용 된다.
일반적으로 ECDH 는 키 값을 추출 하게 되지만 PKCS#11에서는 키가 생성이 되고 그에 대한 핸들을 얻는것이다.
즉 키는 장치에 저장이 되어서 실제 키 값을 알 수는 없고 그에 대한 핸들을 이용하여 사용 할 수 있는 것이다.

[CryptokiMan] HSM 장치 지원 메크니즘 확인 하기

JayKim — Tue, 24 Oct 2023 18:56:12 +0900

HSM 장치에서 PKCS#11 API 를 이용하여 해당 장치가 지원 하는 메커니즘을 확인 할 수 있다.

지원 메커니즘의 정보를 제공하는 API 가 C_GetMechanismList 함수이다.
그리고 각각의 메커니즘에서 좀더 상세한 정보를 제공하는 API 가 C_GetMechanismInfo 함수이다.

PKCS11 함수 정의

C_GetMechanismList

CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismList)(
CK_SLOT_ID slotID,
CK_MECHANISM_TYPE_PTR pMechanismList,
CK_ULONG_PTR pulCount
);

이 함수는 지원 메커니즘을 리스트로 타입값을 모두 가져다 준다.

C_GetMechanismInfo

CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismInfo)(
CK_SLOT_ID slotID,
CK_MECHANISM_TYPE type,
CK_MECHANISM_INFO_PTR pInfo
);

이 함수는 리스트로 가져온 타입 각각의 정보에 대해 구체적인 정보 값을 제공 해 주는 것이다.

지원 메커니즘 확인

CryptokiMan 을 이용하면 좀 더 쉽게 확인 가능하다.
이 툴에서도 위의 두 함수를 이용하여 좀 더 보기 쉽게 보여주는 것이다.

이 정보를 확인 하기 위해서는 장치 초기화 후 슬롯 정보에서 각 메뉴의 Mechanism 메뉴를 클릭 하면된다.
아래가 SoftHSM2 지원하는 메커니즘 예제 화면이다.

화면에서 보면 메커니즘과 그리고 최소, 최대 그리고 플래그 정보를 제공하는 것을 볼 수 있다.

마무리

HSM 장치를 사용할 때 이 장치의 지원 알고리즘과 특성을 파악하기 위한 정보를 얻기 위해서
사용하는 API 가 C_GetMechanismList 와 C_GetMechanismInfo 를 사용하면 된다.

[CryptokiMan] DH (Diffie Hellman) 로 키 생성 하기

JayKim — Tue, 24 Oct 2023 12:29:18 +0900

[이 기능은 라이선스 버전 기능입니다]
라이선스가 필요한 분은 [프로그램 키 발급] 페이지에서 30일 라이선스 발급 가능합니다

CryptokiMan 을 이용하여 PKCS#11 기능의 DH 키와 DeriveKey 기능을 이용하여
대칭키를 추출 해보자.
여기서 생성된 대칭키는 실제로 값을 얻는 것이 아니라 HSM 장치내에서 키가 생성이 되고 생성된 핸들 값을 얻게 된다.

일단 DH 기능을 하기 위해서는 다음 순서로 실행을 한다.

DH 키 생성 이 때 키는 CKA_DERIVE 값이 TRUE 로 되어야 한다.
이때 DH 용 파라미터를 넣어 주어야 하는데 해당 값을 넣어 주거나 테스트를 위해 만들어서 사용한다.
DH 값을 구하기 위해서는 PKCS#11 기능 중에 C_DeriveKey 기능을 사용하다.
참고로 이 DH 알고리즘을 사용하기 위해서는 C_Initialize -> C_OpenSession -> C_Login 이 되어 있는 상태에서 진행 해야 한다.

이 문서 작성을 위하여 사용한 PKCS#11 라이브러리는 SoftHSM2 를 사용하였다.

DH 키 쌍 생성

CryptokiMan -> Objects -> Generate KeyPair 를 실행 하자

그럼 아래 그림 처럼 General 정보 창이 나온다.

Mechanism 을 CKM_DH_PKCS_KEY_PAIR_GEN 을 선택
파라미터 키 길이 : 1024 를 선택 ( 이 값은 512, 2048 선택 해도 된다.)
Gen DH Param 클릭 하면 아래 파라미터 값인 g 와 p 가 표신 된다. 물론 이 값은 기존의 값을 넣어 주어도 된다.

그리고 Private Key 탭을 선택 하자

Label 은 기억하기 쉽게 적으면 된다.
여기서 Derive 값을 체크 하고 true 를 필히 선택 한다.

그리고 OK 를 누르면 DH 키 쌍이 생성 된다 키 쌍은 PrivateKey 와 Public Key 에서 확인 할 수 있다.

DH 공유 키를 생성

공유키를 생성 하기 위해서는 Tools -> Derive Key 를 선택 하자

앞에서 만든 키인 DH Test 를 라벨에서 선택 하자
Method 는 CKM_DH_PKCS_DERIVE 를 선택해서 DH 알고리즘을 지정한다.
Parameter 에서는 상대방 공개 키 값을 넣어 주자

그리고 Key 탭을 선택 한다.

키 탭에서 생성 될 키는 CKO_SECRET_KEY 를 선택
그리고 CKK_GENERIC_SECRET 키를 디폴트로 선택 한다.( 참고로 CKK_AES 를 사용 해도 된다 )
그리고 생성 할 키 길이를 입력 하자 여기서는 16 바이트를 입력 하였다.
그리고 확인을 위해 라벨을 기록 하자 예제는 "Derived Key" 를 입력 하고 "OK"를 누른다.

그럼 아래 그림 처럼 DH 를 이용한 Secret Key 를 확인 할 수 있다.

마무리

PKCS#11 API 를 이용하여 DH 키 쌍 및 대칭키 추출을 해보았다.
DH 알고리즘은 대칭키를 추출 하기 위해서 사용 된다.
일반적으로 DH 는 키 값을 추출 하게 되지만 PKCS#11에서는 키가 생성이 되고 그에 대한 핸들을 얻는것이다.
즉 키는 장치에 저장이 되어서 실제 키 값을 알 수는 없고 그에 대한 핸들을 이용하여 사용 할 수 있는 것이다.

ECDSA 인증서 공개키 값에 0x04 가 앞에 붙는 이유

JayKim — Fri, 13 Oct 2023 17:54:01 +0900

일반적으로 ECDSA 공개키를 인증서에서 값을 읽어 보면
항상 첫 바이트가 0x04 값으로 시작 한다.
그리고 ECDSA 공개키 경우 보통 P-256 파라미터를 사용하면 64 바이트 길이어야 하는데 0x04 가 붙음으로 65 바이트가 된다.

위 그림에서 03 42 00 04 ... 이렇게 진행 하는데
03 은 BitString 이구
42 는 66 바이트이구
00 은 사용하지 않는 비트 개수이구
04 부터 공개키 값이다 즉 이렇게 04 부터 시작하는 것을 알 수 있다.

그럼 이 0x04 값의 의미는 무엇인가?
이 내용에 대해서는 RFC5480 문서에서 다음과 같은 내용이 나온다.

o The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 and the compressed form is indicated by either 0x02 or 0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if any other value is included in the first octet.

이 문서에서 0x04 의 의미는 실제 공개키 값이 압축 되지 않는 형식 (uncompressed form) 이라는 것을 나타낸다.
만약 0x02 또는 0x03 인 경우는 압축된 공개키라는 것이다.
그리고 이 값이 아니면 거부 해야 한다는 것을 나타낸다.

0x04 값 이후의 나머지 값이 ECDSA 실제 공개키 죄표값이 X Y 좌표의 연속 값이다.

마무리

다른 알고리즘에서는 ECDSA 공개키에 있는 0x04 값을 안 사용하는데
그리고 0x02나 0x03 은 압축 된 값을 의미한다구 하는데..
아직까지 0x02 나 0x03 은 본적이 없다.
사실 ECDSA 공개키 길이가 길지 않아서 압축 값을 만들 필요도 없는거 같다.

ECDSA 에서는 압축 되지 않은 값의 의미로 항상 0x04가 추가 되는게 표준이다.
이 값은 ECDSA 에서만 있어서 한번 정리 해 보았다.

Qt5 에서 Qt6 변경 작업 내용

JayKim — Fri, 6 Oct 2023 17:03:12 +0900

지금까지 Qt5 로 만든 BerEditor, CertMan 그리고 CryptokiMan 프로젝트를 Qt6으로 변경 작업을 하였다.
이번에 Qt6 으로 변경 하면서 수정한 내용을 정리 해 보았다.
현재 아래 내용되로 변경을 해서 컴파일은 되었지만 좀 더 시간을 두고 테스트를 해봐야 한다.

기존 QT버전은 5.13.2에서 6.5.3 버전으로 변경 하였다.

QString sprintf 함수가 asprintf 함수로 변경

-   QString sprint 함수가 asprintf 함수로 변경 됨
- 사실 asprintf 함수에서 0x08X 같은 포맷은 지원이 안되어서 모두 QString 과 arg 를 이용하여 변경 함

QDateTime 클래서에서 Unix타임 처리 함수 변환

-   QDateTime 멤버 함수 setTime_t 는 지원 안되구 setSecsSinceEpoch 로 변경 함
-   QDateTime 멤버 함수 toTime_t 는 지원 안되구 toSecsSinceEpoch 로 변경 함
- 사실 SecsSinceEpoch API 경우 QT5 에서도 지원 됨

QRegExp 에서 QRegularExpression 함수 변환

-   QRegExp 클래스는 사라지고 QRegularExpression 클래스와 QRegularExpressionMatch 클래스 조합으로 정규 표현식 처리함
-   단순 패턴 처리는 클래스 명만 변경 하였지만 패턴 일치 유무는 QRegularExpressionMatch 와 같이 사용 함.
- QRegularExpression과 QRegularExpressionMatch 는 QT5에서도 지원 됨

qSort 함수에서 std::sort 로 변환

-   List에 대한 정렬을 위해 사용 하던 qSort 자체는 지원 안되고 std::sort 로 변경 하여 사용
- std::sort 경우 QT5 에서도 이미 지원 됨

printdialog 기능에서 변경

-   dlg->addEnableOption 함수를 dlg->setOptions 로 변환

ui 헤더 파일에서 font.setWeight 코드 제거

-   invalid conversion from 'int' to 'QFont::Weight' 관련 에러 발생
-   ui 헤더 파일에서 해당 함수 제거 함

QTextCodec 클래스 에러 발생

-   #include <QtCore5Compat/QTextCodec> 헤더 추가 함
-   실제로 Qt6에서는 지원 하지 않지만 Qt5 Compatable 모듈을 설치가 되어 지원 하는거 같음

NAME 관련 변경

-   QT_CHARTS_BEGIN_NAMESPACE -> QT_BEGIN_NAMESPACE
-   QT_CHARTS_END_NAMESPACE -> QT_END_NAMESPACE
-   QT_CHARTS_USE_NAMESPACE -> QT_USE_NAMESPACE

StyleSheet 처리 문제

Qt6 에서는 main.cpp 에서 StyleSheet를 적용하면 전체 폰트 설정이 안되는 곳이 생김
사용하는 cpp에서 해당 Stylesheet 로 적용 처리 후 해당 클래서에서 별도 폰트 다시 지정

아마도 Qt6에서 많은 기능이 변경 되었다고 본다.
여기서는 기존에 만들어진 프로젝트를 변경 하면서 수정 한 내용을 기록 하였다.
아마도 테스트 하다가 수정사항이 생기면 이 문서는 계속 업데이트 예정이다.

Qt5에서보다 Qt6이 좀더 오류에 대해서 엄격해진 느낌도 있다.
그리고 지금까지 MinGW 를 사용하여 개발 하였는데 Qt5에서는 32bit 와 64bit 둘다 지원하였지만.
Qt6에서는 MinGW 64 bit 컴파일러만 지원하였다.

[X509] 공동인증서 본인확인 식별번호 ( VID ) 란?

JayKim — Thu, 5 Oct 2023 18:07:10 +0900

우리나라에서 사용하는 공동 인증서에서 사용하는 본인 확인 식별 번호인 VID 인증서 규격이 있다.
이 규격은 현재 공동 인증서에서 사용된다.
대한민국 국민이라면 누구나 가지고 있는 주민번호가 있는데 이 정보와의 연결 값이 VID 이다

이 값은 인증서에 있는 시리얼 번호랑 다른 것이다.

실제로 VID 값은 주민번호를 바로 사용하는 것이 아니라 해당 주민번호를 변형하여 변형 된 값으로 들어가 있다.
이 값은 실제 주민번호를 알면 VID 정보와 맞는지 확인만 가능한 정보이다.
인증서는 누구에게나 공개된 정보라 VID 때문에 주민 번호가 노출 될 염려는 없다.

이 값은 인증서 프로파일 중 주체 대체 이름( Subject Alternative Name ) 에서 other Name 형식을 사용하여 기록 된다.

아래 그림은 VID 정보를 보여주는 화면이다.

인증서 VID 정보

VID 기술 규격

VID = h ( h(IDN, R))

IDN : 주민 번호
R : 랜덤 값

이렇게 VID 정보는 주민 번호와 랜덤 값의 조합을 해서 두번의 해쉬한 결과 값이다.
실제로 검증하기 위해서는 똑같이 IDN 값과 R을 읽어서 VID 생성을 해서 같은 값이 나오는지 확인 하는 것이다.

참고로 R 값이 랜덤 값은 공동인증서의 개인키에 저장 된다.
그래서 VID 검증을 하기 위해선는 주민 번호와 개인키가 있어야 검증 가능 하다.

식별 번호 ASN.1

id-VID OBJECT IDENTIFIER ::= { id-kisa-identifyData 1 }

VID ::= SEQUENCE {
    hashAlg HashAlgorithm,
    virtualID [0] OCTET STRING }
HashAlgorithm ::= AlgorithmIdentifier

HashContent ::= SEQUENCE {
    idn PrintableString,
    randomNum BIT STRING
}

마무리

공동인증서에서 주민번호와의 맞는지 확인을 위해서 VID 값을 검증한다.
이 값을 검증하기 위해서는 주민 번호를 입력 받거나 알고 있어야 하고 개인키가 있어야 검증이 되는 것이다.
즉 주민번호를 알고 있고 개인키를 가지고 있는 본인만이 확인이 가능한 것이다.

[X509] 인증서 주체자 공개키 정보 및 전자 서명

JayKim — Thu, 21 Sep 2023 09:39:26 +0900

X.509 인증서의 기본 개념은 공개키를 CA가 보증 하는 증명서 역활이다.
인증서는 이 공개키 값과 이를 증명하기 위한 전자 서명 값이 들어간다.
즉 인증서의 핵심 기능이 이것이다.

주체자 공개키 정보

공개키 정보는 해당 인증서에서 사용하는 공개키 정보인데 두가지 값이 들어 있다

algorithm : 해당 공개키가 사용하는 RSA ECC DSA 같은 알고리즘이다.
subjectPublicKey : 실제 공개키 값이 들어 있다. 보통 subjectPublicKey 값의 SHA1 해쉬가 KeyIdentifier 값으로 사용 된다.

RSA 공개키 값에 대한 예제 화면이다

RSA 인증서 공개키 정보

위 예제에서는 RSA 공개키 알고리즘을 사용하는 공개키 값이다.

공개키 정보 ASN.1

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING  }

전자 서명

인증서에 들어 있는 전자 서명 값은 해당 인증서 기본 정보와 확장 필드 모든 값을 원문으로
CA 인증서로 서명한 값이다.
이 값을 증명하기 위해서는 CA 인증서의 공개키 값이 필요하다.

인증서에는 전자 서명과 관련하여 두가지 정보가 들어가는데 바로 전자 서명 알고리즘과 실제 서명 값이다.
전자 서명 알고리즘은 원문을 해쉬하고 그것을 개인키로 암호화 한것이어서
전자서명 알고리즘은 해쉬와 키알고리즘 두가지 값이 있는것이다.

아래 그림은 전자 서명 예시 화면이다.

인증서 서명 알고리즘 및 서명 값

예제 화면에서 전자 서명 알고리즘은 RSA-SHA256 을 사용하였고
실제 서명 값을 볼 수 있다.

전자 서명 ASN.1

     signatureAlgorithm   AlgorithmIdentifier,
     signature            BIT STRING

마무리

인증서는 사실 공개키를 신뢰된 기관으로 부터 증명을 하기 위한것이다.
이 증명에 필요하 가장 기본 정보가 공개키와 전자 서명 두가지 정보이다.
즉 공개키는 신뢰 대상의 키 값이고 이 키가 증명을 하기 위한 값이 전자 서명이다.

[X509] 폐기된 인증서 (Revoked Certificates ) 와 CRL 엔트리 확장 필드 (CRL Entry Extensions)

JayKim — Wed, 20 Sep 2023 09:07:32 +0900

인증서를 사용 하다 보면 인증서가 만료 되지 전에 폐기를 해야 하는 경우가 있다.
인증서 사용자는 사용 인증서를 CA에게 요청을 하고 CA는 인증서를 폐기 후 CRL에 게시를 한다.

CRL 파일에는 폐기된 인증서 정보(Revoked Certificates ) 가 들어 있는데
이 정보가 인증서의 폐기 되었다는 것을 표시 하는 정보이다.
폐기 정보에는 기본적으로 인증서의 일련 번호와 폐지 날짜가 있다. 그리고 CRL 엔트리 확장 필드를 사용해 추가적인 정보가 제공된다.

일련 번호는 해당 인증서의 일련번호 값이다.
폐지 날짜는 인증서를 폐기한 시간 값이다.
그리고 CRL 엔트리 확장 필드를 사용하는데 일반적으로 CRL 엔트리 확장 필드의 Reason Code 값을 사용한다.

아래 그림이 예제 화면이다.

Revoked Certificates

폐기 인증서 ASN.1

     revokedCertificates     SEQUENCE OF SEQUENCE  {
          userCertificate         CertificateSerialNumber,
          revocationDate          Time,
          crlEntryExtensions      Extensions OPTIONAL
                                   -- if present, version MUST be v2
                               }  OPTIONAL,
     crlExtensions           [0] Extensions OPTIONAL }
                                   -- if present, version MUST be v2

CRL 엔트리 확장 필드란

이 형식은 발급된 인증서의 효력정지 및 폐기 사유 및 폐기 시간 정보를 나타낸다.
CRL 엔트리 확장 필드에 나타나는 정보는 3가지이다

폐기 사유 ( Reason Code )
폐기 시간 ( Invalidity Date )
인증서 발급자 ( Certificate Issuer )

이렇게 3가지 이다.

폐기 사유 (Reason Code)

   id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

unspecified : 특별한 폐지 사유가 없는 경우
keyCompromise : 인증서 소유자의 키가 손상된 경우 사용
cACompromise : 인증서 발급자의 키가 손상된 경우 사용
affiliationChanged : 소유자의 명칭 또는 기타 정보가 변경 된 경우 사용
superseded : 키 손상 없이 인증서를 폐지 하고자 하는 경우 사용, 인증서 갱신 처럼 이전 인증서 폐기 때 사용
cessationOfOperation : 더 이상 지정된 목적으로 인증서를 사용하지 않는 경우 사용
certificateHold : 인증서 효력 정지에 사용
removeFromCRL : 델타 인증서 효력 정지 및 폐지 목록과 함께 사용

폐지 일자 (Invalidity Date )

효력 정지 및 폐지 사유가 발생한 시점에 대한 정보를 나타낸다.
시각 정보는 GMT로 표현하며 2049년까지는 UTCTime 형식을 사용하고 2050년은 GeneralizedTime 형식을 사용한다.

인증서 발급자 ( Certificate Issuer )

이 필드는 간접 CRL과 관련하여 CRL 내에 효력 정지 및 폐지된 인증서의 발급기관에 대한 명칭을 나타낸다.
간접 CRL의 첫번째가 이 확장 필드를 사용하지 않았다면 인증서의 발급자가 CRL 발급자와 동일하다는 의미이다.
첫번째 엔트리 이후 후속 엔트리가 없다면 직전 엔트리의 인증서 발급자와 동일 하다고 간주 한다.

마무리

CRL을 사용하여 해당 인증서의 실제 목록 값을 표시한 영역이다.
보통 인증서 검증시 폐기 유무를 확인하게 되어서 이 사용하는 인증서의 시리얼 번호가 존재 유무를 확인 하기 위하여 사용하는 것이다.