검수요청.png검수요청.png

"키스토어"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
23번째 줄: 23번째 줄:
  
 
* '''키페어 내 오브잭트 출력'''
 
* '''키페어 내 오브잭트 출력'''
−
: '''인증서 목록 출력''' : 다음 명령으로 키스토어내 인증서 목록을 출력할 수 있다.
+
:* '''인증서 목록 출력''' : 다음 명령으로 키스토어내 인증서 목록을 출력할 수 있다.
 
  $ keytool -list -keystore my-keystore.jks
 
  $ keytool -list -keystore my-keystore.jks
 
: JRE 에 포함되어 있는 기본 인증기관(ca) 인증서 파일은 jre/lib/security/cacerts/cacerts 파일에 존재한다.
 
: JRE 에 포함되어 있는 기본 인증기관(ca) 인증서 파일은 jre/lib/security/cacerts/cacerts 파일에 존재한다.
29번째 줄: 29번째 줄:
 
: 명령은 기본 ca 목록을 출력한다.
 
: 명령은 기본 ca 목록을 출력한다.
  
−
: '''인증서 수입''' : 수입 증명서(importcert) 명령으로 인증서를 임포트(import)할 수 있어 인증기관 인증서라면 신탁 증명서(trustcacerts) 옵션을 추가한다.  
+
:* '''인증서 수입''' : 수입 증명서(importcert) 명령으로 인증서를 임포트(import)할 수 있어 인증기관 인증서라면 신탁 증명서(trustcacerts) 옵션을 추가한다.  
 
   $ keytool -importcert -keystore my-keystore.jks -storepass changeit -trustcacerts -alias rootca -file "rootca.der"
 
   $ 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이므로 변환해야 한다.
+
:* '''개인 키 가져오기''' : 키툴은 외부에서 생성된 [[개인 키]](private key)를 키스토어에 임폴트 하는 방법을 제공하지 않으며, 한 가지 방법은 JDK 6 이상부터 PKCS#12으로 된 인증서와 개인키를 키스토어에 임폴트 하는 게 가능하므로 openssl 로 pkcs#12를 만들고 pkcs#12를 키스토어로 임 폴트 하면 된다. 이미 외부에서 개인키와 인증서(mycert.crt)는 생성되었다고 가정하면 인증서와 개인키가 DER 방식으로 인코딩되어있어 openssl 에서 pkcs12 로 변환하지 못하니 PEM 형식으로 변환해야 한다. 에디터로 열어서 다음과 같이 텍스트로 표시되면 PEM 이고 바이너리면 DER이므로 변환해야 한다.
 
  ## 인증서를 PEM 으로 변환
 
  ## 인증서를 PEM 으로 변환
 
  $ openssl x509 -inform der -in mycert.der -out mycert.crt
 
  $ openssl x509 -inform der -in mycert.der -out mycert.crt
 
  ## 개인키 변환
 
  ## 개인키 변환
 
  $ openssl rsa -inform der -in mycert.key.der -out mycert.key
 
  $ openssl rsa -inform der -in mycert.key.der -out mycert.key
−
: '''openssl로 PKCS12 생성'''
+
:* '''openssl로 PKCS12 생성'''
 
  $ openssl pkcs12 -export -in mycert.crt -inkey mycert.key -out mykeystore.p12 -name "some alias"
 
  $ openssl pkcs12 -export -in mycert.crt -inkey mycert.key -out mykeystore.p12 -name "some alias"
 
: 수출 비밀번호 입력(Enter Export Password)에 pkcs12 암호 입력(예: qwert123)
 
: 수출 비밀번호 입력(Enter Export Password)에 pkcs12 암호 입력(예: qwert123)
54번째 줄: 54번째 줄:
  
 
* '''암호화 구조'''
 
* '''암호화 구조'''
−
: '''클라이언트 키스토어''' : 클라이언트에서 KDF는 [[스크립트]], Encryption은aes-256-cbc를 기본으로 사용하며, PBKDF 2의 옵션을 제공한다. [[노드]]와 차이점으로는 다음과 같다.
+
:* '''클라이언트 키스토어''' : 클라이언트에서 KDF는 [[스크립트]], Encryption은aes-256-cbc를 기본으로 사용하며, PBKDF 2의 옵션을 제공한다. [[노드]]와 차이점으로는 다음과 같다.
  
 
:{|class=wikitable width=600
 
:{|class=wikitable width=600
71번째 줄: 71번째 줄:
 
|}
 
|}
 
