안전한 비밀 키 보관에 대한 고찰

[gondre]

안녕하세요 gondre입니다. 지난번에 스팀잇에 글을 처음으로 쓰고 나서 사이트를 더 둘러보다가, 스팀잇에는 계정을 만들때 생성된 비밀 키 외에도 사용 용도에 따라 여러가지 종류의 권한이 다른 키를 제공하고 있는 것을 보았는데요, 이것을 어떻게 하면 안전하게 저장할까 고민하다가 이 글을 쓰게 되었습니다. 암호화폐 지갑에 대한 기본적인 개념부터 하여 나만의 종이지갑을 만드는 법까지 쭉 다뤄보도록 하겠습니다.

목차

1. 계정관리 방식의 변화(ID/PW 기반 -> 공개키 암호화 기반)
2. 비밀키 보관 시나리오 비교
   2.1. 계정 생성 방식의 온라인 지갑
   2.2. Key 입력 방식의 온라인 지갑
   2.3. 데스크톱 지갑
   2.4. 모바일 지갑
   2.5. 암호화폐 전용 하드웨어 지갑
   2.6. 종이 지갑
3. 비밀키를 안전하게 보관하기 위한 요구사항
   3.1 접근성
   3.2 다중성 (Redundancy)
   3.3 기밀성(Confidentiality)
4. MEW에서 지갑을 생성하는 과정
   4.1. PassPhrase 입력 화면
   4.2. keystore 다운 화면
   4.3. Private key 다운 화면
5. 안전한 비밀키 보관 방법 제안
   5.1. MEW처럼 keystore을 바로 제공하는 경우
   5.2. private key 혹은 mnemonic phrase만을 제공하는 경우
6. 결론

---

1. 계정관리 방식의 변화(ID/PW 기반 -> 공개키 암호화 기반)

전통적인 서버/클라이언트 방식의 서비스들은, 서버가 사용자들의 계정 정보를 암호화해서 보관하고 있는 가운데, 사용자가 계정 정보를 입력하면 서버가 세션을 발급하면서 클라이언트의 요청을 인증하는 방식이 보편적이었다. 그러나 이렇게 신뢰하는 제3자 방식을 통한 인증 방식은 중앙 서버만 탈취하면 공격자가 모든 사용자들의 계정을 탈취할 수 있기 때문에, 서버는 해커들의 지속적인 공격 대상이었고, 해킹으로 인한 피해는 시간이 갈수록 증가하였다. 하지만 비트코인을 필두로 한 블록체인의 개념이 보편화 되면서, 공개키를 기반으로 계정을 인증하는 "대중적인" 서비스들이 생겨나기 시작했다. 스팀잇은 가장 대표적인 사례라고 볼 수 있겠다.

공개키 기반의 전자서명은

1. 송신자가, 공개키(public key)만 네트워크 상에 노출시킨 다음
2. 송신자가, 전달하고자 하는 정보를 비밀키(secret key, private key)로 암호화하여 서명(sign)을 생성하고
3. 전달하고자 하는 정보와 서명을 묶어서 상대방에게 보낸 뒤
4. 수신자가, 서명을 공개키를 사용하여서 복호화했을때, 송신자가 첨부한 정보와 동일하다는 것을 검증(verify)함

으로써 해당 정보가 그 공개키에 대응되는 비밀키를 보유한 사용자에 의해 만들어졌음을 검증하게 된다.

공개키의 작동 방식은 검색을 통해서도 충분히 얻을 수 있으니 이 글에선 생략하기로 하고,(참고: RSA를 이용한 암호화와 서명) 이 글에서는 공개키 암호화의 핵심이 되는 비밀키의 안전한 보관에 대해서 고민해보도록 하겠다.

2. 비밀키 보관 방식 (지갑 형태) 비교

암호화폐 지갑들이 비밀키를 어떻게 보관하는지에 대해서 생각해보자.

