최신판 |
당신의 편집 |
5번째 줄: |
5번째 줄: |
| | | |
| BIP는 [[비트코인]]의 기술을 논의하기 위해 작성하거나 공개된 제안 양식이다. BIP32가 탄생하게 된 배경은 하나의 비트코인 주소보다 여러개의 비트코인 주소를 가지고 입출금을 하면 훨씬 더 안전하다는 것에서부터 출발하여 현재는 다양한 용도로 사용 가능하다. BIP32는 처음 [[HD 지갑]](Hierarchical Deterministic Wallet)에 대한 구조를 제안했는데, HD 지갑은 BIP32 문서를 코드로 [[프로그래밍]]화한 것을 말한다. HD 지갑은 결정적 계층 구조 지갑으로 2진 트리처럼, 또는 부모-자손 관계를 이용해 끝없이 파생시킬 수 있는 지갑으로 BIP32 이외에도 [[BIP39]], [[BIP44]] 등 여러 버전이 있으며 BIP39로 만들어진 프로그램은 [[이오스]](EOS)나 다른 [[블록체인]]에서도 흔히 사용된다.<ref> 공룡, 〈[https://blog.naver.com/forkblock/221559838087 HD Wallet]〉, 《네이버 블로그》, 2019-06-11 </ref> | | BIP는 [[비트코인]]의 기술을 논의하기 위해 작성하거나 공개된 제안 양식이다. BIP32가 탄생하게 된 배경은 하나의 비트코인 주소보다 여러개의 비트코인 주소를 가지고 입출금을 하면 훨씬 더 안전하다는 것에서부터 출발하여 현재는 다양한 용도로 사용 가능하다. BIP32는 처음 [[HD 지갑]](Hierarchical Deterministic Wallet)에 대한 구조를 제안했는데, HD 지갑은 BIP32 문서를 코드로 [[프로그래밍]]화한 것을 말한다. HD 지갑은 결정적 계층 구조 지갑으로 2진 트리처럼, 또는 부모-자손 관계를 이용해 끝없이 파생시킬 수 있는 지갑으로 BIP32 이외에도 [[BIP39]], [[BIP44]] 등 여러 버전이 있으며 BIP39로 만들어진 프로그램은 [[이오스]](EOS)나 다른 [[블록체인]]에서도 흔히 사용된다.<ref> 공룡, 〈[https://blog.naver.com/forkblock/221559838087 HD Wallet]〉, 《네이버 블로그》, 2019-06-11 </ref> |
| + | ==종류== |
| + | *[[BIP32]] |
| + | *[[BIP43]] |
| + | |
| ==등장배경== | | ==등장배경== |
− | [[비트코인]]을 받으려면 비트코인 주소가 필요하다. 이 주소로받은 비트코인을 보내려면 해당 개인 키가 필요하다. 따라서 비트 코 [[클라이언트]]는 적어도 하나의 비트 코 주소와 해당 개인 키가 유용해야합니다. 일반적으로, 비트 동전 지갑은 사용자가 여러 주소를 생성 할 수있게 한다. 복수의 주소를 사용하는 사용자는 하나의 주소만을 사용하는 사람보다 [[블록체인]]을 감시하는 것을 더 어렵게하기 때문에 익명성에 도움이 된다.
| + | 비트 코인을 받으려면 비트 코인 주소가 필요하다. 이 주소로받은 비트 코인을 보내려면 해당 개인 키가 필요하다. 따라서 비트 코 클라이언트는 적어도 하나의 비트 코 주소와 해당 개인 키가 유용해야합니다. 일반적으로, 비트 동전 지갑은 사용자가 여러 주소를 생성 할 수있게 한다. 복수의 주소를 사용하는 사용자는 하나의 주소만을 사용하는 사람보다 블록 체인을 감시하는 것을 더 어렵게하기 때문에 익명성에 도움이 된다. |
| 요청시 주소 / 개인 키를 생성하는 초기 아이디어는 사용자가 주소를 요청할 때마다 임의로 새로운 주소를 효과적으로 생성하는 것이 었다. 이것이 bitcoin-qt가하는 방식이다. 이 방법의 단점 중 하나는 지갑이 모든 주소 / 키를 저장해야한다는 것이다. 따라서 사용자는 새로 생성 된 주소 / 키가 손실되지 않도록하기 위해 새 주소를 생성 할 때마다 지갑을 백업해야한다. | | 요청시 주소 / 개인 키를 생성하는 초기 아이디어는 사용자가 주소를 요청할 때마다 임의로 새로운 주소를 효과적으로 생성하는 것이 었다. 이것이 bitcoin-qt가하는 방식이다. 이 방법의 단점 중 하나는 지갑이 모든 주소 / 키를 저장해야한다는 것이다. 따라서 사용자는 새로 생성 된 주소 / 키가 손실되지 않도록하기 위해 새 주소를 생성 할 때마다 지갑을 백업해야한다. |
− | BIP32 지갑은 사용자가 필요에 따라 새로운 주소를 생성 할 수 있지만 주소 / 키를 반복해서 백업 할 필요가 없다. 마술은 두 번째 주소 / 키가 무작위가 아니라 실제로 첫 번째 것의 파생물이고, 세 번째 것은 두 번째 파생 된 것이다. 이 모든 것은 아무도 그 주소에서 어떤 주소도 추측 할 수 없도록하기 위해 일부 암호화에 의해 뒷받침 이된다. 첫 번째 개인 키가 없어도 지갑을 사용할 수 있다. | + | BIP32 지갑은 사용자가 필요에 따라 새로운 주소를 생성 할 수 있지만 주소 / 키를 반복해서 백업 할 필요가 없다. 마술은 두 번째 주소 / 키가 무작위가 아니라 실제로 첫 번째 것의 파생물이고, 세 번째 것은 두 번째 파생 된 것입니다. 이 모든 것은 아무도 그 주소에서 어떤 주소도 추측 할 수 없도록하기 위해 일부 암호화에 의해 뒷받침 됩니다. 첫 번째 개인 키가 없어도 지갑을 사용할 수 있습니다. |
− | | |
− | ==기본구조==
| |
− | [[비트코인]] 참조 [[클라이언트]]는 임의로 생성 된 키를 사용한다. 매 [[트랜잭션]]마다 백업이 필요하지 않도록 (기본적으로) 100 개의 키가 예약 키 풀에 캐시된다. 하지만이 지갑은 여러 시스템에서 동시에 공유하고 사용할 수 없다. 그들은 지갑 암호화 기능을 사용하고 비밀 번호를 공유하지 않음으로써 개인 키를 숨기도록 지원하지만 그러한 "중성화 된"지갑은 공개 키를 생성 할 수있는 능력을 잃어 버린다.
| |
− | 결정 론적 지갑은 빈번한 백업을 필요로하지 않으며, 타원 곡선 수학은 개인 키를 공개하지 않고 공개 키를 계산할 수있는 스키마를 허용한다. 이것은 예를 들어 webshop 비즈니스가 웹 서버가 (수신 된 자금을 소비하는 데 필요한) 해당 개인 키에 대한 액세스를 제공하지 않고 웹 서버가 각 주문 또는 각 고객에 대해 새로운 주소 (공개 키 해시)를 생성하도록 허용한다.
| |
− | 그러나 결정 론적 지갑은 일반적으로 키 쌍의 단일 "체인"으로 구성된다. 단 하나의 체인이 있다는 사실은 지갑을 공유하는 것이 모두 또는 전혀 기초가 없다는 것을 의미한다. 그러나 경우에 따라 일부 공개 키만 공유하고 복구 할 수 있기를 원한다. 웹샵의 예에서 웹 서버는 판매자의 지갑의 모든 공개 키에 액세스 할 필요가 없다. 예를 들어 판매자가 돈을 지불 할 때 생성되는 변경 주소가 아닌 고객의 지불을받는 데 사용되는 주소에만 적용된다. 계층 적 결정 론적 지갑은 단일 루트에서 파생 된 여러 개의 키 쌍 체인을 지원함으로써 이러한 선택적 공유를 허용한다.
| |
− | | |
− | ==협약==
| |
− | 이 텍스트의 나머지 부분에서는 [[비트코인]]에서 사용되는 공개 키 [[암호화]], 즉 secp256k1 ( http://www.secg.org/sec2-v2.pdf )에서 정의한 필드 및 곡선 매개 변수를 사용하는 타원 곡선 암호화를 가정한다. 아래 변수는 다음 중 하나이다.
| |
− | | |
− | *곡선의 차수를 n으로 나타내는 정수이다.
| |
− | *커브상의 점의 좌표이다.
| |
− | *바이트 시퀀스.
| |
− | 두 좌표 쌍의 더하기 (+)는 EC 그룹 연산의 적용으로 정의됩니다. 연결 (||)은 1 바이트 시퀀스를 다른 시퀀스에 추가하는 작업이다.
| |
− | 표준 변환 함수로 다음과 같이 가정한다.
| |
− | | |
− | *point (p) : secp256k1 기준점의 EC 포인트 곱셈 (EC 그룹 연산의 반복 적용)에서 나온 좌표 쌍을 정수 p로 반환한다.
| |
− | *ser 32 (i) : 32 비트 부호없는 정수 i를 4 바이트 시퀀스로 최상위 바이트 먼저 serialize한다.
| |
− | *ser 256 (p) : 정수 p를 32 바이트 시퀀스로 최상위 바이트 먼저 serialize한다.
| |
− | *ser P (P) : SEC1의 압축 형식 (0x02 또는 0x03)을 사용하여 좌표 쌍 P = (x, y)를 바이트 시퀀스로 직렬화한다. ser 256 (x). 여기서 헤더 바이트는 생략 된 y 좌표의 패리티에 따라 다르다.
| |
− | *256 (p) 파싱 : 32 비트 시퀀스를 최상위 바이트 인 256 비트 숫자로 먼저 해석한다.
| |
− | | |
− | ==확장키==
| |
− | 다음에서는 상위 키에서 여러 하위 키를 유도하는 함수를 정의한다. 이것들이 키 자체에만 의존하는 것을 막기 위해서 우리는 우선 256 비트의 엔트로피로 개인 키와 공개 키를 확장한다. 체인 코드라고하는이 확장은 해당 개인 키와 공개 키에서 동일하며 32 바이트로 구성된다.
| |
− | 우리는 확장 개인 키를 (k, c)로 표현하고, k는 일반 개인 키를, c는 체인 코드를 나타낸다. 확장 공개 키는 (K, c), K = 포인트 (k) 및 체인 코드로 표현된다.
| |
− | 각 확장 키에는 2 31 개의 일반 자식 키와 2 31 개의 강화 된 자식 키가 있다. 이러한 각 하위 키에는 색인이 있다. 통상의 아이 키는 0 ~ 2 31 -1의 인덱스를 사용 한다.
| |
− | 강화 된 자식 키는 인덱스 2 31 에서 2 32 -1을 사용한다. 강화 된 키 인덱스에 대한 표기법을 쉽게하기 위해 숫자 i H 는 i + 2 31을 나타낸다 .
| |
− | | |
− | ==하위 키 유도 (CKD) 함수==
| |
− | 부모 확장 키 및 인덱스 i가 주어지면, 대응하는 자식 확장 키를 계산하는 것이 가능하다. 이렇게하는 [[알고리즘]]은 아동이 강화 된 키인지 아닌지 (또는 i ≧ 2 31 인지 여부)와 개인 키 또는 공개 키에 대해 이야기하는지 여부에 따라 다르다 .
| |
− | | |
− | 개인 부모 키 → 개인 자식 키
| |
− | 함수 CKDpriv ((k par , c par ), i) → (k i , c i )는 부모 확장 개인 키에서 자식 확장 개인 키를 계산한다 :
| |
− | | |
− | *i ≥ 2 31 (아이가 강화 된 키인지 여부)를 확인해라.
| |
− | 그렇다면 : HMAC-SHA512 (Key = c par , Data = 0x00 || ser 256 (k par ) || ser 32 (i)) 라고한다면 . (참고 : 0x00은 33 바이트 길이가되도록 개인 키를 채 웁니다.)
| |
− | 그렇지 않다면 (HMAC-SHA512) (Key = c par , Data = ser P (point (k par )) || ser 32 (i)).
| |
− | *I를 두 개의 32 바이트 시퀀스, I L 과 I R 로 분할 합다.
| |
− | *반환 된 자식 키 (K)의 난 파싱 인 256 (I의 L ) + (K)의 액면 (mod n)을 계산한다.
| |
− | *반환 된 체인 코드 c i 는 I R 이다.
| |
− | *구문 256 (I L ) ≥ n 또는 k i = 0 인 경우 결과 키는 유효하지 않으며 i는 다음 값으로 진행해야한다. (참고 : 2 127의 확률은 1보다 낮습니다 .)
| |
− | HMAC-SHA512 기능은 RFC 4231에 명시되어 있다.
| |
− | 공용 상위 키 → 공용 하위 키
| |
− | 함수 CKDpub ((K의 파 는 C 파가 ), 나) → (K는 난 , C, I ) 아이 공개 키 확장 부모로부터 공개 키를 확장 연산한다. non-hardened 자식 키에 대해서만 정의된다.
| |
− | | |
− | *i ≥ 2 31 (아이가 강화 된 키인지 여부)를 확인.
| |
− | *그렇다면 (단단한 자식) : 반환 실패
| |
− | *그렇지 않다면 (정상 아동) : HMAC-SHA512 (Key = c par , Data = ser P (K par ) || ser 32 (i)) 라고한다면 .
| |
− | I를 두 개의 32 바이트 시퀀스, I L 과 I R 로 분할 한다.
| |
− | *반환 된 자식 키 K가 나는 지점 (파싱 인 256 (I의 L을 )) + K의 파 .
| |
− | *반환 된 체인 코드 c i 는 I R 이다.
| |
− | *파싱 256 (I L ) ≥ n 또는 K i 가 무한대의 점인 경우 결과 키는 유효하지 않으며 i는 다음 값으로 진행해야한다.
| |
− | 개인 부모 키 → 공개 자식 키
| |
− | 함수 N ((k, c)) → (K, c)는 확장 된 개인 키에 상응하는 확장 공개 키를 계산한다.
| |
− | ( "중립"버전은 트랜잭션 서명 기능을 제거한다.).
| |
− | | |
− | *반환 된 키 K는 point (k)이다.
| |
− | *반환 된 체인 코드 c는 전달 된 체인 코드이다.
| |
− | 상위 개인 키의 공용 하위 키를 계산하려면 다음을 수행.
| |
− | *N (CKDpriv ((k par , c par ), i)) (항상 작동 함).
| |
− | *CKDpub (N (k par , c par ), i) (강화되지 않은 자식 키에서만 작동).
| |
− | 키가 동일하다는 사실은 강화되지 않은 키를 유용하게 만드는 것이다 (개인 키를 모르는 상태에서 지정된 부모 키의 자식 공개 키를 파생시킬 수 있음). 또한 강화 된 키와 구별되는 점도 있다. 보안이 강화되지 않은 키 (더 유용함)를 항상 사용하지 않는 이유는 보안이다. 자세한 내용은 추가 정보를 참조하십시오.
| |
− | 공개 부모 키 → 개인 자식 키
| |
− | 불가능하다.
| |
− | | |
− | ==키트리==
| |
− | 다음 단계는 여러 개의 CKD 구성을 계단식으로 배열하여 나무를 만드는 것이다. 우리는 하나의 루트, 마스터 확장 키로 시작합니다. i의 여러 값에 대해 CKDpriv (m, i)를 평가하면 레벨 1 파생 노드 수를 얻을 수 있다. 이들 각각은 다시 확장 키이므로 CKDpriv도 해당 키에 적용 할 수 있다.
| |
− | | |
− | 표기법을 줄이기 위해 우리는 CKDpriv (CKDpriv (CKDpriv (m, 3 H ), 2), 5)를 m / 3 H / 2 / 5로 쓴다 . 공개 키와 마찬가지로 CKDpub (CKDpub (CKDpub (M, 3), 2), 5)를 M / 3 / 2 / 5로 쓴니다. 결과적으로 다음과 같은 ID가 생성된다.
| |
− | | |
− | *(m / a) / b / c = N (m) / a / b / c = M / a / b / c = N (m / 기음.
| |
− | *N (m / aH / b / c) = N (m / aH / b) / c = N (m / aH ) / b / c.
| |
− | 그러나 N (m / a H )은 N (m) / a H 로 다시 쓸 수 없습니다 . 왜냐하면 후자가 불가능하기 때문이다.
| |
− | 트리의 각 리프 노드는 실제 키에 해당하는 반면 내부 노드는 키의 컬렉션에 해당한다. 잎 노드의 체인 코드는 무시되며 내장 된 개인 키나 공개 키만 관련된다. 이 구성으로 인해 확장 개인 키를 알고 있으면 모든 자손 개인 키와 공개 키를 재구성 할 수 있고 확장 공개 키를 알고 있으면 모든 하위 키가 아닌 공개 키를 재구성 할 수 있다.
| |
− | | |
− | ==키 식별자==
| |
− | 확장 된 키는 체인 코드를 무시하고 직렬화 된 ECDSA 공개 키 K의 Hash160 (SHA256 이후의 RIPEMD160)으로 식별 할 수 있다. 이것은 전통적인 Bitcoin 주소에서 사용되는 데이터와 정확하게 일치한다.
| |
− | 이 데이터를 base58 형식으로 표현하는 것은 권장하지 않는다. 이는 주소 방식으로 해석 될 수 있으므로 (지갑 소프트웨어 자체가 체인 키에 대한 지불을 수락하지 않아도되기 때문이다).
| |
− | 식별자의 처음 32 비트는 키 지문이라고 한다.
| |
− | | |
− | ==직렬화 형식==
| |
− | 확장 공개 키와 비공개 키는, 다음과 같이 직렬화된다.
| |
− | | |
− | *4 바이트 : 버전 바이트 (mainnet : 0x0488B21E public, 0x0488ADE4 private, testnet : 0x043587CF public, 0x04358394 private)
| |
− | *1 바이트 : 깊이 : 마스터 노드의 경우 0x00, 레벨 1 파생 키의 경우 0x01 ...
| |
− | *4 바이트 : 부모 키의 지문 (마스터 키인 경우 0x00000000)
| |
− | *4 바이트 : 자식 번호. 이것은 x 32 i (i) x i = x par / i이고 x i 는 키가 직렬화 된 것입니다. (마스터 키인 경우 0x00000000)
| |
− | *32 바이트 : 체인 코드
| |
− | *33 바이트 : 공개 키 또는 개인 키 데이터 (공개 키의 경우 ser P (K), 개인 키의 경우 0x00 || ser 256 (k))
| |
− | 이 78 바이트 구조는 처음에 32 개의 체크섬 비트 (이중 SHA-256 체크섬에서 파생 됨)를 추가 한 다음 Base58 표현으로 변환하여 Base58의 다른 Bitcoin 데이터와 같이 인코딩 할 수 있다. . 그 결과 Base58로 인코딩 된 최대 112 자의 문자열이 생성된다. . 버전 바이트를 선택했기 때문에 Basenet은 testnet의 메인 트루넷 "xprv"또는 "xpub", "tprv"또는 "tpub"로 시작한다.
| |
− | 부모의 지문은 소프트웨어에서 부모 노드와 자식 노드를 빠르게 탐지하는 역할을하며 소프트웨어는 충돌을 처리해야 한다. 내부적으로 전체 160 비트 식별자를 사용할 수 있다.
| |
− | 직렬화 된 확장 공개 키를 임포트 할 때, 구현은 공개 키 데이터의 X 좌표가 곡선상의 한 점과 일치하는지 여부를 검증해야 한다. 그렇지 않은 경우 확장 공개 키가 유효하지 않는다.
| |
− | | |
− | ==마스터 키 생성==
| |
− | 가능한 확장 된 키 쌍의 총 수는 거의 2 512 이지만 생성 된 키의 길이는 256 비트에 불과하며 보안 측면에서 약 절반을 제공합니다. 따라서 마스터 키는 직접 생성되지 않고 잠재적으로 짧은 시드 값에서 생성된다.
| |
− | | |
− | *(P) RNG에서 선택된 길이의 시드 바이트 시퀀스 S (128 비트와 512 비트 사이, 256 비트가 권고 됨)를 생성한다.
| |
− | *I = HMAC-SHA512 (Key = "Bitcoin seed", Data = S)를 계산한다.
| |
− | *I를 두 개의 32 바이트 시퀀스, I L 과 I R 로 분할 한다.
| |
− | *파싱 사용하여 256 (I의 L을 마스터로 비밀 키), 및 I는 R 마스터 체인 코드로.
| |
− | I L 이 0 또는 ≥ n 인 경우 마스터 키가 유효하지 않는다.
| |
− | | |
− | ==사양 : 지갑 구조==
| |
− | 이전 섹션에서는 키 트리와 노드를 지정했다. 다음 단계는이 트리에 지갑 구조를 적용하는 것이다. 이 섹션에서 정의 된 레이아웃은 기본값이지만 모든 기능이 지원되지는 않더라도 호환성을 위해 클라이언트를 모방하는 것이 좋다.
| |
− | | |
− | ==기본 지갑 레이아웃==
| |
− | HDW는 여러 '계정'으로 구성됩니다. 계정에 번호가 매겨지며, 기본 계정 ( "")은 숫자 0입니다. 클라이언트는 둘 이상의 계정을 지원할 필요가 없습니다. 그렇지 않은 경우 클라이언트는 기본 계정 만 사용한다.
| |
− | | |
− | 각 계정은 내부 및 외부 키 쌍으로 구성된 두 개의 키 쌍 체인으로 구성된다. 외부 키 체인은 새로운 공용 주소를 생성하는 데 사용되지만 내부 키 체인은 다른 모든 작업 (주소 변경, 생성 주소 변경, 통신 할 필요가없는 모든 작업)에 사용된다. 이들을위한 별도의 키 체인을 지원하지 않는 클라이언트는 모든 것을 위해 외부 키 체인을 사용해야한다.
| |
− | | |
− | m / i H / 0 / k는 마스터 m에서 파생 된 HDW의 계정 번호 i의 외부 체인의 k 번째 키 쌍에 해당한다.
| |
− | m / i H / 1 / k는 마스터 m에서 파생 된 HDW의 계정 번호 i의 내부 체인의 k 번째 키 쌍에 해당한다.
| |
− | | |
− | ==사용 사례==
| |
− | ===전체 지갑 공유 : m===
| |
− | 두 시스템이 하나의 공유 지갑(Wallet)에 액세스해야하고 둘 다 지출을 수행 할 수 있어야하는 경우 마스터 개인 확장 키를 공유해야 한다. [[노드]]는 외부 체인을 위해 캐시 된 N 개의 미리보기 키 풀을 수신 지불을 감시 할 수 있다. 여기서 내부 쇠사슬에 대한 사전 검색은 매우 작을 수 있다. 첫 번째 사용되지 않는 계정의 체인에 대해 추가 미리보기가 활성화되어 사용할 때 새 계정을 만들 수 있다. 계정 이름은 수동으로 입력해야하며 블록 체인을 통해 동기화 할 수 없다.
| |
− | | |
− | ===감사 : N (m / *)===
| |
− | 감사인이 입출금 목록에 대한 완전한 액세스를 필요로하는 경우 모든 계정 공개 확장 키를 공유 할 수 있다. 그러면 감사인은 모든 계좌에서 지갑과의 모든 거래를 볼 수 있지만 단일 비밀 키는 볼 수 없다.
| |
− | | |
− | ===사무실 단위 잔액 : m / i H===
| |
− | 기업이 여러 개의 독립 사무소를 운영하는 경우 단일 마스터에서 파생 된 지갑을 모두 사용할 수 있다. 이를 통해 본사는 모든 사무실의 모든 송수신 거래를 볼 수있는 수퍼 지갑을 유지할 수있을뿐 아니라 사무실간에 돈을 이동할 수도 있다.
| |
− | | |
− | ===반복되는 B2B 트랜잭션 : N (m / i H / 0)===
| |
− | 두 비즈니스 파트너가 돈을 송금하는 경우, 특정 계정 (M / ih / 0)의 외부 체인에 대한 확장 공개 키를 일종의 "수퍼 주소"로 사용하여 (쉽게) 연관시킬 수없는 빈번한 트랜잭션을 허용 할 수 있다. 각 지불에 대해 새 주소를 요청할 필요는 없다. 이러한 메커니즘은 풀 지불 운영자가 다양한 지불금 주소로 사용할 수도 있다.
| |
− | | |
− | ===무보수 머니 리시버 : N (m / i H / 0)===
| |
− | 안전하지 않은 [[웹 서버]]를 사용하여 전자 상거래 사이트를 운영하는 경우 지불을받는 데 사용되는 공개 주소를 알아야 한다. 웹 서버는 단일 계정의 외부 체인의 공개 확장 키 만 알아야 한다. 즉, 불법적으로 웹 서버에 대한 액세스 권한을 얻는 사람은 대부분 모든 입금을 볼 수 있지만 돈을 훔칠 수는 없으며 나가는 트랜잭션을 구별 할 수 없으며 다른 웹 서버가받은 지불을 볼 수도 없다.
| |
− | | |
− | ==적합성==
| |
− | 이 표준을 준수하기 위해 클라이언트는 최소한 직접 공개 키 또는 개인 키를 가져 와서 직계 하위 항목에 지갑 키로 액세스 할 수 있어야 한다. 사양의 두 번째 부분에 제시된 지갑 구조 (마스터 / 계정 / 체인 / 하위 체인)는 권고 사항 일 뿐이므로 내부 또는 외부 체인을 별도로 지정하거나 구별하지 않아도 쉽게 호환 할 수 있도록 최소한의 구조로 제안된다. 그러나 특정 요구 사항에 따라 구현이 다를 수 있다. 더 복잡한 응용 프로그램은 더 복잡한 트리 구조를 요구할 수 있다.
| |
− | | |
− | ==보안==
| |
− | EC 공개 키 암호화 자체의 기대에 더하여 :
| |
− | | |
− | *공개 키 K가 주어지면 공격자는 EC 이산 대수 문제 (2 128 개 그룹 작업이 필요한 것으로 가정)보다 더 효율적으로 해당 개인 키를 찾을 수 없다 .
| |
− | 이 표준의 의도 된 보안 속성은 다음과 같다.
| |
− | *자식 확장 개인 키 (k i , c i )와 정수 i가 주어지면 공격자는 HMAC-SHA512의 2 256 무차별 공격 보다 부모 개인 키 k par를 더 효율적으로 찾을 수 없다 .
| |
− | *임의의 수 (2 ≤ 2 ≤ N 주어 32 (개인 키 확장 지수) 튜플 (I의 -1)을 J (k 값 I의 J , C, I , J 별개의 I를 포함)), J 의, 그들로부터 유도되는지 여부를 판단 공통 부모는 (k 값이 존재하는지 여부, 즉, 개인 키 (확장 파 는 C 파 (0..N-1) CKDpriv ((k 개의 각 J 용되도록) 파 , C의 파 ) 내가 J ) = ((k)를 i j , c i j )) 는 HMAC-SHA512의 2 256 무차별 대항력 보다 더 효율적으로 수행 될 수 없다 .
| |
− | 그러나 다음 속성은 존재하지 않는다.
| |
− | *부모 확장 공개 키 (K par , c par ) 및 자식 공개 키 (K i )가 주어지면, i 를 찾기가 어렵다.
| |
− | *부모 확장 공개 키 (K par , c par ) 및 강화되지 않은 자식 개인 키 (k i )가 주어지면, k par 를 찾기가 어렵다 .
| |
− | | |
− | ==시사점==
| |
− | 개인 키와 공개 키는 평소처럼 안전하게 보관해야한다. 개인 키 누출은 동전에 대한 액세스를 의미한다. 공개 키를 유출하면 개인 정보가 손실 될 수 있다.
| |
− | | |
− | 확장 된 키는 키의 전체 (하위) 트리에 해당하기 때문에 다소주의를 기울여야한다.
| |
− | | |
− | 즉각적으로 밝혀지지 않을 수있는 약점 중 하나는 상위 확장 공개 키와 하위 확장 비공개 키에 대한 지식이 상위 확장 개인 키 (즉, 하위 개인 키와 공개 키 모두)를 아는 것과 동일하다는 것이다. 이것은 확장 공개 키가 일반 공개 키보다 더 신중하게 다루어 져야 함을 의미한다. 강화 된 키가 존재하는 이유이기도하며 트리에서 계정 수준으로 사용되는 이유이기도 하다. 이렇게하면 계정 고유의 (또는 아래) 개인 키 누출이 마스터 또는 다른 계정을 손상시키지 않는다.
| |
− | | |
− | <ref>
| |
− | maguayo, 〈[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation BIP32]〉, 《깃허브》</ref>
| |
| {{각주}} | | {{각주}} |
| | | |
165번째 줄: |
18번째 줄: |
| * 공룡, 〈[https://blog.naver.com/forkblock/221559838087 HD Wallet]〉, 《네이버 블로그》, 2019-06-11 | | * 공룡, 〈[https://blog.naver.com/forkblock/221559838087 HD Wallet]〉, 《네이버 블로그》, 2019-06-11 |
| * 추천도서천권읽기, 〈[https://blog.naver.com/sd96210/221058971588 블록체인의 충격]〉, 《네이버 블로그》, 2017-07-25 | | * 추천도서천권읽기, 〈[https://blog.naver.com/sd96210/221058971588 블록체인의 충격]〉, 《네이버 블로그》, 2017-07-25 |
− | *maguayo, 〈[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation BIP32]〉, 2018-10-26《깃허브》
| |
| | | |
| == 같이 보기 == | | == 같이 보기 == |
| * [[BIP]] | | * [[BIP]] |
| | | |
− | {{블록체인 기술|검토 필요}} | + | {{블록체인 기술|토막글}} |