"키스토어"의 두 판 사이의 차이
(→자바) |
|||
(같은 사용자의 중간 판 17개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | '''키스토어'''<!--키 스토어-->(Key Store)란 [[암호화폐 지갑]]을 사용하기 위한 [[프라이빗 키]](private key)를 비밀번호로 암호화한 텍스트 또는 파일이다. | + | '''키스토어'''<!--키 스토어-->(Key Store)란 [[암호화폐 지갑]] 을 사용하기 위한 [[프라이빗 키]](private key)를 비밀번호로 암호화한 텍스트 또는 파일이다. |
− | == | + | == 개요 == |
− | + | 키스토어는 텍스트나 파일을 보관하고 있다가, 다른 지갑에 불러올 때 이를 입력한 후 알맞은 비밀번호를 입력하면, 복호화되어 프라이빗 키를 도출할 수 있게 되고, 한 번 암호화된 파일이므로 키스토어 파일은 컴퓨터나 메모장 등에 보관하기 안전하다. 단, 비밀번호가 너무 쉬우면, 무차별대입 공격으로 쉽게 뚫릴 수 있다. 최소 8자, 권장 12자 이상의 어려운 비밀번호 사용을 권장한다.<ref name="키스토어">〈[http://reurl.kr/3334630APC 키스토어가 무엇인가요?]〉, 《미디엄》</ref> | |
− | + | ||
+ | 키스토어를 구현한 공급자에 따라 실제 개인키가 저장되는 곳이 로컬 디스크이든 [[HSM]] 같은 별도의 하드웨어이든 아니면 윈도우(Windows)의 [[써트스토어]](Cert Store)나 [[오에스텐]](OSX)의 [[키 체인]](KeyChain) 이든 상관없이 사용자는 소스 코드 수정 없이 키와 인증서를 가져올 수 있고 이를 이용하여 데이타 암복호화, 전자서명을 수행할 수 있다. [[키툴]](keytool)은 키스토어(Keystore) 기반으로 인증서와 키를 관리할 수 있는 커맨드 방식의 유틸리티로 JDK에 포함되어 있고, 커맨드 방식의 [[openssl]]과 비슷한 용도로 사용할 수 있는 프로그램이다.<ref name="함">lessTif 공식 홈페이지 - https://www.lesstif.com/pages/viewpage.action?pageId=20775436 </ref> | ||
==프라이빗 키== | ==프라이빗 키== | ||
9번째 줄: | 10번째 줄: | ||
* 프라이빗 키를 사용하면 해당 지갑에 접근할 수 있다. 따라서 프라이빗 키를 잘 보관해야 한다. 그런 면에서 비밀번호와 비슷하다고 생각할 수 있지만, 비밀번호와 달리 변경/복구 등이 불가능하다. | * 프라이빗 키를 사용하면 해당 지갑에 접근할 수 있다. 따라서 프라이빗 키를 잘 보관해야 한다. 그런 면에서 비밀번호와 비슷하다고 생각할 수 있지만, 비밀번호와 달리 변경/복구 등이 불가능하다. | ||
* 분실한 프라이빗 키는 어디에서도 찾을 수 없다. 하나의 지갑에는 단 하나의 프라이빗 키만이 존재한다. 프라이빗 키와 이 안의 코인 정보는 전 세계에 퍼져 있는 블록체인 네트워크에 암호화되어 저장된다. | * 분실한 프라이빗 키는 어디에서도 찾을 수 없다. 하나의 지갑에는 단 하나의 프라이빗 키만이 존재한다. 프라이빗 키와 이 안의 코인 정보는 전 세계에 퍼져 있는 블록체인 네트워크에 암호화되어 저장된다. | ||
− | * 암호화폐 지갑이란 이 블록체인 장부를 간편하게 보고, 프라이빗 키를 저장해 두어 입출금을 하기 위한 도구이다. 즉 | + | * [[암호화폐]] 지갑이란 이 블록체인 장부를 간편하게 보고, 프라이빗 키를 저장해 두어 입출금을 하기 위한 도구이다. 즉 은행과 다르며 코인 매니저가 CM 지갑을 운영하지만, 사용자의 돈과 보유 코인 정보들은 코인 매니저 회사에 보관되는 것이 아닌 [[블록체인]] 네트워크에 저장되어 있고 CM 지갑은 이를 간편하게 관리할 수 있게 도와줄 뿐이다.<ref name="키스토어"></ref> |
− | == 이그드라시 | + | == 활용 == |
+ | [[파일:자바 글자.png|썸네일|300픽셀|'''자바'''(Java)]] | ||
+ | === 자바 === | ||
+ | * '''키스토어 유형''' | ||
+ | : [[키툴]](keytool)을 사용할 경우 명시적으로 키스토어 옵션으로 키스토어 파일의 경로를 지정하지 않으면 기본적으로 사용자의 홈디렉터리에서. keystore 파일을 찾게 된다. 키스토어는 여러 가지 타입을 지원하는데 기본적으로는 JKS(Java KeyStore) 라는 타입으로 처리되는데, jks_keystore 라는 파일 이름으로 JKS 방식의 키스토어를 생성하는 명령어로 JKS는 기본 옵션이므로 store type jks 은 생략할 수 있다. | ||
+ | keytool -genkeypair -keystore jks_keystore -storetype jks | ||
+ | : 인증서와 [[개인키]]를 저장하는 또 다른 표준인 [[PKCS12]] 타입을 사용할 경우 다음과 같이 -storetype 옵션을 추가하면 된다. | ||
+ | keytool -genkeypair -keystore pkcs12_keystore -storetype pkcs12 | ||
+ | : 윈도우(Windows) 와 Mac OSX는 OS에 개인키와 인증서를 저장하는 공간이 따로 있는데 키툴로 접근이 가능하며, 윈도우MY는 사용자의 인증서와 개인키를 저장하는 공간이며 윈도우ROOT는 신뢰하는 루트 인증서를 저장하는 공간이다. 오에스텐(OSX)의 키 체인(KeyChain) 에 접근 시 키 체인스토어(Keychain Store)를 타입으로 지정하면 된다. 그외 [[바운시 캐슬]](Bouncy Castle)을 JCE Provider 로 사용할 경우 [[BKS]]타입을 사용할 수 있다.<ref name="함"></ref> | ||
+ | |||
+ | * '''키페어 내 오브잭트 출력''' | ||
+ | :* '''인증서 목록 출력''' : 다음 명령으로 키스토어내 인증서 목록을 출력할 수 있다. | ||
+ | $ keytool -list -keystore my-keystore.jks | ||
+ | : JRE 에 포함되어 있는 기본 인증기관(ca) 인증서 파일은 jre/lib/security/cacerts/cacerts 파일에 존재한다. | ||
+ | $ keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts | ||
+ | : 명령은 기본 ca 목록을 출력한다. | ||
+ | |||
+ | :* '''인증서 수입''' : 수입 증명서(importcert) 명령으로 인증서를 임포트(import)할 수 있어 인증기관 인증서라면 신탁 증명서(trustcacerts) 옵션을 추가한다. | ||
+ | $ keytool -importcert -keystore my-keystore.jks -storepass changeit -trustcacerts -alias rootca -file "rootca.der" | ||
+ | |||
+ | :* '''개인 키 가져오기''' : 키툴은 외부에서 생성된 [[개인 키]](private key)를 키스토어에 임폴트 하는 방법을 제공하지 않으며, 한 가지 방법은 JDK 6 이상부터 PKCS#12으로 된 인증서와 개인키를 키스토어에 임폴트 하는 게 가능하므로 openssl 로 pkcs#12를 만들고 pkcs#12를 키스토어로 임 폴트 하면 된다. 이미 외부에서 개인키와 인증서(mycert.crt)는 생성되었다고 가정하면 인증서와 개인키가 DER 방식으로 인코딩되어있어 openssl 에서 pkcs12 로 변환하지 못하니 PEM 형식으로 변환해야 한다. 에디터로 열어서 다음과 같이 텍스트로 표시되면 PEM 이고 바이너리면 DER이므로 변환해야 한다. | ||
+ | ## 인증서를 PEM으로 변환 | ||
+ | $ openssl x509 -inform der -in mycert.der -out mycert.crt | ||
+ | ## 개인키 변환 | ||
+ | $ openssl rsa -inform der -in mycert.key.der -out mycert.key | ||
+ | :* '''openssl로 PKCS12 생성''' | ||
+ | $ openssl pkcs12 -export -in mycert.crt -inkey mycert.key -out mykeystore.p12 -name "some alias" | ||
+ | : 수출 비밀번호 입력(Enter Export Password)에 pkcs12 암호 입력(예: qwert123) | ||
+ | $ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore my-keystore.jks -srckeystore mykeystore.p12 -srcstoretype PKCS12 -srcstorepass qwert123 -alias "some alias" | ||
+ | : 키툴로 PKCS12를 키스토어로 변환한다.<ref name="함"></ref> {{자세히|자바}} | ||
+ | |||
+ | === 이그드라시 === | ||
+ | [[파일:이그드라시 글자.png|썸네일|300픽셀|'''이그드라시'''(Yggdrash)]] | ||
* '''알고리즘''' | * '''알고리즘''' | ||
− | : 키 알고리즘은 ECDSA secp256k1 알고리즘을 사용하고, 개인키는 32바이트, 공개키는 65바이트, | + | : 키 알고리즘은 ECDSA secp256k1 알고리즘을 사용하고, 개인키는 32바이트, 공개키는 65바이트, 서명 값은 65바이트로 해시 알고리즘은 SHA 3(KECCAK-256)을 사용하며, 32바이트 데이터를 출력한다. 주소는 공개키를 SHA 3 해 쉬한 값에서 뒤로부터 20바이트를 사용하며, 주소 표기는 0x로 시작하고 20바이트 주소 값을 핵사값으로 표기한다. ex) 0x056a8143fdc7416a9b8d59cb4196930588731e9b |
* '''키 암호화 비밀번호''' | * '''키 암호화 비밀번호''' | ||
− | : 개인키를 암호화하는 알고리즘은 AES/CBC/PKCS7Padding로 패스워드 기반 유도 알고리즘은 PBKDF2 이고, 32바이트의 대칭키(AES)가 유도된다. 패스워드 길이는 12 ~ 32자리 이고, 1자 이상의 대문자/소문자/숫자/특수기호를 각각 | + | : 개인키를 암호화하는 알고리즘은 AES/CBC/PKCS7Padding로 패스워드 기반 유도 알고리즘은 PBKDF2 이고, 32바이트의 대칭키(AES)가 유도된다. 패스워드 길이는 12~32자리 이고, 1자 이상의 대문자/소문자/숫자/특수기호를 각각 포함해야 하며, 특수기호는 아스키(ASCII) 코드표에서 출력 가능한 문자(0x21-0x2F, 0x3A-0x40, 0x5B-0x60, 0x7B-0x7E)만 허용된다. |
− | * '''키 파일''' : 키파일은 IV(Initialization Vector) | + | * '''키 파일''' : 키파일은 IV(Initialization Vector)16 바이트 와 암호화된 키값 48바이트로 구성되며, 설정 파일에 지정된 디렉터리와 파일명으로 저장된다. |
* '''암호화 구조''' | * '''암호화 구조''' | ||
− | :* '''클라이언트 키스토어''' : 클라이언트에서 KDF는 스크립트, | + | :* '''클라이언트 키스토어''' : 클라이언트에서 KDF는 [[스크립트]], Encryption은aes-256-cbc를 기본으로 사용하며, PBKDF 2의 옵션을 제공한다. [[노드]]와 차이점으로는 다음과 같다. |
:{|class=wikitable width=600 | :{|class=wikitable width=600 | ||
37번째 줄: | 70번째 줄: | ||
|align=center|aes - 128 - cbc | |align=center|aes - 128 - cbc | ||
|} | |} | ||
− | + | : '''KDF 알고리즘 비교''' | |
− | + | * '''비크립트'''(bcrypt) : [[비크립트]]는 애초부터 패스워드 저장을 목적으로 설계되었으며, [[닐스 프로보스]](Niels Provos)와 [[데이비드 마지에르]](David Mazi res)가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이며, 비크립트는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고, PBKDF2보다 더 경쟁력이 있다. | |
− | + | * '''PBKDF2''' : 가장 많이 사용되는 키 도출 기능은 PBKDF2(Password-Based Key D. 해시 함수의 컨테이너인 PBKDF2는 솔트를 적용한 후 해시 함수의 반복 횟수를 임의로 선택할 수 있고, PBKDF2는 아주 가볍고 구현하기 쉬우며, SHA와 같이 검증된 해시 함수만을 사용한다. | |
− | : '''키 암호화''' | + | :* '''키 암호화''' |
DIGEST = PBKDF2(PRF, Password, Salt, c, DLen) | DIGEST = PBKDF2(PRF, Password, Salt, c, DLen) | ||
PRF: hmac-sha256 | PRF: hmac-sha256 | ||
51번째 줄: | 84번째 줄: | ||
AES(128b), CBC, PKCS7 Padding | AES(128b), CBC, PKCS7 Padding | ||
− | : '''클라이언트 DB 구조''' | + | :* '''클라이언트 DB 구조''' |
{ | { | ||
{{글자색|"accounts"|#9b48a3}}: [ | {{글자색|"accounts"|#9b48a3}}: [ | ||
67번째 줄: | 100번째 줄: | ||
] | ] | ||
} | } | ||
− | : '''클라이언트 키 파일 사양구조''' | + | :* '''클라이언트 키 파일 사양구조''' |
{ | { | ||
{{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}}, | {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}}, | ||
87번째 줄: | 120번째 줄: | ||
} | } | ||
− | + | * '''스크립트'''(scrypt) : [[스크립트]]는 PBKDF2와 유사한 적응형 키 도출 기능이며 [[콜린 퍼시발]](Colin Percival)이 2012년 9월 17일 설계했다. 스크립트는 다이제스트를 생성할 때 메모리 [[오버헤드]]를 갖도록 설계되어, 억지 기법 공격(brute-force attack)을 시도할 때 병렬화 처리가 매우 어렵워 PBKDF2보다 안전하다고 평가되며 비크립트에 비해 더 경쟁력이 있다. 스크립트는 보안에 아주 민감한 사용자들을 위한 백업 솔루션을 제공하는 타스냅(Tarsnap)에서도 사용하고 있으며, 여러 프로그래밍 언어의 라이브러리로 제공받을 수 있다. PBKDF2와의 차이점이라면, PBKDF2는 가벼운 알고리즘으로써 모든 기기에 구현 가능하다는 장점이 있지만, 이 장점이 역으로 공격자가 가볍게 수백, 수천 개의 병렬 연산으로 무차별 대입 공격을 가능하게 할 수 있다.<ref>이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9 </ref> | |
− | : '''키 암호화''' | + | :* '''키 암호화''' |
DIGEST = scrypt(Password, Salt, N, r, p, DLen) | DIGEST = scrypt(Password, Salt, N, r, p, DLen) | ||
Password | Password | ||
99번째 줄: | 132번째 줄: | ||
AES(512b), CBC, PKCS7 Padding | AES(512b), CBC, PKCS7 Padding | ||
− | : '''클라이언트 DB 구조''' | + | :* '''클라이언트 DB 구조''' |
{ | { | ||
{{글자색|"accounts"|#9b48a3}}: [ | {{글자색|"accounts"|#9b48a3}}: [ | ||
117번째 줄: | 150번째 줄: | ||
} | } | ||
− | : '''클라이언트 키 파일 사양구조''' | + | :* '''클라이언트 키 파일 사양구조''' |
{ | { | ||
{{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}}, | {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}}, | ||
135번째 줄: | 168번째 줄: | ||
} | } | ||
} | } | ||
+ | {{자세히|이그드라시}} | ||
+ | |||
+ | == 키스토어 생성및 삭제 == | ||
+ | ===키스토어 생성=== | ||
+ | 계정에서 사용자 지정 키 스토어를 하나 또는 여러 개 생성할 수 있고, 각 사용자 지정 키 스토어는 동일한 AWS 리전에 있는 AWS 클라우드HSM 클러스터 하나와 연결되며, 사용자 지정 키 스토어를 생성하기 전에 사전 조건을 수집해야 하여, 사용자 지정 키 스토어를 사용할 수 있으려면 먼저 AWS 클라우드HSM 클러스터에 이를 연결해야 한다. | ||
+ | * '''사전 조건 수집''' | ||
+ | : 각각의 AWS KMS 사용자 지정 키 스토어는 AWS 클라우드HSM 클러스터를 기반으로 하며, 사용자 지정 키 스토어를 생성하려면 다른 키 스토어에 아직 연결되어 있지 않은 활성 AWS 클라우드HSM 클러스터를 지정해야 해서 AWS KMS가 사용자를 대신해 키를 생성하고 관리하는 데 사용할 수 있는 클러스터의 HSM에서 전용 CU(Crypto User)를 생성한다.<ref name="공식">aws 공식 홈페이지 - https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/create-keystore.html </ref> | ||
+ | |||
+ | * '''AWS 클라우드HSM 클러스터 선택''' | ||
+ | : 모든 사용자 지정 키 스토어가 단 하나의 AWS 클라우드HSM 클러스터에 연결되면, 사용자 지정 키 스토어에서 고객 마스터키(CMK)를 생성하여, AWS KMS는 AWS KMS의 ID 및 Amazon 리소스 이름(ARN) 같은 CMK [[메타데이터]]를 생성한 다음, 연결 클러스터의 HSM에서 키 구성 요소를 생성한다. 새 AWS 클라우드HSM 클러스터를 생성하거나 기존 클러스터를 사용할 수 있으며, AWS KMS에서 클러스터에 대한 독점적인 액세스가 필요하지 않다. 선택한 AWS 쿨라우드HSM 클러스터가 사용자 지정 키 스토어에 영구적으로 연결되면, 사용자 지정 키 스토어를 생성한 후에 연결 클러스터의 클러스터 ID를 변경할 수 있지만, 지정한 클러스터는 원래 클러스터와 백업 기록을 공유해야 하며, 관련이 없는 클러스터를 사용하려면 사용자 지정 키 스토어를 새로 생성해야 한다. | ||
+ | # 클러스터는 활성 상태여야 한다. 클러스터를 생성해서 이를 초기화하고 플랫폼에 대한 AWS 클라우드HSM 클라이언트 소프트웨어를 설치한 다음, 클러스터를 활성화해야 한다. | ||
+ | # 클러스터가 AWS KMS 사용자 지정 키 스토어와 동일한 계정 및 리전에 있어야 하며, 한 리전에 있는 사용자 지정 키 스토어를 다른 리전의 클러스터와 연결할 수 없으며, 다중 리전 키 인프라를 생성하려면 각 리전에서 키 스토어와 클러스터를 생성해야 한다. | ||
+ | # 클러스터가 계정의 다른 사용자 지정 키 스토어에 연결될 수 없는데, 각각의 사용자 지정 키 스토어는 서로 다른 AWS 클라우드HSM 클러스터에 연결되어야 하고, 사용자 지정 키 스토어에 이미 연결된 클러스터나 연결 클러스터와 백업 기록을 공유하는 클러스터를 지정할 수 없다. 백업 기록을 공유하는 클러스터들은 동일한 클러스터 인증서를 가지고 있는데, 클러스터의 클러스터 인증서를 보려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용한다. | ||
+ | # 리전에서 서로 다른 가용 영역이 두 개 이상인 프라이빗 서브넷으로 클러스터를 구성해야 한다. AWS 클라우드HSM은 모든 가용 영역에서 지원되는 것이 아니어서 해당 리전의 모든 가용 영역에서 프라이빗 서브넷을 생성한다. 기존 클러스터에 대한 서브넷을 재구성할 수 없으며, 클러스터 구성에서 서브넷을 서로 달리하여 백업으로부터 클러스터를 생성할 수 있다. | ||
+ | # 클러스터용 보안 그룹(cloudhsm-cluster--sg)은 포트 2223~2225에서 TCP 트래픽을 허용하는 인바운드 규칙과 아웃바운드 규칙을 포함해야 하는데, 인바운드 규칙의 소스와 아웃바운드 규칙의 대상이 보안 그룹 ID와 일치해야 하며, 규칙은 클러스터를 생성할 때 기본적으로 설정에서 삭제하거나 변경하지 않는다. | ||
+ | # 클러스터는 서로 다른 가용 영역에 활성 HSM을 최소 2개 포함하고 있어야 하는데, HSM의 수를 확인하려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용하여 필요한 경우 HSM을 추가할 수 있다. | ||
+ | |||
+ | * '''트러스트 앵커 인증서 찾기''' : 사용자 지정 키 스토어를 생성할 때 AWS 클라우드HSM 클러스터의 트러스트 앵커 인증서를 AWS KMS로 업로드해야 한다. AWS KMS은 사용자 지정 키 스토어를 클러스터에 연결하기 위해 트러스트 앵커 인증서가 필요하며, 모든 활성 AWS 클라우드HSM 클러스터는 트러스트 앵커 인증서를 갖고, 클러스터를 초기화할 때 이러한 인증서를 생성해서 customerCA.crt 파일에 저장하고 클러스터를 연결하는 호스트에 이를 복사한다. | ||
+ | |||
+ | * '''AWS KMS에 생성''' : 사용자 지정 키 스토어를 관리하기 위해 AWS KMS는 선택한 클러스터의 KMS 사용자 CU(Crypto User) 계정에 로그인한다. 사용자 지정 키 스토어를 생성하기 전에 먼저 KMS 사용자 CU를 생성해야 하고, 사용자 지정 키 스토어를 생성할 때 사용자는 AWS KMS에 kms사용자의 암호를 제공하여, AWS KMS는 연결 AWS 클라우드HSM 클러스터에 사용자 지정 키 스토어를 연결할 때마다 KMS 사용자 암호를 교체한다. KMS 사용자 CU를 생성할 때 2FA 옵션을 지정해서는 안 되며, 그렇게 하면 AWS KMS가 로그인할 수 없고 사용자 지정 키 스토어가 이 AWS 클라우드HSM 클러스터에 연결될 수 없어 2FA를 지정하면 실행 취소를 할 수 없다. 대신에 CU를 삭제한 다음 다시 생성해야 한다. KMS 사용자 CU를 생성하는 절차는 다음과 같다. | ||
+ | # AWS 클라우드HSM 사용자 설명의 클라우드 HMS 관리유틸리티 실행 준비 섹션에 설명된 대로 클라우드 HMS 관리유틸리티를 시작한다. | ||
+ | # 클라우드 HMS 관리유틸리티의 크리에이트 사용자(create User) 명령을 사용하여 KMS 사용자라는 CU를 생성하고, 암호는 7~32자의 영숫자로만 구성되어야 하며, 대소문자가 구분되며 어떤 특수 문자도 포함해서는 안 된다.<ref name="공식"></ref> | ||
+ | aws-cloudhsm> createUser CU kmsuser {{글자색|kmsPswd|#ff0000}} | ||
+ | |||
+ | * '''콘솔 생성''' | ||
+ | : AWS 매니지먼트 콘솔에서 사용자 지정 키 스토어를 생성할 때 워크플로우 과정에서 사전 조건을 추가 및 생성할 수 있으나 이들을 미리 수집하면 프로세스가 더 빨라진다. AWS 매니지먼트 콘솔에 로그인한 후 AWS KMS(key management service) 콘솔을 열어, AWS 리전을 변경하려면 페이지의 오른쪽 위 모서리에 있는 리전 선택기를 사용한다. 탐색 창에서 사용자 지정 키 스토어를 선택하여, 키 스토어 생성을 선택하고, 기억하기 쉬운 사용자 지정 키 스토어 이름을 입력하는데, 이름은 계정에서 고유해야 한다. 사용자 지정 키 스토어의 AWS [[클라우드]]HSM 클러스터를 선택하지 않고 AWS 클라우드HSM 클러스터를 새로 선택하려면 AWS 클라우드HSM 클러스터 만들기 링크를 선택한다. 사용자 지정 키 스토어를 연결하려면 클러스터가 요구 사항을 충족해야 하며, 메뉴에는 사용자 지정 키 스토어에 아직 연결되지 않은 계정 및 리전의 사용자 지정 키 스토어가 표시된다. 파일 업로드를 선택한 다음, 선택한 AWS 클라우드HSM 클러스터의 트러스트 앵커 인증서를 업로하면, 클러스터를 초기화했을 때 생성한 customerCA.crt 파일이다. 선택한 클러스터에서 생성한 kms사용자 CU(Crypto User)의 암호를 입력하여, 만들기(Create)를 선택한다. 절차가 성공하면 계정 및 리전의 사용자 지정 키 스토어 목록에 새로운 사용자 지정 키 스토어가 나타나며, 절차가 실패하면 오류 메시지가 나타나서 문제를 설명하고 이를 수정할 방법에 대한 도움말을 제공한다.<ref name="공식"></ref> | ||
+ | |||
+ | * '''API 생성''' | ||
+ | : 키 스토어 사용자 정의 만들기(CreateCustomKeyStore) 작업은 계정 및 리전의 AWS 클라우드HSM 클러스터에 연결되는 새로운 사용자 지정 키 스토어를 생성한다. 이 예제들은 AWS CLI(Command Line Interface)를 사용하지만, 사용자는 어떤 지원되는 프로그래밍 언어라도 사용할 수 있다. 키 스토어 사용자 정의 만들기 작업에서는 다음과 같은 파라미터 값이 필요하다. | ||
+ | # CustomKeyStoreName – 계정에서 고유한 기억하기 쉬운 사용자 지정 키 스토어의 이름이다. | ||
+ | # CloudHsmClusterId – 사용자 지정 키 스토어를 연결하기 위해 요구 사항을 충족하는 클러스터의 클러스터 ID이다. | ||
+ | # KeyStorePassword – 지정된 클러스터의 kms사용자 CU 계정 암호이다. | ||
+ | # TrustAnchorCertificate – 클러스터를 초기화할 때 생성한 customerCA.crt 파일의 콘텐츠이다. | ||
+ | : 가상의 클러스터 ID를 사용하여, 명령을 실행하기 전에 유효한 클러스터 ID로 이를 바꾼다. | ||
+ | $ aws kms create-custom-key-store | ||
+ | --custom-key-store-name {{글자색|ExampleKeyStore|#ff0000}} / | ||
+ | --cloud-hsm-cluster-id {{글자색|cluster-1a23b4cdefg|#ff0000}} / | ||
+ | --key-store-password {{글자색|kmsPswd|#ff0000}} / | ||
+ | --trust-anchor-certificate {{글자색|<certificate-goes-here>|#ff0000}} | ||
+ | : AWS CLI를 사용 중인 경우에는 콘텐츠 대신에 트러스트 앵커 인증서 파일을 지정할 수 있으며, customerCA.crt 파일은 루트 디렉터리에 있다. | ||
+ | $ aws kms create-custom-key-store | ||
+ | --custom-key-store-name {{글자색|ExampleKeyStore|#ff0000}} / | ||
+ | --cloud-hsm-cluster-id {{글자색|cluster-1a23b4cdefg|#ff0000}} / | ||
+ | --key-store-password {{글자색|kmsPswd|#ff0000}} / | ||
+ | --trust-anchor-certificate {{글자색|file://customerCA.crt|#ff0000}} | ||
+ | : 작업이 성공하면 키스토어 사용자 정의 만들기가 사용자 지정 키 스토어 ID를 반환한다. | ||
+ | { | ||
+ | "CustomKeyStoreId": cks-1234567890abcdef0 | ||
+ | } | ||
+ | : 작업이 실패할 경우 예외로 표시된 오류를 정정하고 다시 시도한다. 사용자 지정 키 스토어를 사용하려면 AWS 클라우드HSM 클러스터에 연결한다.<ref name="공식"></ref> | ||
+ | |||
+ | ===키스토어 삭제=== | ||
+ | 사용자 지정 키 스토어를 삭제하면 AWS KMS가 AWS 클라우드HSM [[클러스터]] 연결에 대한 정보를 포함해 사용자 지정 키 스토어에 대한 모든 메타데이터를 KMS에서 삭제한다. 이 작업은 AWS CloudHSM 클러스터와 그 HSM, 또는 그 사용자에게 영향을 미치지 않으며, 사용자는 지정된 클러스터에 연결된 새로운 사용자 지정 키 스토어를 생성할 수 있지만, 삭제 작업의 실행을 취소할 수는 없다. AWS KMS에서 연결 해제되고 어떠한 고객 마스터키(CMK)도 포함하고 있지 않은 사용자 지정 키 스토어만 삭제할 수 있고, 사용자 지정 키 스토어를 삭제하기 전에 수행한다. 모든 암호화 작업에서 키 스토어의 CMK를 전혀 사용할 필요가 없는지 확인한 다음, 키 스토어에서 모든 CMK의 삭제를 예약한다. 모든 CMK가 삭제되었는지 확인하면, AWS KMS에서 사용자 지정 키 스토어의 연결을 해제한다. 사용자 지정 키 스토어를 삭제하는 대신, 사용자 지정 키 스토어의 연결이 해제되어 있는 동안 사용자 지정 키 스토어와 그 고객 마스터키(CMK)를 관리할 수 있으나 사용자 지정 키 스토어에서 CMK를 생성 또는 사용할 수 없으며, 언제든지 사용자 지정 키 스토어를 다시 연결할 수 있다. AWS 계정의 모든 리전에서 모든 사용자 지정 키 스토어를 삭제했고 추가로 생성할 계획이 없는 경우에는 AWS KMS가 사용자 지정 키 스토어에서 사용하는 서비스 연결 역할을 삭제해야 한다.<ref name="공식"></ref> | ||
+ | |||
+ | * '''콘솔 삭제''' | ||
+ | : AWS 매니지먼트 [[콘솔]]에서 사용자 지정 키 스토어를 삭제하려면 사용자 지정 키 스토어 페이지에서 사용자 지정 키 스토어를 선택하고, AWS 매니지먼트 콘솔에 로그인한 후 AWS KMS( Key Management Service) 콘솔을 연다. AWS 리전을 변경하려면 페이지의 오른쪽 위 모서리에 있는 리전 선택기를 사용하고, 탐색 창에서 사용자 지정 키 스토어를 선택했다면, 제거하고 싶은 사용자 지정 키 스토어를 나타내는 열을 찾는다. 사용자 지정 키 스토어의 상태가 연결 해제 됐으면 사용자 지정 키 스토어를 삭제하기 전에 사용자 지정 키 스토어의 연결 해제가 필요하다. 키 스토어 작업 메뉴에서 사용자 지정 키 스토어 삭제를 선택하면, 작업이 완료되면 성공 메시지가 나타나고, 사용자 지정 키스토어는 더 이상 사용자 지정 키스토어 목록에 나타나지 않는다. 작업이 실패하면 오류 메시지가 나타나서 문제를 설명하고 이를 수정할 방법에 대한 도움말을 제공한다.<ref name="공식"></ref> | ||
+ | |||
+ | * '''API''' | ||
+ | : 사용자 지정 키 스토어를 삭제하려면 키스토어 맞춤삭제 작업을 사용하여, 작업이 성공하지 않으면 AWS KMS가 HTTP 200 응답 및 속성을 포함하지 않는 [[JSON]] 객체를 반환하고, 시작하려면 사용자 지정 키 스토어에 어떤 AWS KMS 고객 [[마스터 키]](CMK)도 포함되어 있지 않은지 확인해야 한다. CMK를 포함하는 사용자 지정 키 스토어를 삭제할 수 없으며, 첫 번째 예제 명령은 [[리스트키]](ListKeys) 및 [[설명키]](describeKey)를 사용하여 가상 키스토어 ID가 cks-1234567890abcdef0인 사용자 지정 키 스토어에서 AWS KMS 고객 마스터 키를 검색한다. 이 경우, 명령은 어떤 CMK도 반환하지 않으며, 스케줄 키 삭제 작업을 사용하여 각 CMK에 대한 삭제를 예약한다. | ||
+ | {{글자색|for|#9b48a3}} key {{글자색|in|#9b48a3}} $(aws kms list-keys --query {{글자색|'Keys[*].KeyId'|#269624}} --output text) ; | ||
+ | {{글자색|do|#9b48a3}} aws kms describe-key --key-id {{글자색|$key|#856829}} | | ||
+ | grep {{글자색|'"CustomKeyStoreId": "|#269624}}{{글자색|cks-1234567890abcdef0|#ff0000}}{{글자색|"'|#269624}} --context 100; {{글자색|done|#9b48a3}} | ||
+ | |||
+ | : 그런 다음, 사용자 지정 키 스토어의 연결을 해제하면, 예제 명령은 키스토어 연결 끊기 작업을 사용하여 AWS 클라우드HSM 클러스터에서 사용자 지정 키 스토어의 연결을 해제하고, 이 명령을 실행하기 앞서 예제에 나온 사용자 지정 키 스토어 ID를 유효한 ID로 대체한다.<ref name="공식"></ref> | ||
+ | $ aws kms disconnect-custom-key-store --custom-key-store-id {{글자색|cks-1234567890abcdef0|#ff0000}} | ||
+ | : 사용자 지정 키 스토어가 연결 해제된 후에는 키스토어 맞춤삭제 작업을 사용하여 이를 삭제할 수 있다. | ||
+ | $ aws kms delete-custom-key-store --custom-key-store-id {{글자색|cks-1234567890abcdef0|#ff0000}} | ||
+ | |||
140번째 줄: | 241번째 줄: | ||
==참고자료== | ==참고자료== | ||
− | * CoinManager Dev Team, 〈[http://reurl.kr/3334630APC 키스토어가 무엇인가요?]〉, 《미디엄》 | + | * 이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9 |
+ | * aws 공식 홈페이지 - https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/create-keystore.html | ||
+ | * lessTif 공식 홈페이지 - https://www.lesstif.com/pages/viewpage.action?pageId=20775436 | ||
+ | * CoinManager Dev Team, 〈[http://reurl.kr/3334630APC 키스토어가 무엇인가요?]〉, 《미디엄》 | ||
==같이 보기== | ==같이 보기== | ||
146번째 줄: | 250번째 줄: | ||
* [[블록체인 키스토어]] | * [[블록체인 키스토어]] | ||
− | {{블록체인 기술| | + | {{블록체인 기술|검토 필요}} |
2019년 9월 6일 (금) 17:03 기준 최신판
키스토어(Key Store)란 암호화폐 지갑 을 사용하기 위한 프라이빗 키(private key)를 비밀번호로 암호화한 텍스트 또는 파일이다.
개요[편집]
키스토어는 텍스트나 파일을 보관하고 있다가, 다른 지갑에 불러올 때 이를 입력한 후 알맞은 비밀번호를 입력하면, 복호화되어 프라이빗 키를 도출할 수 있게 되고, 한 번 암호화된 파일이므로 키스토어 파일은 컴퓨터나 메모장 등에 보관하기 안전하다. 단, 비밀번호가 너무 쉬우면, 무차별대입 공격으로 쉽게 뚫릴 수 있다. 최소 8자, 권장 12자 이상의 어려운 비밀번호 사용을 권장한다.[1]
키스토어를 구현한 공급자에 따라 실제 개인키가 저장되는 곳이 로컬 디스크이든 HSM 같은 별도의 하드웨어이든 아니면 윈도우(Windows)의 써트스토어(Cert Store)나 오에스텐(OSX)의 키 체인(KeyChain) 이든 상관없이 사용자는 소스 코드 수정 없이 키와 인증서를 가져올 수 있고 이를 이용하여 데이타 암복호화, 전자서명을 수행할 수 있다. 키툴(keytool)은 키스토어(Keystore) 기반으로 인증서와 키를 관리할 수 있는 커맨드 방식의 유틸리티로 JDK에 포함되어 있고, 커맨드 방식의 openssl과 비슷한 용도로 사용할 수 있는 프로그램이다.[2]
프라이빗 키[편집]
- 암호화폐 지갑은 블록체인 네트워크에서 사용자들의 코인이 저장되는 공간이다. 모든 지갑은 고유한 주소가 존재하며, 이 주소와 1:1 대응되는 비밀번호와 같은 역할을 하는 프라이빗 키가 존재한다.
- 프라이빗 키를 사용하면 해당 지갑에 접근할 수 있다. 따라서 프라이빗 키를 잘 보관해야 한다. 그런 면에서 비밀번호와 비슷하다고 생각할 수 있지만, 비밀번호와 달리 변경/복구 등이 불가능하다.
- 분실한 프라이빗 키는 어디에서도 찾을 수 없다. 하나의 지갑에는 단 하나의 프라이빗 키만이 존재한다. 프라이빗 키와 이 안의 코인 정보는 전 세계에 퍼져 있는 블록체인 네트워크에 암호화되어 저장된다.
- 암호화폐 지갑이란 이 블록체인 장부를 간편하게 보고, 프라이빗 키를 저장해 두어 입출금을 하기 위한 도구이다. 즉 은행과 다르며 코인 매니저가 CM 지갑을 운영하지만, 사용자의 돈과 보유 코인 정보들은 코인 매니저 회사에 보관되는 것이 아닌 블록체인 네트워크에 저장되어 있고 CM 지갑은 이를 간편하게 관리할 수 있게 도와줄 뿐이다.[1]
활용[편집]
자바[편집]
- 키스토어 유형
- 키툴(keytool)을 사용할 경우 명시적으로 키스토어 옵션으로 키스토어 파일의 경로를 지정하지 않으면 기본적으로 사용자의 홈디렉터리에서. keystore 파일을 찾게 된다. 키스토어는 여러 가지 타입을 지원하는데 기본적으로는 JKS(Java KeyStore) 라는 타입으로 처리되는데, jks_keystore 라는 파일 이름으로 JKS 방식의 키스토어를 생성하는 명령어로 JKS는 기본 옵션이므로 store type jks 은 생략할 수 있다.
keytool -genkeypair -keystore jks_keystore -storetype jks
keytool -genkeypair -keystore pkcs12_keystore -storetype pkcs12
- 윈도우(Windows) 와 Mac OSX는 OS에 개인키와 인증서를 저장하는 공간이 따로 있는데 키툴로 접근이 가능하며, 윈도우MY는 사용자의 인증서와 개인키를 저장하는 공간이며 윈도우ROOT는 신뢰하는 루트 인증서를 저장하는 공간이다. 오에스텐(OSX)의 키 체인(KeyChain) 에 접근 시 키 체인스토어(Keychain Store)를 타입으로 지정하면 된다. 그외 바운시 캐슬(Bouncy Castle)을 JCE Provider 로 사용할 경우 BKS타입을 사용할 수 있다.[2]
- 키페어 내 오브잭트 출력
- 인증서 목록 출력 : 다음 명령으로 키스토어내 인증서 목록을 출력할 수 있다.
$ keytool -list -keystore my-keystore.jks
- JRE 에 포함되어 있는 기본 인증기관(ca) 인증서 파일은 jre/lib/security/cacerts/cacerts 파일에 존재한다.
$ keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
- 명령은 기본 ca 목록을 출력한다.
- 인증서 수입 : 수입 증명서(importcert) 명령으로 인증서를 임포트(import)할 수 있어 인증기관 인증서라면 신탁 증명서(trustcacerts) 옵션을 추가한다.
$ keytool -importcert -keystore my-keystore.jks -storepass changeit -trustcacerts -alias rootca -file "rootca.der"
- 개인 키 가져오기 : 키툴은 외부에서 생성된 개인 키(private key)를 키스토어에 임폴트 하는 방법을 제공하지 않으며, 한 가지 방법은 JDK 6 이상부터 PKCS#12으로 된 인증서와 개인키를 키스토어에 임폴트 하는 게 가능하므로 openssl 로 pkcs#12를 만들고 pkcs#12를 키스토어로 임 폴트 하면 된다. 이미 외부에서 개인키와 인증서(mycert.crt)는 생성되었다고 가정하면 인증서와 개인키가 DER 방식으로 인코딩되어있어 openssl 에서 pkcs12 로 변환하지 못하니 PEM 형식으로 변환해야 한다. 에디터로 열어서 다음과 같이 텍스트로 표시되면 PEM 이고 바이너리면 DER이므로 변환해야 한다.
## 인증서를 PEM으로 변환 $ openssl x509 -inform der -in mycert.der -out mycert.crt ## 개인키 변환 $ openssl rsa -inform der -in mycert.key.der -out mycert.key
- openssl로 PKCS12 생성
$ openssl pkcs12 -export -in mycert.crt -inkey mycert.key -out mykeystore.p12 -name "some alias"
- 수출 비밀번호 입력(Enter Export Password)에 pkcs12 암호 입력(예: qwert123)
$ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore my-keystore.jks -srckeystore mykeystore.p12 -srcstoretype PKCS12 -srcstorepass qwert123 -alias "some alias"
- 키툴로 PKCS12를 키스토어로 변환한다.[2] 자바에 대해 자세히 보기
이그드라시[편집]
- 알고리즘
- 키 알고리즘은 ECDSA secp256k1 알고리즘을 사용하고, 개인키는 32바이트, 공개키는 65바이트, 서명 값은 65바이트로 해시 알고리즘은 SHA 3(KECCAK-256)을 사용하며, 32바이트 데이터를 출력한다. 주소는 공개키를 SHA 3 해 쉬한 값에서 뒤로부터 20바이트를 사용하며, 주소 표기는 0x로 시작하고 20바이트 주소 값을 핵사값으로 표기한다. ex) 0x056a8143fdc7416a9b8d59cb4196930588731e9b
- 키 암호화 비밀번호
- 개인키를 암호화하는 알고리즘은 AES/CBC/PKCS7Padding로 패스워드 기반 유도 알고리즘은 PBKDF2 이고, 32바이트의 대칭키(AES)가 유도된다. 패스워드 길이는 12~32자리 이고, 1자 이상의 대문자/소문자/숫자/특수기호를 각각 포함해야 하며, 특수기호는 아스키(ASCII) 코드표에서 출력 가능한 문자(0x21-0x2F, 0x3A-0x40, 0x5B-0x60, 0x7B-0x7E)만 허용된다.
- 키 파일 : 키파일은 IV(Initialization Vector)16 바이트 와 암호화된 키값 48바이트로 구성되며, 설정 파일에 지정된 디렉터리와 파일명으로 저장된다.
- 암호화 구조
노드와 차이점 이름 클라이언트 노드 kd PBKDF2, SCRYPT(option) PBKDF2 encrypte aes - 128 - cbc, aes -256 cbc(option) aes - 128 - cbc
- KDF 알고리즘 비교
- 비크립트(bcrypt) : 비크립트는 애초부터 패스워드 저장을 목적으로 설계되었으며, 닐스 프로보스(Niels Provos)와 데이비드 마지에르(David Mazi res)가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이며, 비크립트는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고, PBKDF2보다 더 경쟁력이 있다.
- PBKDF2 : 가장 많이 사용되는 키 도출 기능은 PBKDF2(Password-Based Key D. 해시 함수의 컨테이너인 PBKDF2는 솔트를 적용한 후 해시 함수의 반복 횟수를 임의로 선택할 수 있고, PBKDF2는 아주 가볍고 구현하기 쉬우며, SHA와 같이 검증된 해시 함수만을 사용한다.
- 키 암호화
DIGEST = PBKDF2(PRF, Password, Salt, c, DLen) PRF: hmac-sha256 Password Salt: keccak256(password) c: 262144 DLen: 32B AES(128b), CBC, PKCS7 Padding
- 클라이언트 DB 구조
{ "accounts": [ { "address": "97995C6B3067764F1Fa3972814331df80004c9d7", "encryptedKey": "6a30d30e2d4fb11f9524214bf98d5648d888f1280b624b6148bf02f0866039e7b5c636410e960f97589a5da703c9a264", "iv": "f96fedb017c9e51f1056e6ee1a526711", "kdfParams": { "dklen": 32, "salt": "fa3a56b2c27740bd1b22a107288bcd989261b7f88e16051e4e5f043e21440524", "c": 4000, "prf": "hmac-sha256" } } ] }
- 클라이언트 키 파일 사양구조
{ "address": "d21307c7c57320dfd21fb805f18c70a1a8b2f1c5", "crypto": { "cipher": "aes-128-cbc", "cipherparams": { "iv": "2a8908f116079b804f1bc4e46181db92" }, "ciphertext": "35f62f87336d51a63047230074de88d00ab334684cbb5909a9d1c0ee37a34ac5e40e0da858f0b7d021d85e67c4066e55", "kdf": "pbkdf2", "kdfparams": { "c": 262144, "dklen": 32, "prf": "hmac-sha256", "salt": "3c1c0475ae162df514856769f0050c0a879013c31c6dff871d86d21111050298" }, "mac": "60d2321155dab16e1d73753669fdbb21ea9b65030996994559a52dcd653f51b1" } }
- 스크립트(scrypt) : 스크립트는 PBKDF2와 유사한 적응형 키 도출 기능이며 콜린 퍼시발(Colin Percival)이 2012년 9월 17일 설계했다. 스크립트는 다이제스트를 생성할 때 메모리 오버헤드를 갖도록 설계되어, 억지 기법 공격(brute-force attack)을 시도할 때 병렬화 처리가 매우 어렵워 PBKDF2보다 안전하다고 평가되며 비크립트에 비해 더 경쟁력이 있다. 스크립트는 보안에 아주 민감한 사용자들을 위한 백업 솔루션을 제공하는 타스냅(Tarsnap)에서도 사용하고 있으며, 여러 프로그래밍 언어의 라이브러리로 제공받을 수 있다. PBKDF2와의 차이점이라면, PBKDF2는 가벼운 알고리즘으로써 모든 기기에 구현 가능하다는 장점이 있지만, 이 장점이 역으로 공격자가 가볍게 수백, 수천 개의 병렬 연산으로 무차별 대입 공격을 가능하게 할 수 있다.[3]
- 키 암호화
DIGEST = scrypt(Password, Salt, N, r, p, DLen) Password Salt: randomBytes(32B) N: 262144 r: 8 p: 1 DLen: 32B AES(512b), CBC, PKCS7 Padding
- 클라이언트 DB 구조
{ "accounts": [ { "address": "8370416C75C48f4e26B84CDD79D57f7b629E861E", "encryptedKey": "efb8a91edbd2518a64774f9074781b6d8f8bfa2ff47bba8bd31faf437f87b8f3442cdb24b80d79fca6bdb2ff1497d2fc", "iv": "8b135a3c533aeffff4babbc3052c9120", "kdfParams": { "dklen": 32, "salt": "37e9b309d6ff35df9745386df5979353541e41a1ccc84ebf5b0b78bda7e336bc", "n": 4096, "r": 8, "p": 1 } } ] }
- 클라이언트 키 파일 사양구조
{ "address": "d21307c7c57320dfd21fb805f18c70a1a8b2f1c5", "crypto": { "cipher": "aes-128-cbc", "cipherparams": { "iv": "2a8908f116079b804f1bc4e46181db92" }, "ciphertext": "35f62f87336d51a63047230074de88d00ab334684cbb5909a9d1c0ee37a34ac5e40e0da858f0b7d021d85e67c4066e55", "kdf": "pbkdf2", "kdfparams": { "n": 4086, "r": "8" "p": 1, }, "mac": "60d2321155dab16e1d73753669fdbb21ea9b65030996994559a52dcd653f51b1" } }
키스토어 생성및 삭제[편집]
키스토어 생성[편집]
계정에서 사용자 지정 키 스토어를 하나 또는 여러 개 생성할 수 있고, 각 사용자 지정 키 스토어는 동일한 AWS 리전에 있는 AWS 클라우드HSM 클러스터 하나와 연결되며, 사용자 지정 키 스토어를 생성하기 전에 사전 조건을 수집해야 하여, 사용자 지정 키 스토어를 사용할 수 있으려면 먼저 AWS 클라우드HSM 클러스터에 이를 연결해야 한다.
- 사전 조건 수집
- 각각의 AWS KMS 사용자 지정 키 스토어는 AWS 클라우드HSM 클러스터를 기반으로 하며, 사용자 지정 키 스토어를 생성하려면 다른 키 스토어에 아직 연결되어 있지 않은 활성 AWS 클라우드HSM 클러스터를 지정해야 해서 AWS KMS가 사용자를 대신해 키를 생성하고 관리하는 데 사용할 수 있는 클러스터의 HSM에서 전용 CU(Crypto User)를 생성한다.[4]
- AWS 클라우드HSM 클러스터 선택
- 모든 사용자 지정 키 스토어가 단 하나의 AWS 클라우드HSM 클러스터에 연결되면, 사용자 지정 키 스토어에서 고객 마스터키(CMK)를 생성하여, AWS KMS는 AWS KMS의 ID 및 Amazon 리소스 이름(ARN) 같은 CMK 메타데이터를 생성한 다음, 연결 클러스터의 HSM에서 키 구성 요소를 생성한다. 새 AWS 클라우드HSM 클러스터를 생성하거나 기존 클러스터를 사용할 수 있으며, AWS KMS에서 클러스터에 대한 독점적인 액세스가 필요하지 않다. 선택한 AWS 쿨라우드HSM 클러스터가 사용자 지정 키 스토어에 영구적으로 연결되면, 사용자 지정 키 스토어를 생성한 후에 연결 클러스터의 클러스터 ID를 변경할 수 있지만, 지정한 클러스터는 원래 클러스터와 백업 기록을 공유해야 하며, 관련이 없는 클러스터를 사용하려면 사용자 지정 키 스토어를 새로 생성해야 한다.
- 클러스터는 활성 상태여야 한다. 클러스터를 생성해서 이를 초기화하고 플랫폼에 대한 AWS 클라우드HSM 클라이언트 소프트웨어를 설치한 다음, 클러스터를 활성화해야 한다.
- 클러스터가 AWS KMS 사용자 지정 키 스토어와 동일한 계정 및 리전에 있어야 하며, 한 리전에 있는 사용자 지정 키 스토어를 다른 리전의 클러스터와 연결할 수 없으며, 다중 리전 키 인프라를 생성하려면 각 리전에서 키 스토어와 클러스터를 생성해야 한다.
- 클러스터가 계정의 다른 사용자 지정 키 스토어에 연결될 수 없는데, 각각의 사용자 지정 키 스토어는 서로 다른 AWS 클라우드HSM 클러스터에 연결되어야 하고, 사용자 지정 키 스토어에 이미 연결된 클러스터나 연결 클러스터와 백업 기록을 공유하는 클러스터를 지정할 수 없다. 백업 기록을 공유하는 클러스터들은 동일한 클러스터 인증서를 가지고 있는데, 클러스터의 클러스터 인증서를 보려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용한다.
- 리전에서 서로 다른 가용 영역이 두 개 이상인 프라이빗 서브넷으로 클러스터를 구성해야 한다. AWS 클라우드HSM은 모든 가용 영역에서 지원되는 것이 아니어서 해당 리전의 모든 가용 영역에서 프라이빗 서브넷을 생성한다. 기존 클러스터에 대한 서브넷을 재구성할 수 없으며, 클러스터 구성에서 서브넷을 서로 달리하여 백업으로부터 클러스터를 생성할 수 있다.
- 클러스터용 보안 그룹(cloudhsm-cluster--sg)은 포트 2223~2225에서 TCP 트래픽을 허용하는 인바운드 규칙과 아웃바운드 규칙을 포함해야 하는데, 인바운드 규칙의 소스와 아웃바운드 규칙의 대상이 보안 그룹 ID와 일치해야 하며, 규칙은 클러스터를 생성할 때 기본적으로 설정에서 삭제하거나 변경하지 않는다.
- 클러스터는 서로 다른 가용 영역에 활성 HSM을 최소 2개 포함하고 있어야 하는데, HSM의 수를 확인하려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용하여 필요한 경우 HSM을 추가할 수 있다.
- 트러스트 앵커 인증서 찾기 : 사용자 지정 키 스토어를 생성할 때 AWS 클라우드HSM 클러스터의 트러스트 앵커 인증서를 AWS KMS로 업로드해야 한다. AWS KMS은 사용자 지정 키 스토어를 클러스터에 연결하기 위해 트러스트 앵커 인증서가 필요하며, 모든 활성 AWS 클라우드HSM 클러스터는 트러스트 앵커 인증서를 갖고, 클러스터를 초기화할 때 이러한 인증서를 생성해서 customerCA.crt 파일에 저장하고 클러스터를 연결하는 호스트에 이를 복사한다.
- AWS KMS에 생성 : 사용자 지정 키 스토어를 관리하기 위해 AWS KMS는 선택한 클러스터의 KMS 사용자 CU(Crypto User) 계정에 로그인한다. 사용자 지정 키 스토어를 생성하기 전에 먼저 KMS 사용자 CU를 생성해야 하고, 사용자 지정 키 스토어를 생성할 때 사용자는 AWS KMS에 kms사용자의 암호를 제공하여, AWS KMS는 연결 AWS 클라우드HSM 클러스터에 사용자 지정 키 스토어를 연결할 때마다 KMS 사용자 암호를 교체한다. KMS 사용자 CU를 생성할 때 2FA 옵션을 지정해서는 안 되며, 그렇게 하면 AWS KMS가 로그인할 수 없고 사용자 지정 키 스토어가 이 AWS 클라우드HSM 클러스터에 연결될 수 없어 2FA를 지정하면 실행 취소를 할 수 없다. 대신에 CU를 삭제한 다음 다시 생성해야 한다. KMS 사용자 CU를 생성하는 절차는 다음과 같다.
- AWS 클라우드HSM 사용자 설명의 클라우드 HMS 관리유틸리티 실행 준비 섹션에 설명된 대로 클라우드 HMS 관리유틸리티를 시작한다.
- 클라우드 HMS 관리유틸리티의 크리에이트 사용자(create User) 명령을 사용하여 KMS 사용자라는 CU를 생성하고, 암호는 7~32자의 영숫자로만 구성되어야 하며, 대소문자가 구분되며 어떤 특수 문자도 포함해서는 안 된다.[4]
aws-cloudhsm> createUser CU kmsuser kmsPswd
- 콘솔 생성
- AWS 매니지먼트 콘솔에서 사용자 지정 키 스토어를 생성할 때 워크플로우 과정에서 사전 조건을 추가 및 생성할 수 있으나 이들을 미리 수집하면 프로세스가 더 빨라진다. AWS 매니지먼트 콘솔에 로그인한 후 AWS KMS(key management service) 콘솔을 열어, AWS 리전을 변경하려면 페이지의 오른쪽 위 모서리에 있는 리전 선택기를 사용한다. 탐색 창에서 사용자 지정 키 스토어를 선택하여, 키 스토어 생성을 선택하고, 기억하기 쉬운 사용자 지정 키 스토어 이름을 입력하는데, 이름은 계정에서 고유해야 한다. 사용자 지정 키 스토어의 AWS 클라우드HSM 클러스터를 선택하지 않고 AWS 클라우드HSM 클러스터를 새로 선택하려면 AWS 클라우드HSM 클러스터 만들기 링크를 선택한다. 사용자 지정 키 스토어를 연결하려면 클러스터가 요구 사항을 충족해야 하며, 메뉴에는 사용자 지정 키 스토어에 아직 연결되지 않은 계정 및 리전의 사용자 지정 키 스토어가 표시된다. 파일 업로드를 선택한 다음, 선택한 AWS 클라우드HSM 클러스터의 트러스트 앵커 인증서를 업로하면, 클러스터를 초기화했을 때 생성한 customerCA.crt 파일이다. 선택한 클러스터에서 생성한 kms사용자 CU(Crypto User)의 암호를 입력하여, 만들기(Create)를 선택한다. 절차가 성공하면 계정 및 리전의 사용자 지정 키 스토어 목록에 새로운 사용자 지정 키 스토어가 나타나며, 절차가 실패하면 오류 메시지가 나타나서 문제를 설명하고 이를 수정할 방법에 대한 도움말을 제공한다.[4]
- API 생성
- 키 스토어 사용자 정의 만들기(CreateCustomKeyStore) 작업은 계정 및 리전의 AWS 클라우드HSM 클러스터에 연결되는 새로운 사용자 지정 키 스토어를 생성한다. 이 예제들은 AWS CLI(Command Line Interface)를 사용하지만, 사용자는 어떤 지원되는 프로그래밍 언어라도 사용할 수 있다. 키 스토어 사용자 정의 만들기 작업에서는 다음과 같은 파라미터 값이 필요하다.
- CustomKeyStoreName – 계정에서 고유한 기억하기 쉬운 사용자 지정 키 스토어의 이름이다.
- CloudHsmClusterId – 사용자 지정 키 스토어를 연결하기 위해 요구 사항을 충족하는 클러스터의 클러스터 ID이다.
- KeyStorePassword – 지정된 클러스터의 kms사용자 CU 계정 암호이다.
- TrustAnchorCertificate – 클러스터를 초기화할 때 생성한 customerCA.crt 파일의 콘텐츠이다.
- 가상의 클러스터 ID를 사용하여, 명령을 실행하기 전에 유효한 클러스터 ID로 이를 바꾼다.
$ aws kms create-custom-key-store --custom-key-store-name ExampleKeyStore / --cloud-hsm-cluster-id cluster-1a23b4cdefg / --key-store-password kmsPswd / --trust-anchor-certificate <certificate-goes-here>
- AWS CLI를 사용 중인 경우에는 콘텐츠 대신에 트러스트 앵커 인증서 파일을 지정할 수 있으며, customerCA.crt 파일은 루트 디렉터리에 있다.
$ aws kms create-custom-key-store --custom-key-store-name ExampleKeyStore / --cloud-hsm-cluster-id cluster-1a23b4cdefg / --key-store-password kmsPswd / --trust-anchor-certificate file://customerCA.crt
- 작업이 성공하면 키스토어 사용자 정의 만들기가 사용자 지정 키 스토어 ID를 반환한다.
{ "CustomKeyStoreId": cks-1234567890abcdef0 }
- 작업이 실패할 경우 예외로 표시된 오류를 정정하고 다시 시도한다. 사용자 지정 키 스토어를 사용하려면 AWS 클라우드HSM 클러스터에 연결한다.[4]
키스토어 삭제[편집]
사용자 지정 키 스토어를 삭제하면 AWS KMS가 AWS 클라우드HSM 클러스터 연결에 대한 정보를 포함해 사용자 지정 키 스토어에 대한 모든 메타데이터를 KMS에서 삭제한다. 이 작업은 AWS CloudHSM 클러스터와 그 HSM, 또는 그 사용자에게 영향을 미치지 않으며, 사용자는 지정된 클러스터에 연결된 새로운 사용자 지정 키 스토어를 생성할 수 있지만, 삭제 작업의 실행을 취소할 수는 없다. AWS KMS에서 연결 해제되고 어떠한 고객 마스터키(CMK)도 포함하고 있지 않은 사용자 지정 키 스토어만 삭제할 수 있고, 사용자 지정 키 스토어를 삭제하기 전에 수행한다. 모든 암호화 작업에서 키 스토어의 CMK를 전혀 사용할 필요가 없는지 확인한 다음, 키 스토어에서 모든 CMK의 삭제를 예약한다. 모든 CMK가 삭제되었는지 확인하면, AWS KMS에서 사용자 지정 키 스토어의 연결을 해제한다. 사용자 지정 키 스토어를 삭제하는 대신, 사용자 지정 키 스토어의 연결이 해제되어 있는 동안 사용자 지정 키 스토어와 그 고객 마스터키(CMK)를 관리할 수 있으나 사용자 지정 키 스토어에서 CMK를 생성 또는 사용할 수 없으며, 언제든지 사용자 지정 키 스토어를 다시 연결할 수 있다. AWS 계정의 모든 리전에서 모든 사용자 지정 키 스토어를 삭제했고 추가로 생성할 계획이 없는 경우에는 AWS KMS가 사용자 지정 키 스토어에서 사용하는 서비스 연결 역할을 삭제해야 한다.[4]
- 콘솔 삭제
- AWS 매니지먼트 콘솔에서 사용자 지정 키 스토어를 삭제하려면 사용자 지정 키 스토어 페이지에서 사용자 지정 키 스토어를 선택하고, AWS 매니지먼트 콘솔에 로그인한 후 AWS KMS( Key Management Service) 콘솔을 연다. AWS 리전을 변경하려면 페이지의 오른쪽 위 모서리에 있는 리전 선택기를 사용하고, 탐색 창에서 사용자 지정 키 스토어를 선택했다면, 제거하고 싶은 사용자 지정 키 스토어를 나타내는 열을 찾는다. 사용자 지정 키 스토어의 상태가 연결 해제 됐으면 사용자 지정 키 스토어를 삭제하기 전에 사용자 지정 키 스토어의 연결 해제가 필요하다. 키 스토어 작업 메뉴에서 사용자 지정 키 스토어 삭제를 선택하면, 작업이 완료되면 성공 메시지가 나타나고, 사용자 지정 키스토어는 더 이상 사용자 지정 키스토어 목록에 나타나지 않는다. 작업이 실패하면 오류 메시지가 나타나서 문제를 설명하고 이를 수정할 방법에 대한 도움말을 제공한다.[4]
- API
- 사용자 지정 키 스토어를 삭제하려면 키스토어 맞춤삭제 작업을 사용하여, 작업이 성공하지 않으면 AWS KMS가 HTTP 200 응답 및 속성을 포함하지 않는 JSON 객체를 반환하고, 시작하려면 사용자 지정 키 스토어에 어떤 AWS KMS 고객 마스터 키(CMK)도 포함되어 있지 않은지 확인해야 한다. CMK를 포함하는 사용자 지정 키 스토어를 삭제할 수 없으며, 첫 번째 예제 명령은 리스트키(ListKeys) 및 설명키(describeKey)를 사용하여 가상 키스토어 ID가 cks-1234567890abcdef0인 사용자 지정 키 스토어에서 AWS KMS 고객 마스터 키를 검색한다. 이 경우, 명령은 어떤 CMK도 반환하지 않으며, 스케줄 키 삭제 작업을 사용하여 각 CMK에 대한 삭제를 예약한다.
for key in $(aws kms list-keys --query 'Keys[*].KeyId' --output text) ; do aws kms describe-key --key-id $key | grep '"CustomKeyStoreId": "cks-1234567890abcdef0"' --context 100; done
- 그런 다음, 사용자 지정 키 스토어의 연결을 해제하면, 예제 명령은 키스토어 연결 끊기 작업을 사용하여 AWS 클라우드HSM 클러스터에서 사용자 지정 키 스토어의 연결을 해제하고, 이 명령을 실행하기 앞서 예제에 나온 사용자 지정 키 스토어 ID를 유효한 ID로 대체한다.[4]
$ aws kms disconnect-custom-key-store --custom-key-store-id cks-1234567890abcdef0
- 사용자 지정 키 스토어가 연결 해제된 후에는 키스토어 맞춤삭제 작업을 사용하여 이를 삭제할 수 있다.
$ aws kms delete-custom-key-store --custom-key-store-id cks-1234567890abcdef0
각주[편집]
- ↑ 1.0 1.1 〈키스토어가 무엇인가요?〉, 《미디엄》
- ↑ 2.0 2.1 2.2 lessTif 공식 홈페이지 - https://www.lesstif.com/pages/viewpage.action?pageId=20775436
- ↑ 이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 aws 공식 홈페이지 - https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/create-keystore.html
참고자료[편집]
- 이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9
- aws 공식 홈페이지 - https://docs.aws.amazon.com/ko_kr/kms/latest/developerguide/create-keystore.html
- lessTif 공식 홈페이지 - https://www.lesstif.com/pages/viewpage.action?pageId=20775436
- CoinManager Dev Team, 〈키스토어가 무엇인가요?〉, 《미디엄》
같이 보기[편집]