암호화폐 지갑 형태는 크게 온라인지갑, 데스크톱지갑, 하드웨어지갑, 페이퍼지갑 으로 나뉜다. (관련포스트) 이 중에서 사용 방법에 따라서 조금 더 지갑 형태를 세분화해보자.

2.1. 계정 생성 방식의 온라인 지갑 (BlockChain )

• 장점 : ID/PW만 알고 있으면 언제 어디서든 접근할 수 있다
• 단점 : 해당 지갑 사이트가 내 비밀키를 안전하게 보관하고 있다고 믿어야한다. 즉 사이트가 뚫리면 내 비밀키도 탈취당할 가능성이 있다. 전통적인 서버/클라이언트 모델이다.

2.2. Key 입력 방식의 온라인 지갑 (MyEtherWallet)

• 장점 : 클라이언트를 설치할 필요 없이, 하드웨어 지갑을 연결하거나, private key를 암호화한 keystore 파일과 이 파일에 대한 암호를 입력하거나, mnemonic phrase혹은 private key 자체를 이용해서 바로 계정에 접근할 수 있다.
• 단점 : 사용할 때만 비밀키를 올리면 된다는 점에서 1번방식의 온라인 지갑보다는 안전하지만, 해당 사이트가 내 비밀키를 중간에 수집하지 않는다는 보장을 확실히 할 수 없기 때문에, 확실히 검증된 지갑 사이트를 이용해야한다. (확실히 검증된 지갑 사이트라 함은, 해당 코인의 공식 홈페이지에서 "여기는 써도 된다"라고 한 사이트들을 의미함). 만약 누군가가 피싱 사이트를 만들었다면 (최근의 binance 피싱사이트 사태처럼), 공격자에게 내 비밀키를 직접 전달해버릴 가능성이 있다. 다만 하드웨어 지갑들은 인증서 검증을 해서 피싱 사이트 접속을 차단하는 기능을 제공하기 때문에, 직접 private key 혹은 keystore를 입력하는 경우만 피싱 사이트에 의해서 피해를 볼 가능성이 있다고 보면된다.

실제로 MEW를 보면, keystore, mnemonic phrase, private key 로 계좌를 접근할 때 같은 내용의 경고 문구를 써 놓고 있다.

2.3. 데스크톱 지갑(JAXX, EXODUS, Mist,)

• 장점 : 다운받아 설치하면 되기 때문에 그리 불편하진 않다. 데스크톱과 모바일을 동시에 지원하는 지갑들도 있기 때문에 사용 환경을 통일할 수 있다. JAXX나 EXODUS 같은 multi currency wallet은 대부분 shape shift를 지원하기 때문에 지갑 내에서 바로 코인을 교환할 수 있다. 로컬에서 보관하고 있기 때문에 온라인 방식보단 안전하다.
• 단점 : 여전히 인터넷과 연결된 환경이기 때문에 공격받을 가능성이 있다. 해당 지갑이 내 비밀키를 안전하게 지키고 있다고 믿어야한다. (만약 데스크톱 지갑이 내 비밀키를 암호화해서 보관하지 않은 상태에서 내 컴퓨터에 해커가 침입했다면?) 만약 내 컴퓨터에 문제가 생기고(내 컴퓨터가 랜섬웨어에 감염되어 디스크가 모두 암호화 됐다고 생각해보자), 지갑을 복구할 mnemonic phrase를 잃어버리면 지갑에 접근할 수 없게된다.

2.4. 모바일 지갑( Coinnomi )

• 2.3과 비슷한 특징을 공유한다. 그런데 아직까지 암호화폐가 실사용되는 일이 많지 않기 때문에 아직까진 모바일 지갑의 장점인 휴대성을 통한 이득을 얻을 수 있을만한 상황이 별로 없는것 같다

2.5. 암호화폐 전용 하드웨어 지갑 (TREZOR, Nano Ledger S)

