BIP32 편집하기
최신판 | 당신의 편집 | ||
6번째 줄: | 6번째 줄: | ||
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> | ||
==등장배경== | ==등장배경== | ||
− | + | 비트 코인을 받으려면 비트 코인 주소가 필요하다. 이 주소로받은 비트 코인을 보내려면 해당 개인 키가 필요하다. 따라서 비트 코 클라이언트는 적어도 하나의 비트 코 주소와 해당 개인 키가 유용해야합니다. 일반적으로, 비트 동전 지갑은 사용자가 여러 주소를 생성 할 수있게 한다. 복수의 주소를 사용하는 사용자는 하나의 주소만을 사용하는 사람보다 블록 체인을 감시하는 것을 더 어렵게하기 때문에 익명성에 도움이 된다. | |
요청시 주소 / 개인 키를 생성하는 초기 아이디어는 사용자가 주소를 요청할 때마다 임의로 새로운 주소를 효과적으로 생성하는 것이 었다. 이것이 bitcoin-qt가하는 방식이다. 이 방법의 단점 중 하나는 지갑이 모든 주소 / 키를 저장해야한다는 것이다. 따라서 사용자는 새로 생성 된 주소 / 키가 손실되지 않도록하기 위해 새 주소를 생성 할 때마다 지갑을 백업해야한다. | 요청시 주소 / 개인 키를 생성하는 초기 아이디어는 사용자가 주소를 요청할 때마다 임의로 새로운 주소를 효과적으로 생성하는 것이 었다. 이것이 bitcoin-qt가하는 방식이다. 이 방법의 단점 중 하나는 지갑이 모든 주소 / 키를 저장해야한다는 것이다. 따라서 사용자는 새로 생성 된 주소 / 키가 손실되지 않도록하기 위해 새 주소를 생성 할 때마다 지갑을 백업해야한다. | ||
BIP32 지갑은 사용자가 필요에 따라 새로운 주소를 생성 할 수 있지만 주소 / 키를 반복해서 백업 할 필요가 없다. 마술은 두 번째 주소 / 키가 무작위가 아니라 실제로 첫 번째 것의 파생물이고, 세 번째 것은 두 번째 파생 된 것이다. 이 모든 것은 아무도 그 주소에서 어떤 주소도 추측 할 수 없도록하기 위해 일부 암호화에 의해 뒷받침 이된다. 첫 번째 개인 키가 없어도 지갑을 사용할 수 있다. | BIP32 지갑은 사용자가 필요에 따라 새로운 주소를 생성 할 수 있지만 주소 / 키를 반복해서 백업 할 필요가 없다. 마술은 두 번째 주소 / 키가 무작위가 아니라 실제로 첫 번째 것의 파생물이고, 세 번째 것은 두 번째 파생 된 것이다. 이 모든 것은 아무도 그 주소에서 어떤 주소도 추측 할 수 없도록하기 위해 일부 암호화에 의해 뒷받침 이된다. 첫 번째 개인 키가 없어도 지갑을 사용할 수 있다. | ||
+ | ==종류== | ||
+ | *[[BIP32]] | ||
+ | *[[BIP39]] | ||
+ | *[[BIP43]] | ||
+ | *[[BIP44]] | ||
==기본구조== | ==기본구조== | ||
− | + | Bitcoin 참조 클라이언트는 임의로 생성 된 키를 사용한다. 매 트랜잭션마다 백업이 필요하지 않도록 (기본적으로) 100 개의 키가 예약 키 풀에 캐시된다. 하지만이 지갑은 여러 시스템에서 동시에 공유하고 사용할 수 없다. 그들은 지갑 암호화 기능을 사용하고 비밀 번호를 공유하지 않음으로써 개인 키를 숨기도록 지원하지만 그러한 "중성화 된"지갑은 공개 키를 생성 할 수있는 능력을 잃어 버린다. | |
결정 론적 지갑은 빈번한 백업을 필요로하지 않으며, 타원 곡선 수학은 개인 키를 공개하지 않고 공개 키를 계산할 수있는 스키마를 허용한다. 이것은 예를 들어 webshop 비즈니스가 웹 서버가 (수신 된 자금을 소비하는 데 필요한) 해당 개인 키에 대한 액세스를 제공하지 않고 웹 서버가 각 주문 또는 각 고객에 대해 새로운 주소 (공개 키 해시)를 생성하도록 허용한다. | 결정 론적 지갑은 빈번한 백업을 필요로하지 않으며, 타원 곡선 수학은 개인 키를 공개하지 않고 공개 키를 계산할 수있는 스키마를 허용한다. 이것은 예를 들어 webshop 비즈니스가 웹 서버가 (수신 된 자금을 소비하는 데 필요한) 해당 개인 키에 대한 액세스를 제공하지 않고 웹 서버가 각 주문 또는 각 고객에 대해 새로운 주소 (공개 키 해시)를 생성하도록 허용한다. | ||
그러나 결정 론적 지갑은 일반적으로 키 쌍의 단일 "체인"으로 구성된다. 단 하나의 체인이 있다는 사실은 지갑을 공유하는 것이 모두 또는 전혀 기초가 없다는 것을 의미한다. 그러나 경우에 따라 일부 공개 키만 공유하고 복구 할 수 있기를 원한다. 웹샵의 예에서 웹 서버는 판매자의 지갑의 모든 공개 키에 액세스 할 필요가 없다. 예를 들어 판매자가 돈을 지불 할 때 생성되는 변경 주소가 아닌 고객의 지불을받는 데 사용되는 주소에만 적용된다. 계층 적 결정 론적 지갑은 단일 루트에서 파생 된 여러 개의 키 쌍 체인을 지원함으로써 이러한 선택적 공유를 허용한다. | 그러나 결정 론적 지갑은 일반적으로 키 쌍의 단일 "체인"으로 구성된다. 단 하나의 체인이 있다는 사실은 지갑을 공유하는 것이 모두 또는 전혀 기초가 없다는 것을 의미한다. 그러나 경우에 따라 일부 공개 키만 공유하고 복구 할 수 있기를 원한다. 웹샵의 예에서 웹 서버는 판매자의 지갑의 모든 공개 키에 액세스 할 필요가 없다. 예를 들어 판매자가 돈을 지불 할 때 생성되는 변경 주소가 아닌 고객의 지불을받는 데 사용되는 주소에만 적용된다. 계층 적 결정 론적 지갑은 단일 루트에서 파생 된 여러 개의 키 쌍 체인을 지원함으로써 이러한 선택적 공유를 허용한다. | ||
==협약== | ==협약== | ||
− | 이 텍스트의 나머지 부분에서는 | + | 이 텍스트의 나머지 부분에서는 Bitcoin에서 사용되는 공개 키 암호화, 즉 secp256k1 ( http://www.secg.org/sec2-v2.pdf )에서 정의한 필드 및 곡선 매개 변수를 사용하는 타원 곡선 암호화를 가정한다. 아래 변수는 다음 중 하나이다. |
*곡선의 차수를 n으로 나타내는 정수이다. | *곡선의 차수를 n으로 나타내는 정수이다. | ||
37번째 줄: | 42번째 줄: | ||
==하위 키 유도 (CKD) 함수== | ==하위 키 유도 (CKD) 함수== | ||
− | 부모 확장 키 및 인덱스 i가 주어지면, 대응하는 자식 확장 키를 계산하는 것이 가능하다. 이렇게하는 | + | 부모 확장 키 및 인덱스 i가 주어지면, 대응하는 자식 확장 키를 계산하는 것이 가능하다. 이렇게하는 알고리즘은 아동이 강화 된 키인지 아닌지 (또는 i ≧ 2 31 인지 여부)와 개인 키 또는 공개 키에 대해 이야기하는지 여부에 따라 다르다 . |
개인 부모 키 → 개인 자식 키 | 개인 부모 키 → 개인 자식 키 | ||
111번째 줄: | 116번째 줄: | ||
==사양 : 지갑 구조== | ==사양 : 지갑 구조== | ||
− | 이전 섹션에서는 키 트리와 노드를 | + | 이전 섹션에서는 키 트리와 노드를 지정했습니다. 다음 단계는이 트리에 지갑 구조를 적용하는 것입니다. 이 섹션에서 정의 된 레이아웃은 기본값이지만 모든 기능이 지원되지는 않더라도 호환성을 위해 클라이언트를 모방하는 것이 좋습니다. |
− | |||
==기본 지갑 레이아웃== | ==기본 지갑 레이아웃== | ||
− | HDW는 여러 '계정'으로 구성됩니다. 계정에 번호가 매겨지며, 기본 계정 ( "")은 숫자 0입니다. 클라이언트는 둘 이상의 계정을 지원할 필요가 없습니다. 그렇지 않은 경우 클라이언트는 기본 계정 만 | + | HDW는 여러 '계정'으로 구성됩니다. 계정에 번호가 매겨지며, 기본 계정 ( "")은 숫자 0입니다. 클라이언트는 둘 이상의 계정을 지원할 필요가 없습니다. 그렇지 않은 경우 클라이언트는 기본 계정 만 사용합니다. |
− | 각 계정은 내부 및 외부 키 쌍으로 구성된 두 개의 키 쌍 체인으로 | + | 각 계정은 내부 및 외부 키 쌍으로 구성된 두 개의 키 쌍 체인으로 구성됩니다. 외부 키 체인은 새로운 공용 주소를 생성하는 데 사용되지만 내부 키 체인은 다른 모든 작업 (주소 변경, 생성 주소 변경, 통신 할 필요가없는 모든 작업)에 사용됩니다. 이들을위한 별도의 키 체인을 지원하지 않는 클라이언트는 모든 것을 위해 외부 키 체인을 사용해야합니다. |
− | |||
− | |||
− | |||
+ | m / i H / 0 / k는 마스터 m에서 파생 된 HDW의 계정 번호 i의 외부 체인의 k 번째 키 쌍에 해당합니다. | ||
+ | m / i H / 1 / k는 마스터 m에서 파생 된 HDW의 계정 번호 i의 내부 체인의 k 번째 키 쌍에 해당합니다. | ||
==사용 사례== | ==사용 사례== | ||
===전체 지갑 공유 : m=== | ===전체 지갑 공유 : m=== | ||
− | 두 시스템이 하나의 공유 | + | 두 시스템이 하나의 공유 Wallet에 액세스해야하고 둘 다 지출을 수행 할 수 있어야하는 경우 마스터 개인 확장 키를 공유해야합니다. 노드는 외부 체인을 위해 캐시 된 N 개의 미리보기 키 풀을 수신 지불을 감시 할 수 있습니다. 여기서 내부 쇠사슬에 대한 사전 검색은 매우 작을 수 있습니다. 첫 번째 사용되지 않는 계정의 체인에 대해 추가 미리보기가 활성화되어 사용할 때 새 계정을 만들 수 있습니다. 계정 이름은 수동으로 입력해야하며 블록 체인을 통해 동기화 할 수 없습니다. |
===감사 : N (m / *)=== | ===감사 : N (m / *)=== | ||
− | 감사인이 입출금 목록에 대한 완전한 액세스를 필요로하는 경우 모든 계정 공개 확장 키를 공유 할 수 | + | 감사인이 입출금 목록에 대한 완전한 액세스를 필요로하는 경우 모든 계정 공개 확장 키를 공유 할 수 있습니다. 그러면 감사인은 모든 계좌에서 지갑과의 모든 거래를 볼 수 있지만 단일 비밀 키는 볼 수 없습니다. |
===사무실 단위 잔액 : m / i H=== | ===사무실 단위 잔액 : m / i H=== | ||
− | 기업이 여러 개의 독립 사무소를 운영하는 경우 단일 마스터에서 파생 된 지갑을 모두 사용할 수 | + | 기업이 여러 개의 독립 사무소를 운영하는 경우 단일 마스터에서 파생 된 지갑을 모두 사용할 수 있습니다. 이를 통해 본사는 모든 사무실의 모든 송수신 거래를 볼 수있는 수퍼 지갑을 유지할 수있을뿐 아니라 사무실간에 돈을 이동할 수도 있습니다. |
===반복되는 B2B 트랜잭션 : N (m / i H / 0)=== | ===반복되는 B2B 트랜잭션 : N (m / i H / 0)=== | ||
− | 두 비즈니스 파트너가 돈을 송금하는 경우, 특정 계정 (M / ih / 0)의 외부 체인에 대한 확장 공개 키를 일종의 "수퍼 주소"로 사용하여 (쉽게) 연관시킬 수없는 빈번한 트랜잭션을 허용 할 수 | + | 두 비즈니스 파트너가 돈을 송금하는 경우, 특정 계정 (M / ih / 0)의 외부 체인에 대한 확장 공개 키를 일종의 "수퍼 주소"로 사용하여 (쉽게) 연관시킬 수없는 빈번한 트랜잭션을 허용 할 수 있습니다 각 지불에 대해 새 주소를 요청할 필요는 없습니다. 이러한 메커니즘은 풀 지불 운영자가 다양한 지불금 주소로 사용할 수도 있습니다. |
===무보수 머니 리시버 : N (m / i H / 0)=== | ===무보수 머니 리시버 : N (m / i H / 0)=== | ||
− | 안전하지 않은 | + | 안전하지 않은 웹 서버를 사용하여 전자 상거래 사이트를 운영하는 경우 지불을받는 데 사용되는 공개 주소를 알아야합니다. 웹 서버는 단일 계정의 외부 체인의 공개 확장 키 만 알아야합니다. 즉, 불법적으로 웹 서버에 대한 액세스 권한을 얻는 사람은 대부분 모든 입금을 볼 수 있지만 돈을 훔칠 수는 없으며 나가는 트랜잭션을 구별 할 수 없으며 다른 웹 서버가받은 지불을 볼 수도 없습니다. 몇몇입니다. |
− | |||
==적합성== | ==적합성== | ||
− | 이 표준을 준수하기 위해 클라이언트는 최소한 직접 공개 키 또는 개인 키를 가져 와서 직계 하위 항목에 지갑 키로 액세스 할 수 | + | 이 표준을 준수하기 위해 클라이언트는 최소한 직접 공개 키 또는 개인 키를 가져 와서 직계 하위 항목에 지갑 키로 액세스 할 수 있어야합니다. 사양의 두 번째 부분에 제시된 지갑 구조 (마스터 / 계정 / 체인 / 하위 체인)는 권고 사항 일 뿐이므로 내부 또는 외부 체인을 별도로 지정하거나 구별하지 않아도 쉽게 호환 할 수 있도록 최소한의 구조로 제안됩니다. 그러나 특정 요구 사항에 따라 구현이 다를 수 있습니다. 더 복잡한 응용 프로그램은 더 복잡한 트리 구조를 요구할 수 있습니다. |
− | |||
==보안== | ==보안== | ||
EC 공개 키 암호화 자체의 기대에 더하여 : | EC 공개 키 암호화 자체의 기대에 더하여 : | ||
− | *공개 키 K가 주어지면 공격자는 EC 이산 대수 문제 (2 128 개 그룹 작업이 필요한 것으로 가정)보다 더 효율적으로 해당 개인 키를 찾을 수 | + | *공개 키 K가 주어지면 공격자는 EC 이산 대수 문제 (2 128 개 그룹 작업이 필요한 것으로 가정)보다 더 효율적으로 해당 개인 키를 찾을 수 없습니다 . |
이 표준의 의도 된 보안 속성은 다음과 같다. | 이 표준의 의도 된 보안 속성은 다음과 같다. | ||
− | *자식 확장 개인 키 (k i , c i )와 정수 i가 주어지면 공격자는 HMAC-SHA512의 2 256 무차별 공격 보다 부모 개인 키 k par를 더 효율적으로 찾을 수 | + | *자식 확장 개인 키 (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 무차별 대항력 보다 더 효율적으로 수행 될 수 없다 . | *임의의 수 (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 )가 주어지면, i 를 찾기가 어렵습니다. |
− | *부모 확장 공개 키 (K par , c par ) 및 강화되지 않은 자식 개인 키 (k i )가 주어지면, k par 를 찾기가 | + | *부모 확장 공개 키 (K par , c par ) 및 강화되지 않은 자식 개인 키 (k i )가 주어지면, k par 를 찾기가 어렵습니다 . |
− | |||
==시사점== | ==시사점== | ||
− | 개인 키와 공개 키는 평소처럼 안전하게 | + | 개인 키와 공개 키는 평소처럼 안전하게 보관해야합니다. 개인 키 누출은 동전에 대한 액세스를 의미합니다. 공개 키를 유출하면 개인 정보가 손실 될 수 있습니다. |
− | 확장 된 키는 키의 전체 (하위) 트리에 해당하기 때문에 다소주의를 | + | 확장 된 키는 키의 전체 (하위) 트리에 해당하기 때문에 다소주의를 기울여야합니다. |
− | 즉각적으로 밝혀지지 않을 수있는 약점 중 하나는 상위 확장 공개 키와 하위 확장 비공개 키에 대한 지식이 상위 확장 개인 키 (즉, 하위 개인 키와 공개 키 모두)를 아는 것과 동일하다는 | + | 즉각적으로 밝혀지지 않을 수있는 약점 중 하나는 상위 확장 공개 키와 하위 확장 비공개 키에 대한 지식이 상위 확장 개인 키 (즉, 하위 개인 키와 공개 키 모두)를 아는 것과 동일하다는 것입니다. 이것은 확장 공개 키가 일반 공개 키보다 더 신중하게 다루어 져야 함을 의미합니다. 강화 된 키가 존재하는 이유이기도하며 트리에서 계정 수준으로 사용되는 이유이기도합니다. 이렇게하면 계정 고유의 (또는 아래) 개인 키 누출이 마스터 또는 다른 계정을 손상시키지 않습니다. |
<ref> | <ref> | ||
− | maguayo, 〈[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation BIP32]〉, | + | maguayo, 〈[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation BIP32]〉, 《짓허브》</ref> |
− | |||
== 참고자료 == | == 참고자료 == | ||
* 공룡, 〈[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- | + | *maguayo, 〈[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation BIP32]〉, 2018-10-26《짓허브》 |
== 같이 보기 == | == 같이 보기 == | ||
* [[BIP]] | * [[BIP]] | ||
− | {{블록체인 기술| | + | {{블록체인 기술|토막글}} |