* '''KDF 알고리즘 비교'''
 
* '''KDF 알고리즘 비교'''
−
: '''비크립트'''(bcrypt) : [[비크립트]]는 애초부터 패스워드 저장을 목적으로 설계되었으며, [[닐스 프로보스]](Niels Provos)와 [[데이비드 마지에르]](David Mazi res)가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이며, 비크립트는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고, PBKDF2보다 더 경쟁력이 있다.
+
:* '''비크립트'''(bcrypt) : [[비크립트]]는 애초부터 패스워드 저장을 목적으로 설계되었으며, [[닐스 프로보스]](Niels Provos)와 [[데이비드 마지에르]](David Mazi res)가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이며, 비크립트는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고, PBKDF2보다 더 경쟁력이 있다.
  
−
: '''PBKDF2''' : 가장 많이 사용되는 키 도출 기능은 PBKDF2(Password-Based Key D. 해시 함수의 컨테이너인 PBKDF2는 솔트를 적용한 후 해시 함수의 반복 횟수를 임의로 선택할 수 있고, PBKDF2는 아주 가볍고 구현하기 쉬우며, SHA와 같이 검증된 해시 함수만을 사용한다.
+
:* '''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
84번째 줄: 84번째 줄:
 
  AES(128b), CBC, PKCS7 Padding
 
  AES(128b), CBC, PKCS7 Padding
  
−
: '''클라이언트 DB 구조'''
+
* '''클라이언트 DB 구조'''
 
  {
 
  {
 
   {{글자색|"accounts"|#9b48a3}}: [
 
   {{글자색|"accounts"|#9b48a3}}: [
100번째 줄: 100번째 줄:
 
   ]
 
   ]
 
  }
 
  }
−
: '''클라이언트 키 파일 사양구조'''
+
* '''클라이언트 키 파일 사양구조'''
 
  {
 
  {
 
   {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}},
 
   {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}},
120번째 줄: 120번째 줄:
 
  }
 
  }
  
−
: '''스크립트'''(scrypt) : [[스크립트]]는 PBKDF2와 유사한 적응형 키 도출 기능이며 [[콜린 퍼시발]](Colin Percival)이 2012년 9월 17일 설계했다. 스크립트는 다이제스트를 생성할 때 메모리 [[오버헤드]]를 갖도록 설계되어, 억지 기법 공격(brute-force attack)을 시도할 때 병렬화 처리가 매우 어렵워 PBKDF2보다 안전하다고 평가되며 비크립트에 비해 더 경쟁력이 있다. 스크립트는 보안에 아주 민감한 사용자들을 위한 백업 솔루션을 제공하는 타스냅(Tarsnap)에서도 사용하고 있으며, 여러 프로그래밍 언어의 라이브러리로 제공받을 수 있다. PBKDF2와의 차이점이라면, PBKDF2는 가벼운 알고리즘으로써 모든 기기에 구현 가능하다는 장점이 있지만, 이 장점이 역으로 공격자가 가볍게 수백, 수천 개의 병렬 연산으로 무차별 대입 공격을 가능하게 할 수 있다.<ref>이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9 </ref>
+
* '''스크립트'''(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
132번째 줄: 132번째 줄:
 
  AES(512b), CBC, PKCS7 Padding
 
  AES(512b), CBC, PKCS7 Padding
  
−
: '''클라이언트 DB 구조'''
+
* '''클라이언트 DB 구조'''
 
  {
 
  {
 
   {{글자색|"accounts"|#9b48a3}}: [
 
   {{글자색|"accounts"|#9b48a3}}: [
150번째 줄: 150번째 줄:
 
  }
 
  }
  
−
: '''클라이언트 키 파일 사양구조'''
+
* '''클라이언트 키 파일 사양구조'''
 
  {
 
  {
 
   {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}},
 
   {{글자색|"address"|#9b48a3}}: {{글자색|"d21307c7c57320dfd21fb805f18c70a1a8b2f1c5"|#269624}},
184번째 줄: 184번째 줄:
 
# 클러스터는 서로 다른 가용 영역에 활성 HSM을 최소 2개 포함하고 있어야 하는데, HSM의 수를 확인하려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용하여 필요한 경우 HSM을 추가할 수 있다.
 
# 클러스터는 서로 다른 가용 영역에 활성 HSM을 최소 2개 포함하고 있어야 하는데, HSM의 수를 확인하려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용하여 필요한 경우 HSM을 추가할 수 있다.
  
−
: '''트러스트 앵커 인증서 찾기''' : 사용자 지정 키 스토어를 생성할 때 AWS 클라우드HSM 클러스터의 트러스트 앵커 인증서를 AWS KMS로 업로드해야 한다. AWS KMS은 사용자 지정 키 스토어를 클러스터에 연결하기 위해 트러스트 앵커 인증서가 필요하며, 모든 활성 AWS 클라우드HSM 클러스터는 트러스트 앵커 인증서를 갖고, 클러스터를 초기화할 때 이러한 인증서를 생성해서 customerCA.crt 파일에 저장하고 클러스터를 연결하는 호스트에 이를 복사한다.
+
* '''트러스트 앵커 인증서 찾기''' : 사용자 지정 키 스토어를 생성할 때 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 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 관리유틸리티를 시작한다.
 
# AWS 클라우드HSM 사용자 설명의 클라우드 HMS 관리유틸리티 실행 준비 섹션에 설명된 대로 클라우드 HMS 관리유틸리티를 시작한다.
 
# 클라우드 HMS 관리유틸리티의 크리에이트 사용자(create User) 명령을 사용하여 KMS 사용자라는 CU를 생성하고, 암호는 7~32자의 영숫자로만 구성되어야 하며, 대소문자가 구분되며 어떤 특수 문자도 포함해서는 안 된다.<ref name="공식"></ref>
 
# 클라우드 HMS 관리유틸리티의 크리에이트 사용자(create User) 명령을 사용하여 KMS 사용자라는 CU를 생성하고, 암호는 7~32자의 영숫자로만 구성되어야 하며, 대소문자가 구분되며 어떤 특수 문자도 포함해서는 안 된다.<ref name="공식"></ref>

2019년 9월 6일 (금) 16:59 판

키스토어(Key Store)란 암호화폐 지갑 을 사용하기 위한 프라이빗 키(private key)를 비밀번호로 암호화한 텍스트 또는 파일이다.

개요

키스토어는 텍스트나 파일을 보관하고 있다가, 다른 지갑에 불러올 때 이를 입력한 후 알맞은 비밀번호를 입력하면, 복호화되어 프라이빗 키를 도출할 수 있게 되고, 한 번 암호화된 파일이므로 키스토어 파일은 컴퓨터나 메모장 등에 보관하기 안전하다. 단, 비밀번호가 너무 쉬우면, 무차별대입 공격으로 쉽게 뚫릴 수 있다. 최소 8자, 권장 12자 이상의 어려운 비밀번호 사용을 권장한다.[1]

키스토어를 구현한 공급자에 따라 실제 개인키가 저장되는 곳이 로컬 디스크이든 HSM 같은 별도의 하드웨어이든 아니면 윈도우(Windows)의 써트스토어(Cert Store)나 오에스텐(OSX)의 키 체인(KeyChain) 이든 상관없이 사용자는 소스 코드 수정 없이 키와 인증서를 가져올 수 있고 이를 이용하여 데이타 암복호화, 전자서명을 수행할 수 있다. 키툴(keytool)은 키스토어(Keystore) 기반으로 인증서와 키를 관리할 수 있는 커맨드 방식의 유틸리티로 JDK에 포함되어 있고, 커맨드 방식의 openssl과 비슷한 용도로 사용할 수 있는 프로그램이다.[2]

프라이빗 키

  • 암호화폐 지갑은 블록체인 네트워크에서 사용자들의 코인이 저장되는 공간이다. 모든 지갑은 고유한 주소가 존재하며, 이 주소와 1:1 대응되는 비밀번호와 같은 역할을 하는 프라이빗 키가 존재한다.
  • 프라이빗 키를 사용하면 해당 지갑에 접근할 수 있다. 따라서 프라이빗 키를 잘 보관해야 한다. 그런 면에서 비밀번호와 비슷하다고 생각할 수 있지만, 비밀번호와 달리 변경/복구 등이 불가능하다.
  • 분실한 프라이빗 키는 어디에서도 찾을 수 없다. 하나의 지갑에는 단 하나의 프라이빗 키만이 존재한다. 프라이빗 키와 이 안의 코인 정보는 전 세계에 퍼져 있는 블록체인 네트워크에 암호화되어 저장된다.
  • 암호화폐 지갑이란 이 블록체인 장부를 간편하게 보고, 프라이빗 키를 저장해 두어 입출금을 하기 위한 도구이다. 즉 은행과 다르며 코인 매니저가 CM 지갑을 운영하지만, 사용자의 돈과 보유 코인 정보들은 코인 매니저 회사에 보관되는 것이 아닌 블록체인 네트워크에 저장되어 있고 CM 지갑은 이를 간편하게 관리할 수 있게 도와줄 뿐이다.[1]

활용

자바(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타입을 사용할 수 있다.[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] 가기.png 자바에 대해 자세히 보기

이그드라시

이그드라시(Yggdrash)
  • 알고리즘
키 알고리즘은 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바이트로 구성되며, 설정 파일에 지정된 디렉터리와 파일명으로 저장된다.
  • 암호화 구조
  • 클라이언트 키스토어 : 클라이언트에서 KDF는 스크립트, Encryption은aes-256-cbc를 기본으로 사용하며, PBKDF 2의 옵션을 제공한다. 노드와 차이점으로는 다음과 같다.
노드와 차이점
이름 클라이언트 노드
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"
 }
}

가기.png 이그드라시에 대해 자세히 보기

키스토어 생성및 삭제

키스토어 생성

계정에서 사용자 지정 키 스토어를 하나 또는 여러 개 생성할 수 있고, 각 사용자 지정 키 스토어는 동일한 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를 변경할 수 있지만, 지정한 클러스터는 원래 클러스터와 백업 기록을 공유해야 하며, 관련이 없는 클러스터를 사용하려면 사용자 지정 키 스토어를 새로 생성해야 한다.
  1. 클러스터는 활성 상태여야 한다. 클러스터를 생성해서 이를 초기화하고 플랫폼에 대한 AWS 클라우드HSM 클라이언트 소프트웨어를 설치한 다음, 클러스터를 활성화해야 한다.
  2. 클러스터가 AWS KMS 사용자 지정 키 스토어와 동일한 계정 및 리전에 있어야 하며, 한 리전에 있는 사용자 지정 키 스토어를 다른 리전의 클러스터와 연결할 수 없으며, 다중 리전 키 인프라를 생성하려면 각 리전에서 키 스토어와 클러스터를 생성해야 한다.
  3. 클러스터가 계정의 다른 사용자 지정 키 스토어에 연결될 수 없는데, 각각의 사용자 지정 키 스토어는 서로 다른 AWS 클라우드HSM 클러스터에 연결되어야 하고, 사용자 지정 키 스토어에 이미 연결된 클러스터나 연결 클러스터와 백업 기록을 공유하는 클러스터를 지정할 수 없다. 백업 기록을 공유하는 클러스터들은 동일한 클러스터 인증서를 가지고 있는데, 클러스터의 클러스터 인증서를 보려면 AWS 클라우드HSM 콘솔 또는 클러스터 설명 작업을 사용한다.
  4. 리전에서 서로 다른 가용 영역이 두 개 이상인 프라이빗 서브넷으로 클러스터를 구성해야 한다. AWS 클라우드HSM은 모든 가용 영역에서 지원되는 것이 아니어서 해당 리전의 모든 가용 영역에서 프라이빗 서브넷을 생성한다. 기존 클러스터에 대한 서브넷을 재구성할 수 없으며, 클러스터 구성에서 서브넷을 서로 달리하여 백업으로부터 클러스터를 생성할 수 있다.
  5. 클러스터용 보안 그룹(cloudhsm-cluster--sg)은 포트 2223~2225에서 TCP 트래픽을 허용하는 인바운드 규칙과 아웃바운드 규칙을 포함해야 하는데, 인바운드 규칙의 소스와 아웃바운드 규칙의 대상이 보안 그룹 ID와 일치해야 하며, 규칙은 클러스터를 생성할 때 기본적으로 설정에서 삭제하거나 변경하지 않는다.
  6. 클러스터는 서로 다른 가용 영역에 활성 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를 생성하는 절차는 다음과 같다.
  1. AWS 클라우드HSM 사용자 설명의 클라우드 HMS 관리유틸리티 실행 준비 섹션에 설명된 대로 클라우드 HMS 관리유틸리티를 시작한다.
  2. 클라우드 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)를 사용하지만, 사용자는 어떤 지원되는 프로그래밍 언어라도 사용할 수 있다. 키 스토어 사용자 정의 만들기 작업에서는 다음과 같은 파라미터 값이 필요하다.
  1. CustomKeyStoreName – 계정에서 고유한 기억하기 쉬운 사용자 지정 키 스토어의 이름이다.
  2. CloudHsmClusterId – 사용자 지정 키 스토어를 연결하기 위해 요구 사항을 충족하는 클러스터의 클러스터 ID이다.
  3. KeyStorePassword – 지정된 클러스터의 kms사용자 CU 계정 암호이다.
  4. 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. ↑ 1.0 1.1 〈키스토어가 무엇인가요?〉, 《미디엄》
  2. ↑ 2.0 2.1 2.2 lessTif 공식 홈페이지 - https://www.lesstif.com/pages/viewpage.action?pageId=20775436
  3. ↑ 이그드라시 공식 홈페이지 - https://www.notion.so/Key-store-f2a72659951940769756185be7f7aba9
  4. ↑ 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

참고자료

같이 보기


  검수요청.png검수요청.png 이 키스토어 문서는 블록체인 기술에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.  

블록체인 : 블록체인 기술 □■⊕, 합의 알고리즘, 암호 알고리즘, 알고리즘, 블록체인 플랫폼, 블록체인 솔루션, 블록체인 서비스
블록체인 기술 Bech32 • BTP • DRC-20 • EIP • IPFS • KRC-20 • NFT 마켓플레이스 • P2P • P2PKH • P2SH • PFP • PUF • SPV • TPS • TRC-20 • UTXO • 가나슈 • 가명성 • 가스 • 가십 • 가십 프로토콜 • 개념증명(PoC) • 검증가능지연함수(VDF) • 게스 • 고스트 프로토콜 • 공공예산 • 글로벌신뢰인공지능 • 대체가능토큰 • 대체불가토큰(NFT) • 도지더리움 브릿지 • 디지털 자산 • 디지털 희소성 • 라운드 • 라운드 로빈 • 라이트하우스 • 랜덤 • 레그테크 • 레이든 • 리카르디안 계약 • 린스타트업 • 마스터키 • 마스트 • 메인넷 • 멜팅 • 믹싱 • 민팅 • 밈블윔블 • 반감기 • 베타넷 • 변경불가성 • 브릿지 • 블록체인 생태계 • 블록체인 클라우드 서비스(BaaS) • 블룸필터 • 비블록체인 • 비앱 • 비콘체인 • 비트코인코어 • 빤통경제 • 수정 고스트 프로토콜 • 스냅샷 • 스마트 계약 • 스마트 브리지 • 스웜프로토콜 • 스크립트퍼브키 • 스테이킹 • 스텔스 주소 • 스핀오프코인 • 슬래싱 • 시크릿 컨트랙트 • 심플 컨트랙트 • 아토믹스왑 • 암호경제(크립토 이코노미) • 앤드어스체인인공지능 • 앵커링 • 언스테이킹 • 에어드랍 • 에폭 • 오프체인 오더락 • 오피리턴 • 옵코드 • 원토큰 문제 • 웨이 • 위스퍼 프로토콜 • 위임 • 유니스왑 • 유동성 • 이더리움 가상머신(EVM) • 이더리움 클라이언트 • 이중지불 • 익명성 • 인증된 익명 아이디 • 인터레저 프로토콜(ILP) • 자산화 • 잠금 스크립트 • 최소기능제품(MVP) • 컨소시엄 블록체인 • 컬러드코인 • 코인셔플 • 코인소각 • 코인에이지 • 코인조인 • 코인토싱 • 크립토노트 • 키스토어 • 타임락 • 테스트넷 • 토다 • 토큰 이코노미 • 토큰화 • 튜링완전 • 튜링불완전 • 트랜잭션 아이디(TxID) • 트러스트 컨트랙트 • 트루빗 • 트릴레마 • 파워 • 파티셔닝 • 퍼블릭 블록체인 • 페널티 • 프라이버시 • 프라이빗 블록체인 • 플랫폼 • 플러딩 • 피어 • 피투피(P2P) • 하이브리드 블록체인 • 합의 • 해시락 • 해시타임락(HTLC) • 해제 스크립트 • 확장성
해시 레인보우 테이블 • 매핑 • 머클경로 • 머클루트 • 머클트리 • 분산해시테이블(DHT) • 블록해시 • 스큐드 머클트리 • 온라인툴즈 • 이전블록해시 • 카뎀리아 • 해시 • 해시레이트 • 해시맵 • 해시충돌 • 해시테이블 • 해시파워 • 해시함수 • 해싱
블록 고아블록 • 그래핀 • 논스 • 마이크로블록 • 베이킹 • 북키퍼 • 브랜치블록 • 브로드캐스팅 • 블록 • 블록높이 • 블록바디 • 블록생성자 • 블록정보 • 블록타임 • 블록헤더 • 비츠 • 세그윗 • 엉클블록 • 완결성 • 제네시스블록 • 타임스탬프 • 프룻 • 프룻체인
체인 더블체인 • 라이트닝 네트워크 • 라이트닝 루프 • 루트체인 • 루프체인 • 메인체인 • 방향성 비순환 그래프(DAG) • 베리파이어블 프루닝 • 블록격자 • 블록체인 • 사용자 활성화 소프트포크(UASF) • 사용자 활성화 하드포크(UAHF) • 사이드체인 • 서브체인 • 소프트포크 • 오페라체인 • 오프체인 • 온체인 • 인터체인 • 차일드체인 • 체인 • 탱글 • 테스트체인 • 토카막 네트워크 • 포크 • 포크체인 • 퓨어체인 • 프로덕트체인 • 프루닝 • 프리포크 • 플라즈마 알고리즘 • 플라즈마캐시 • 플래시 계층 • 하드포크 • 해시그래프 • 홀로체인
노드 검증인(밸리데이터) • 기본노드 • 노드 • 라이트노드 • 랜덤노드 • 마스터노드 • 베이킹노드 • 보조노드 • 보증노드 • 슈퍼노드(슈퍼대표, 대표노드) • 슬롯 • 슬롯리더 • 엔드포인트노드(레인저노드) • 의회 네트워크 • 작업노드 • 종단노드 • 종자노드(시드노드) • 중계노드 • 지갑노드 • 채굴노드(마이닝노드) • 쿼럼 • 풀노드 • 합의노드
샤딩 네트워크 샤딩 • 데이터베이스 샤딩 • 동적샤딩 • 샤드 • 샤딩 • 스테이트 샤딩 • 알고리즘 샤딩 • 적응형 상태 샤딩 • 체인샤딩 • 트랜잭션 샤딩
채굴 병합채굴 • 사전채굴 • 에이식(ASIC) • 에이식부스트 • 에이식 저항 • 일드파밍 • 채굴 • 채굴 난이도 • 채굴량 • 탄소감축채굴 • 페어런치
탈중앙화 TVL • 거버넌스 • 게임파이 • 다오(DAO) • 다이코(DAICO) • 닥(DAC) • 닥스(DAX) • 덱스(DEX) • 디앱(DApp) • 디지오(DGO) • 디튜브 • 디파이(DeFi) • 분산경제 • 분산원장(DLT) • 분산 클라우드 • 소셜파이 • 씨파이(C-Fi) • 오프체인 거버넌스 • 온체인 거버넌스 • 원장 • 준중앙화 • 중앙화 • 탈중앙화 • 탈중앙화 TPS • 탈중앙화 조직(DO) • 탈중앙화 지수(DQ)
분산아이디 DIDs • IETF • ToIP • 검증가능한 자격증명 • 검증인 • 디지털아이덴티티재단 • 발급자 • 보유자 • 분산아이디(DID) • 분산아이디 기관 • 분산아이디 인증(DID Auth) • 아이온 • 자기주권 • 자기주권신원 • 최소화된 자격증명 데이터 • 탈중앙화 키관리시스템 • 통합해석기
오라클 상호인증 블록체인 • 오라클 • 오라클 머신 • 오라클 문제 • 오라클 서비스 • 중간자
BIP BIP • BIP9 • BIP16 • BIP32 • BIP39 • BIP43 • BIP44 • BIP47 • BIP49 • BIP63 • BIP70 • BIP84 • BIP141 • BIP148
ERC ERC • ERC-20 • ERC-165 • ERC-223 • ERC-621 • ERC-721 • ERC-777 • ERC-827 • ERC-884 • ERC-998 • ERC-1155 • ERC-1404
위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반
원본 주소 "http://wiki1.kr/index.php?title=키스토어&oldid=144680"