• 장점 : 인터넷과 분리된 하드웨어에 비밀키를 보관한뒤, 송금이 필요할 땐 2.3의 데스크톱 지갑또는 2.2의 온라인 지갑 사이트에 하드웨어 지갑을 연동시켜서 PIN 인증을 한 뒤 송금을 할 수 있게 해준다. 참고로, 대부분의 하드웨어 지갑 제작사는 자체적인 만든 데스크톱 지갑 앱도 제공해준다. 비밀키를 직접적으로 사용자에게 노출시키지 않는다. 1, 2
• 단점 : 비밀키를 export할 수 없다. (장점이자 단점) 지갑을 복구할 수 있도록 키 생성에 사용한 mnemonic phrase를 사용자에게 따로 적어놓도록 요구하지만, 이로 인해서 mnemonic phrase자체가 또 하나의 공격대상이 되기 때문에 mnemonic phrase를 안전하게 보관해야 하는 조건이 생겨난다. mnemonic phrase가 private key를 생성하는데 쓰일 수 있는 code이므로, 사실상 mnemonic phrase와 private key는 같은 보안 수준에 있다고 말할 수 있다. mnemonic phrase와 private key와의 차이는, human readable 한가 아닌가의 차이 뿐이다. 해당 하드웨어 지갑이 제공하는 "암호화폐" 키 보관 외에 다른 키를 보관할 수 없다. (공개키 암호화 방식으로 돌아가는 서비스에서 발급한 계정 비밀키를 저장하기 위한 용도로 사용할 수 없음.)

2.6. 종이 지갑

• 장점 : 하드웨어 지갑과 비슷한 수준의 보안성을 갖지만 비용이 들지 않는다. private key를 인쇄만 하면 되기 때문에, 암호화폐 비밀키든, 공개키 기반 서비스의 비밀키든 그냥 본인이 알아볼 수 있게 인쇄만 하면 된다.
• 단점 : private key를 출력해서 보관하기 떄문에 이 종이가 공격대상이 된다. 데스크톱 지갑 또는 온라인 지갑에 private key를 import하기 위해서 수기로 입력해야한다.

3. 비밀키를 안전하게 보관하기 위한 요구사항

3.1. 접근성

접근성이 너무 좋으면 보안성이 낮아지게 된다. 2.1처럼 ID/PW를 이용한 사이트를 통해서 지갑을 사용하는 것은 접근성이 가장 좋지만, 이 방식을 쓰게 되면 공개키 암호화 방식을 쓰는 이유가 사라지게 된다. 공개키 암호화의 핵심은, 비밀키를 절대 외부에 노출시키지 않고 오직 나만 알 수 있게 보관하는 것이다. 비밀키가 네트워크 상에 공개될 가능성은 애초에 차단하는게 좋다.

그러나 너무 보안성을 중시한다면 접근성이 떨어지게 된다. 2.6의 종이 지갑은 인터넷과 분리된 물리 종이에 private key를 인쇄하는 것이기 때문에 보안적으론 우수할지 몰라도, 사용하기 위해선 private key를 매번 입력해야 하는 단점이 있다.

따라서 이 둘의 적절한 타협점인 하드웨어 지갑은 보안성과 접근성을 둘다 잡았다고 생각할 수 있다. 그러나 하드웨어 지갑은 mnemonic phrase를 안전하게 보관해야 하는 또 하나의 요구사항이 생겨나고, 또 앞서 말했듯이, 암호화폐 비밀키 외에 다른 용도로 쓰이는 비밀키를 저장할 수가 없는 단점이 있다.

3.2. 다중성 (Redundancy)

만약 하드웨어 지갑의 mnemonic phrase나, private key를 인쇄한 종이 묶음을 집에 보관하고 있었는데, 집에 불이 났다고 쳐보자. mnemonic phrase와 비밀키를 인쇄한 종이를 챙겨 나오지도 못하고, 하드웨어 지갑 마저 못챙겨 나왔다면 내 모든 자산이 통채로 날려가는 것이다.
이런 상황을 막으려면, mnemonic phrase나 private key를 적절히 복제해서 여러곳에 분산해서 저장해야 할 필요가 있다. 일반적으로 집에 하나, 은행 금고에 하나 이렇게 하면 일반인 수준에선 가장 적절한 수준일 것이다.

그러나 이런 다중 복제는 보안 취약점을 비례해서 늘려준다. 만약 내 비밀키 종이를 100장 복사해서 100군데 뿌려놓았다면 절대 잃어버릴 일은 없겠지만, 누군가 내 비밀키 종이를 탈취할 가능성을 100배 높여준다. 따라서 다중성을 늘리는 것은 해당 보안 자산이 분실했을 사태에 대비해서 복원할 수 있는 가능성을 높여주지만, 보안 수준을 높이진 못하고 오히려 떨어트리는 수단이 된다.

3.3 기밀성 (Confidentiality)

private key나 mnemonic phrase 자체가 보안을 유지해야 하는 자산이라면, 누군가가 이것을 보았을 때 그 내용을 바로 알아차릴 수 없게 해야 한다. (누군가 내 집에 침입해 private key를 적은 종이를 열람하는 상황을 생각해보자) 이를 위해선 private key나 mnemonic phrase 자체를 암호화 하고 필요 할 때 복호화해서 사용하면 된다.

이 방법은 MEW에서 지갑을 생성할때 이미 사용되는 방식이다. MEW에서 지갑을 생성하기 시작하면, 처음에 비밀번호를 입력하라고 한 뒤, keystore 파일을 다운받으라고 하는데, 이 keystore파일에는 private key가 암호화된 내용을 담고 있다. 따라서 keystore 파일에 passphrase를 넣어 복호화 해야 private key를 생성할 수 있기 때문에, 내 컴퓨터에서 keystore 파일을 저장하고 있는것은 private key자체를 보관하는 것보다 더 안전하다고 말할 수 있다.

음... 왠지 나 혼자서 신나게 말만 하고 있는것 같으니 직접 MEW에서 지갑을 생성해보면서 각 과정을 이해해 보도록 하자.

4. MEW에서 지갑을 생성하는 과정 설명

4.1. PassPhrase 입력 화면

MEW에서 New Wallet탭을 가면, 그냥 뜬금없이 비밀번호를 입력하라는 화면이 나온다. ID/PW에 익숙한 사람들은 무슨 뜬금없이 비밀번호만 입력하라고 하냐 라고 해서 생소할 수 있는데, 이 비밀번호는 private key를 암호화하여 keystore를 생성하는데 사용되는 대칭키이다. 달리 말하면, keystore를 복호화하는데 사용되는 키라고도 말할 수 있겠다.. 위 입력창 하단에도 "This password encrypts your private key."라고 짧게 설명이 나오고 있다.

필자는 여기서 gondre1234 를 PassPhrase로 사용하였다. 이 설명에 나오는 주소와 private key는 모두 설명을 위해 임의로 만든 것이기 때문에, 이 설명에 나오는 주소로 이더리움을 전송하진 말아달라. (혹시 돈을 버리고 싶다면 이 글 하단에 있는 필자의 지갑으로 전송해주길 바란다!)

4.2. keystore 다운 화면

적당한 비밀번호를 입력하고 나면, keystore 파일이 생성되었으니 다운받으라고 나온다.

keysotre 파일의 내용이 궁금하니 한번 까보도록 하자.

{
  "version": 3,
  "id": "6acf04d2-a663-412b-8f83-ee7d3d20e5e3",
  "address": "a4b988c765c38f781e431dd0185163a74ad085cf",
  "Crypto": {
    "ciphertext":
      "682977c1f7452baae4a587342417d82a229fb41c7b47482b1b5644842cbb3d17",
    "cipherparams": { "iv": "2f72444b15c0dbc572ae89ec665d8f41" },
    "cipher": "aes-128-ctr",
    "kdf": "scrypt",
    "kdfparams": {
      "dklen": 32,
      "salt":
        "331ca80f2ccb928a1d82d6adaeb438ad72049a0b2fb4a1102037bf2023111ab1",
      "n": 8192,
      "r": 8,
      "p": 1
    },
    "mac": "4a7bd367a182846645061e8d9e246ae22a1cfec60c9bf935ea332aa312295e87"
  }
}

keystore파일에 대한 자세한 설명은 이링크에서도 확인할 수 있는데, keystore파일을 복호화하는 프로세스를 대충 설명하면 아래와 같다.

4.2.1. PassPhrase를 입력한다

• 이 PassPhrase는 종이에도 쓰지 말고 그냥 머릿속으로만 기억하고 있어야 한다.

4.2.2. kdfparams에 있는 파라미터들을 반영하여 "decryption key"를 생성한다

• 이것을 하는 이유는, 같은 PassPhrase를 입력했더라도, 랜덤으로 만들어진 kdfparams의 salt값 의해서 서로 다른 decryption key를 생성하기 위해서다. 즉 누군가가 나를 따라서 gondre1234를 PassPhrase로 입력하여 keystore를 만들었어도, 그사람의 salt값은 지금 내 값과 다르기 때문에 생성되는 decryption key 역시 다르다
• 이 과정을 하는 이유는, Bruth force 공격을 막기 위하여 높은 엔트로피 가진 대칭키를 생성 하고, 이 대칭키로 ciphertext를 복호화하기 위해서 이다. (뭔말인지 모르면 그냥 지나가자)

4.2.3. 이 decryption key의 유효성을 검증한다

• 4.2.2.에서 만든 decryption key와, 암호화되어 있는 ciphertext를 이어붙인 다음(concatenation한 다음) SHA3-256 해쉬값을 구한다
• 이 해쉬값을, keystore가 저장하고 있던 MAC값(Message Authentication Code)과 비교하여 일치하는지 확인한다.
• 만약 일치한다면, 4.2.4로 진행하고, 일치하지 않는다면 에러를 반환한다
• 이 과정을 하는 이유는, PassPhrase의 유효성을 클라이언트단에서 검증하여서, 네트워크단에서 로드를 대폭 줄이기 위한 것으로 추정된다

4.2.4. decryption key의 유효성이 검증됐다면, 이것을 대칭키로 사용하여서 ciphertext를 복호화 하여 private key를 복원한다.

덧

위 과정을 통해 알아차린 분도 있겠지만, keystore파일에 있는 id와 address는 그냥 참고용으로 넣어놓은 값이었다. 실제 id와 address를 바꾼 뒤 keystore 파일을 업로드해보면 바꾼 값에 상관없이 passphrase만 잘 입력한다면, 지갑에 접근할 수 있었다.

4.3 Private key 다운 화면

내가 MEW에서 지갑을 생성할때 좀 이해가 안가는게, 바로 이 과정이다. 4.1.과 4.2.를 통해서 안전한 keystore파일을 잘 만들어 놓고 갑자기 privatekey를 떡하니 노출시켜서, 잘 모르는 사용자 입장에서는 "아니 그럼 아까 입력한 passphrase는 뭐여? keystore가 중요한거여 아니면 이 privatekey가 중요한거여 아니면 둘다 중요한거여?"라는 혼란을 주고 있다.

심지어 여기서 Print Paper Wallet버튼을 누르게 되면

마치 "더 안전하게 하고 싶으면 이 이미지를 인쇄해서 보관하렴 ^^"라고 말하고 있는 듯한 이미지를 보여주는데, 이 이미지는 private key를 그냥 떡하니 다 보여주고 있기 때문에 3.3 기밀성을 갖추지 않은 정보고, 따라서 누군가 그냥 이 종이를 습득하면 지갑 소유권을 얻게 되는 것이다.

이럴거면 도대체 keystore 파일을 왜 만들라고 했냐고..... 사용자가 컴퓨터에 keystore만 저장하면 충분히 안전한 것을, 괜히 암호화되지 않은 privatekey를 따로 또 저장하게 만들어서 보안 취약점을 털털 만들어내고 있다. 혹시 MEW에서 지갑을 생성한 뒤 keystore과 private key를 같이 저장한 사람이 있다면, private key는 파기하도록 하자. (단, passphrase를 기억하고 있단 전제 하에). private key는 MEW의 ViewWalletInfo 페이지에서 복원해낼 수 있다.

5. 안전한 비밀키 보관 방법 제안

여기까지 다 읽었고 잘 따라와 주었으면, 다음의 내 결론을 이해할 수 있을 것이다

private key를 어떤 형태로든 바로 저장하고 있는 것은 보안상 취약점이 되며, MEW의 keystore처럼 private key를 한번 암호화한파일을 갖고 있는 것이 안전하다. 또한, mnemonic phrase는 private key와 같은 보안 수준을 갖고 있는 정보기 때문에, mnemonic phrase 역시 마찬가지로, 한번 암호화 한 파일을 보관해야 한다. 이렇게 암호화 된 파일은 기밀성을 갖추고 있기 때문에, 적당히 물리적으로 복제(redundancy)하여 저장한다고 해도, 제 3자가 취득하였을 때 암호화에 사용된 알고리즘과 passphrase를 동시에 알아야 복호화를 할 수 있기 때문에 보안이 유지된다. 단, 암호화에 쓴 알고리즘과 passphrase를 동시에 알고 있는 사용자가 쉽게 복원할 수 있도록 접근성을 확보해야 한다

keystore 파일은, 하나는 접근성을 위해 인터넷과 분리된 저장소에 파일 형태로(가정용 usb로도 충분하다고 본다), 하나는 종이에 프린트 하는 방법을 권장하는데, 종이에 프린트 한것을 복구에 사용하기 위해서 다시 수기로 입력하는 것은 효율이 떨어지기 때문에 qrcode로 프린트해서 보관하는 것이 좋다고 생각한다.

그럼 두가지 시나리오에 대해서 생각해보도록 하자.

5.1. MEW처럼 keystore을 바로 제공하는 경우

이 경우에는 keystore 파일을 그대로 보관하면 된다. 출력을 하고 싶으면 qrcode로 인코딩 하여 출력하면 된다. qrcode 인코딩 방법은 아래에 나온다.

5.2. private key 혹은 mnemonic phrase만을 제공하는 경우

이 경우에는 openssl 같은 암호화 툴을 이용하여 private key 혹은 mnemonic phrase를 암호화 하여 keystore 파일을 만든 뒤 저장해야 한다. 좀더 구체적인 방법은 아래와 같다.

5.2.1. private key 혹은 mnemonic phrase를 확보한다

보통 지갑 생성시에 보여주는 경우가 대부분이며, export key 혹은 display mnemonic phrase 같은 메뉴를 통해서 다시 확인할 수 있게 해주기도 한다.

여기에서는 key.txt 파일을 만들어서 그 안에 아래와 같은 mnemonic phrase를 저장했다고 가정해보겠다

<key.txt>

circle wool tuition lesson 
trick assume solve punch 
display sail jewel outdoor 
spatial vital birth drip 
illness midnight orange detect 
today polar narrow urban

5.2.2. key.txt를 암호화 하여 keystore를 만든다

• 대칭키 알고리즘를 사용한다. 여기에선 aes-128-ctr을 사용 (AES: 고급 암호화 표준)
• base64로 인코딩 하여서 qrcode로의 생성을 용이하게 한다. base64 인코딩은 암호화와 관련이 없다. 단지 qrcoded에 입력값으로 사용하기 위해서 데이터를 한번 인코딩하는 것 뿐이다
• 암호화 시 입력하는 passphrase는 종이에도 적지 말고 기억만 한다. 이 passphrase는, 기억할수 있는 10자 이상의 숫자 영문자 특수문자 조합이면 충분하다. 기억을 못할 정도로 긴 암호를 만든다면 결국 어딘가에 다시 적어야 하고 그럼 그 적어놓은 것이 보안 취약점이 되어버린다.
• openssl은 linux나 mac에는 기본적으로 깔려있으나, 윈도우에선 따로 설치를 해야하는것 같다. 설치는 알아서...
• 아래와 같은 openssl 명령어를 입력하여서, base64로 인코딩 된 keystore 파일을 생성한다

$ openssl enc -e -base64 -aes-128-ctr -in key.txt -out keystore

enc: openssl에서 encrypt, decrypt와 관련된 커맨드를 수행
-e : encrypt작업을 수행
-base64 : base64로 인코딩
-aes-128-ctr : aes-128-ctr 알고리즘으로 암호화
-in key.txt : key.txt 파일을 인풋으로 사용
-out keystore : 결과물을 keystore 파일에 저장

이렇게 입력하면 enter aes-128-ctr encryption password: 라는 메시지가 뜨는데, 그때 본인이 원하는 pass phrase를 입력하면 된다. 나는 여기서 gondre1234라고 입력해보겠다.

위 작업을 마치고 나면, 아래와 같은 keystore 파일이 생성된다

$ cat keystore
U2FsdGVkX19bSOKK8TsY1S/r5vQegjttnDYRaaj22/Qh2nhpF2iyDsXmFN0sTewH
cNtqvAcTR737b8lEjON9FENYsGJNzQnyEipzOqXni1NVoVaifkM5E7qxkWnX6Yw0
VJuIKnncG6Ep8EJ+HXi/l7e2t9ZHg1QWIFBeaKNtllBbmHVJ/aSL3Lof2FkjVI1o
9QM3XhcS9Q8Du6BGg7h6nJbywV4WnJCCck73JCkXf6dJbQr+Tg==

암호화 완료!

암호화를 완료하고 난 뒤에 바로 key.txt를 지우지 말고, 아래 과정을 통해서 복호화가 잘 되는지 확인을 하고 key.txt를 삭제하자. 강조하지만, key는 잃어버리면 다시는 찾을 수 없다.

5.2.3. 종이에 인쇄하기 위한 qrcode 생성

• 만약 qrcode를 따로 만들지 않고, keystore만 갖고 있다가 바로 복호화를 하려고 하면 5.2.5로 넘어가자
• online qrcode generator들도 있으나, 가급적 로컬에 설치하는 qrcode encoder app을 사용하자
• qrcode 스펙을 보면 alphanumeric으로는 최대 4296개까지 문자열을 넣을 수 있다고 하니, 입력값으로 사용되는 keystore의 문자열이 4296개를 넘지 않도록 하자. (qrcode standard)
• 참고로 위에서 만든 keystore의 문자 수는 247개다. 즉 mnemonic phrase나 private key를 여러개 묶어서 하나의 keystore로 만들어도 되긴 된다는 뜻. steemit같은 경우 key가 4개나 되니 이것들을 모아서 key.txt에 넣는게 좋을 것 같다
• 아래는 위의 keystore를 실제 입력값으로 넣어서 만든 qrcode

• 이제 이 qrcode를 인쇄해서 보관하면 된다.

5.2.4 qrcode scan

• qrcode encoder 앱 만큼이나 reader 앱도 많으니 아무거나 설치해서 qrcode를 읽어들인다
  

• qrcode reader가 읽어들인 텍스트 내용

U2FsdGVkX19bSOKK8TsY1S/r5vQegjttnDYRaaj22/Qh2nhpF2iyDsXmFN0sTewH
cNtqvAcTR737b8lEjON9FENYsGJNzQnyEipzOqXni1NVoVaifkM5E7qxkWnX6Yw0
VJuIKnncG6Ep8EJ+HXi/l7e2t9ZHg1QWIFBeaKNtllBbmHVJ/aSL3Lof2FkjVI1o
9QM3XhcS9Q8Du6BGg7h6nJbywV4WnJCCck73JCkXf6dJbQr+Tg==

이 텍스트를 keystore-read.txt라는 파일로 저장해놓자.

5.2.5 keystore 복호화

• 아래 openssl 명령어를 입력한다
• 패스워드 입력하라고 하면, 암호화 시에 사용한 패스워드를 입력하면 된다

$ openssl enc -d -base64 -aes-128-ctr -in keystore-read.txt
enter aes-128-ctr decryption password:
circle wool tuition lesson
trick assume solve punch
display sail jewel outdoor
spatial vital birth drip
illness midnight orange detect
today polar narrow urban

짜잔! mnemonic phrase가 잘 출력되었다. 이제 이것을 내 지갑 복원할 때 사용하면 된다.

이렇게 암,복호화가 잘 된다는것을 확인했으면, 이제 mnemonic phrase의 원문을 갖고 있는 key.txt 파일은 삭제해버리자. 이제 세상 어디에서도, 내가 저장하고 있는 keystore를 복호화 하는 방법 외에는, 저 mnemonic phrase를 직접 확인할 수 있는 방법은 없다.

6. 결론

어떻게 하면 비밀키를 안전하게 보관할까 라는 고민에서 출발했다가, 꽤 긴 글을 쓰게 된것 같습니다. 그냥 개발자한테 설명한다고 하면 "그냥 너 혼자 알고 있는 대칭키 써서 암호화 한다음에 카피해놔!"라고 한문장으로 말할 수 있는 것을, 기초 개념부터 설명하고자 하는 욕심 때문에 글이 굉장히 길어진 것 같네요.

한가지 걱정은, 이렇게 openssl을 쓰고 qrcode로 인코딩 하는것을 아무리 쉽게 설명한다고 해도 일반인 수준에선 어렵게 느껴질 수 있다는 점입니다. 어려운 내용은 아니니 제가 직접 툴을 만들수도 있으나, 이론적인 방법을 아는것과, 높은 수준의 보안성을 갖춘 프로그램을 만드는 것은 또 다른 레벨이기 때문에, 나보다 더 대단한 고수가 시간 내서 툴을 만들어주겠지 라고 기대를 가지며 글은 이만 마치도록 하겠습니다.

혹시 제 글이 도움이 되었다면 소정의 수고비라도 주시는게 어떨까요? ^^; 미리 감사합니다~
BTC address : 1JVZJ2mSbksubDAuMSsor4WufpJCutZCNB
BCH address : qzdsv5pevcx653n09kjmxze692v9ftugacnhzv7kt9
ETH address : 0xA8E131655C2e70443E0742FAD981124dfBAf4B09
LTC address : LUR1NvgVcK4mnUMZZjFMhNXP22ZAuaqbvX
DASH address : XdWxEFkYmKQAUbfzF5TZJKm5CfmjU6hins
ETC address : 0x8d482c22BeEa6665D0cBAc9E1A8D721A749F7325

Comments

[bunnysbutt]

좋은 글 감사합니다 :)

[gondre]

하핫 드디어 사람이 달아주는 첫 댓글을 구경해보는군요 ㅋㅋ 읽어주셔서 감사합니다 :)

[steemitboard]

Congratulations @gondre! You have completed some achievement on Steemit and have been rewarded with new badge(s) :

You got a First Reply
Award for the number of upvotes

Click on any badge to view your own Board of Honor on SteemitBoard.
For more information about SteemitBoard, click here

If you no longer want to receive notifications, reply to this comment with the word STOP

Upvote this notification to help all Steemit users. Learn why here!