a16z: 개인 키가 반복적으로 위반되었습니까? Web3 보안은 지갑에서 시작해야 합니다.

개인은 자신의 개인 키(및 암호 자산)에 대한 직접적이고 단독적인 제어권(및 소유권)을 가집니다. 이 철학을 준수하는 암호 지갑은 "비수탁" 지갑으로 알려져 있으며, 이는 외부인이 키에 액세스할 수 없음을 의미합니다.

일련의 "비수탁" 지갑 해킹 사건까지 - 9월 Wintermute 개인 키가 "무차별 공격"되어 1억 6천만 달러 손실, August Slope 지갑 해커가 8,000개 이상의 계정에 침입, 2020년 Trinity는 2백만 달러 이상의 IOTA 지갑 해킹을 훔쳤습니다. , 2017년 150,000 ETH를 훔친 Parity 지갑 해킹, 다양한 하드웨어 지갑 취약점으로 인해 관리형 지갑과 비관리형 지갑 사이의 보안 경계가 모호해졌습니다. 이러한 경우 피해자는 비수탁형 지갑을 사용하고 있다고 생각하지만 개인 키가 도난당했다는 사실을 알게 됩니다.

실제로 비수탁형 지갑은 일반적으로 다른 사람의 하드웨어와 소프트웨어에 의해 생성되고 실행되기 때문에 사용자에게 키에 대한 완전한 제어권을 실제로 부여하지 않습니다. 사용자는 점점 더 타사 제품을 신뢰하고 있습니다. 이러한 제품은 블록체인 명령줄 인터페이스, 지갑 소프트웨어 및 장치, 중앙 집중식 플랫폼, 스마트 계약 코드, 분산 응용 프로그램을 통합하거나 사용하며 각 접점은 위험을 증가시킵니다. 이러한 모든 연결점은 사람들이 "관리되지 않는" 개념에 대해 가지고 있는 장밋빛 환상을 산산이 부수고 있습니다.

"관리되지 않음"은 실제로 많은 관리 요소를 참조할 수 있습니다.

일반적으로 키 관리(지갑 보안의 기초)는 세 가지 방향으로 나눌 수 있습니다.

1. 키 생성(암호화 키 생성)
2. 키 저장(미사용 키 보호);
3. 키 사용(키 인증 사용).

각 방향에는 고유한 위험 지점이 있습니다.

이 기사는 암호화된 지갑 보안 및 커스터디 플랫폼의 특징과 단점을 소개하고, 향후 가장 관심과 개발이 필요한 영역을 다루며, Web3 사용자가 비커스터디 방식으로 암호화된 자산을 보호하는 복잡성을 더 잘 이해하도록 돕는 것을 목표로 합니다. . 또한 우리는 엔지니어가 지갑 개발의 일반적인 실패 지점을 식별하고 피하도록 돕고 Docker, Anchorage, Facebook 및 a16z 암호화 시스템에 대한 수년간의 포괄적인 경험을 사용하여 사용자와 프로젝트 당사자가 보안 사고를 피할 수 있도록 돕고 싶습니다.

키 생성

키 생성 단계의 보안은 매우 중요합니다. 이 단계에서 염두에 두어야 할 세 가지 중요한 문제가 있습니다. 신뢰할 수 있는 코드 사용, 코드를 올바르게 구현, 출력을 안전하게 처리합니다.

일부 지갑 제공업체가 공식 웹사이트 또는 Github 저장소에 게시한 감사 보고서. 자신의 조사를 수행하고 지갑 뒤에 평판이 좋은 회사가 있는지 확인하십시오. 정보가 부족한 경우 중요한 사용자 및 개발자 활동이 유용한 지표가 될 수 있습니다.

위험을 줄이려면 다음 지침을 따르십시오. 지갑이 다음 확인에 실패하면 도망치십시오.

오랫동안 테스트되지 않은 지갑은 사용하지 마십시오.

지갑을 구성하는 코드는 평판이 좋아야 합니다. 잘못 작성된 소프트웨어를 선택하거나 고유한 대안을 개발하려고 하면 키가 유출되거나 권한이 없는 당사자에게 기밀 정보가 공개되는 것과 같은 "재앙적인 사건"이 발생할 수 있습니다.

여러 보험이 있는 지갑 사용

코드가 평판이 좋은 암호화 라이브러리를 사용하더라도 적절하게 통합되어야 합니다. 감사된 소프트웨어는 종종 올바른 매개변수로 기본 설정되지만 실행 중에 버그가 발생할 수 있습니다. 많은 개별 키(또는 키 조각, 키 조각)를 생성하고 조정해야 하는 많은 MPC(다자간 계산) 알고리즘과 같은 특정 키 생성 프로세스의 경우 지갑은 알고리즘에 지정된 프로토콜을 따라야 합니다. 알고리즘은 또한 자금의 보안을 유지하기 위해 지갑에 적절하게 통합되어야 하는 여러 라운드의 계산 및 새로 고침 키를 요구할 수 있습니다.

"비밀을 지켜주는" 지갑을 사용하세요

키 생성 프로세스의 마지막 단계에는 소프트웨어의 실제 작동 및 출력이 포함됩니다. 키가 생성되는 위치와 형식에 유의하십시오. 이상적으로는 독립적인 하드웨어에서 키를 생성하고 신뢰할 수 있는 알고리즘을 사용하여 정보를 암호화해야 합니다.

올 여름 해킹된 슬로프 지갑의 키는 외부 서버에 로그인하기 위해 평문으로 생성됐다. 이러한 종류의 보안 허점은 코드 감사 또는 오픈 소스 구현에서 나타날 수 있습니다. 지갑의 투명성 부족 – 비공개 소스 코드가 특징이며 대중에게 공개되는 제3자 보안 감사가 없어야 합니다.

키 저장소

키가 생성된 후에는 어딘가에 숨겨야 합니다(일반 텍스트가 아니라 항상 암호화됨). 그러나 키를 저장하는 장치의 단순한 소유가 반드시 키의 소유권 및 제어와 동일하지는 않습니다. 장치의 공급망 보안, 장치 연결 방법 및 장치가 상호 작용하는 다른 구성 요소와 같은 많은 요소를 고려해야 합니다. 또한 각 스토리지 방법에는 보안, 접근성, 유지 관리 용이성 및 가용성 간에 고유한 장단점이 있습니다.

아래에는 관련된 알려진 위험 수준에 따라 가장 일반적인 지갑 보안 범주를 분류했습니다.

고위험: 핫 월렛

다른 모든 조건이 같다면 콜드 월렛은 핫 월렛보다 더 안전하지만 사용하기 더 어렵습니다. 모든 네트워크에 연결된 지갑은 공격자가 취약점을 찾아 악용할 수 있는 더 많은 기회를 제공하기 때문에 해킹당할 가능성이 더 높습니다.

핫 월렛 네트워킹에는 두 가지 형태가 있습니다.

• 연결 소프트웨어: 온라인 데이터베이스 또는 웹 서버 애플리케이션 메모리, 브라우저 확장

이들은 가장 높은 위험입니다. 호스팅 여부에 관계없이 지갑 소프트웨어는 외부 인터넷에 연결된 키에 직접 액세스할 수 있기 때문입니다. 이상적으로는 키를 암호화해야 하며 키를 암호화하는 데 사용되는 다른 키 세트는 운영 체제 키 체인 또는 클라우드 키 관리 시스템과 같이 고도로 제한된 액세스 제어가 있는 전용 키 관리 시스템(KMS)에 저장해야 합니다.

• 연결된 하드웨어: 전용 어플라이언스, 모바일 보안 엔클레이브, 인라인 하드웨어 보안 모듈(HSM)

연결된 하드웨어는 일반적으로 연결된 소프트웨어보다 덜 위험한 것으로 간주되지만 여전히 콜드 스토리지만큼 안전하지는 않습니다. 연결된 하드웨어에서 키는 전용 하드웨어 장치에서만 생성됩니다. 그런 다음 내부 또는 공용 네트워크에 연결할 수 있습니다. 이러한 장치는 일반적으로 키 생성, 서명 및 스토리지 보안을 포함하여 키 관리와 관련된 여러 가지 책임을 집니다.

Trezor 및 Ledger와 같은 하드웨어 지갑도 있습니다. 신용 카드 결제와 같은 민감한 데이터 처리를 처리하는 것과 같은 보다 전통적인 비즈니스 설정에서 자주 사용되는 하드웨어 보안 모듈(HSM)도 있습니다.

장치는 장치를 생산하고 구성하는 공급망만큼만 안전합니다. 하드웨어 연결을 고려할 때는 신뢰할 수 있는 공급업체에서 직접 장비를 구입하는 것이 가장 좋습니다. 패키지가 손상된 것처럼 보이지 않도록 소스에서 직접 배송됩니다. 사용하기 전에 펌웨어 버전 및 구성을 확인할 수도 있습니다.

물론 나중에 권한이 없는 사람이 하드웨어 지갑을 도난당하거나 액세스할 가능성은 항상 존재합니다. 이러한 위협을 감안할 때 하드웨어 지갑에 안전한 액세스 제어 계층이 있는지 확인하는 것이 중요합니다. 즉, 모든 트랜잭션에 맹목적으로 서명하지 않도록 하는 보호 장치입니다. 컨트롤에는 암호 요구 사항, 트랜잭션의 각 단계에 대한 명시적 권한을 요청하는 프롬프트 및 트랜잭션의 실제 작업을 설명하는 간단한 요약이 포함될 수 있습니다. 또한 대부분의 하드웨어 지갑은 "키 래핑"이라고도 하는 개인 키 암호화를 지원합니다.

덜 위험: 콜드 월렛

다른 모든 조건이 같다면 콜드 월렛은 일반적으로 핫 월렛보다 더 안전한 것으로 간주되지만 일반적으로 사용하기 쉽지는 않습니다. 콜드 월렛은 내부 또는 공용 네트워크에 연결되어 있지 않습니다.

몇 가지 콜드 월렛 옵션을 검토해 보겠습니다.

• 오프라인 소프트웨어: 오프라인 서버 애플리케이션

공격자는 언제든지 컴퓨터를 훔치거나 온라인 상태로 만들 수 있기 때문에 콜드 월렛은 온라인 상태에서 안전하도록 설계되어야 합니다. HSM과 같은 특수 목적 하드웨어는 일반적으로 소프트웨어를 연결하는 것보다 더 많은 제어 기능을 제공하므로 적극 권장됩니다.

• 오프라인 하드웨어: 오프라인 하드웨어 지갑, 오프라인 하드웨어 보안 모듈(HSM)

이 솔루션은 가장 안전한 것으로 간주됩니다. 이전 범주와 유사하게 하드웨어를 도난당하고 온라인에서 얻을 수 있다고 가정해야 합니다. 따라서 앞에서 설명한 것처럼 이러한 시스템에는 적절하게 구현된 액세스 제어 계층이 포함되어야 합니다. 많은 HSM 공급업체는 키 액세스를 잠금 해제하기 전에 특정 수의 물리적 스마트 카드를 함께 가져오도록 요구합니다. 기기에 디스플레이 화면이 없더라도 사용자가 거래 세부정보를 확인할 수 있는 방법을 제공해야 합니다.

콜드 월렛이나 오프라인 월렛이 가장 안전한 카테고리이기 때문에 코인베이스, 제미니, 크라켄 등 대기업에서 관리하는 대부분의 자금과 앵커리지가 이런 방식으로 보관하고 있습니다. 이러한 플레이어 중 다수는 액세스 권한을 잃거나 시스템이 손상, 도난 또는 파괴될 경우를 대비하여 백업 및 복구와 같은 또 다른 방어선을 선택합니다.

백업 및 복원

서명 키는 암호화 후 백업해야 합니다. 암호화 서명 키와 키 래핑 키의 반복이 중요합니다. 서명 키를 백업하는 방법은 다양하지만 항상 하드웨어 기반 솔루션을 선택해야 합니다.

하드웨어 지갑의 경우 백업에는 일반적으로 개인 키가 파생되는 일반 텍스트 시드가 포함됩니다. 표준 암호화 키에는 기본적으로 액세스 제어로 암호화된 키를 파생시킬 수 있는 메커니즘이 있습니다. 액세스 제어가 충족되면 키를 다른 HSM으로 가져올 수 있습니다. 많은 수의 HSM이 스마트 카드 쿼럼에서 파생된 공통 암호화 키를 제공할 수도 있습니다. 이러한 방식으로 중요한 재료에서 하드웨어를 분리하면 단일 실패 지점을 방지하는 데 도움이 됩니다.

마지막으로 고려해야 할 인적 요소가 있습니다. 복구 메커니즘은 계정 관리 작업에 관련된 개인이 일시적 또는 영구적으로 사용할 수 없는 상황을 견딜 수 있어야 합니다. 개인은 정전 또는 기타 긴급 상황 발생 시 키를 회수할 수 있는 방법이 있는지 확인해야 합니다. 동시에 그룹 작업은 비상 시 작업을 계속할 수 있는 사람의 수를 결정해야 합니다.

키 사용법

키가 생성 및 저장되면 트랜잭션을 인증하는 디지털 서명을 만드는 데 사용할 수 있습니다. 소프트웨어와 하드웨어의 조합이 클수록 위험도 커집니다. 위험을 완화하기 위해 지갑은 다음 승인 및 인증 지침을 준수해야 합니다.

신뢰하되 검증도 하라

지갑은 확인이 필요합니다. 즉, 사용자의 신원이 확인되어야 하며 권한이 있는 당사자만 지갑의 내용에 액세스할 수 있어야 합니다. 여기서 가장 일반적인 보안 조치는 PIN 코드 또는 암호입니다. 보다 발전된 형태의 인증에는 다른 여러 보안 장치의 암호화 서명과 같은 공개 키 암호화를 기반으로 하는 생체 인식 또는 승인이 포함될 수 있습니다.

오랫동안 테스트되지 않은 지갑을 사용하지 마십시오.

지갑은 건전한 암호화 라이브러리를 사용해야 합니다. 키 자료 유출 또는 개인 키의 완전한 손실을 방지하기 위해 감사 및 보안을 확인하기 위해 몇 가지 조사를 수행하십시오. 문제를 더욱 복잡하게 만드는 것은 최신 Ed25519 라이브러리의 경우처럼 신뢰할 수 있는 라이브러리도 안전하지 않은 인터페이스를 가질 수 있다는 것입니다.

난스 재사용

잘 연구된 키 사용 함정은 특정 암호화 서명 매개변수를 의도하지 않게 재사용하는 것입니다. 일부 서명 체계에는 시스템에서 한 번만 사용되는 "한 번만 사용되는 숫자"(임의의 숫자)라는 일회성 의미가 필요할 수 있습니다. 따라서 건전한 암호화 라이브러리를 사용하고 있는지 확인하십시오. 그러나 이 공격 벡터는 2010년 Sony PlayStation 3 해킹과 같이 Web3 외부의 유명 해킹에서도 악용되었습니다.

하나의 키 하나 사용

또 다른 모범 사례는 동일한 키를 여러 목적으로 재사용하지 않는 것입니다. 예를 들어 암호화 및 서명을 위해 별도의 키를 보관해야 합니다. 이는 손상된 상황에서 "최소 권한" 원칙을 따릅니다. 즉, 모든 자산, 정보 또는 작업에 대한 액세스는 시스템 작동에 절대적으로 필요한 당사자 또는 코드로만 제한되어야 합니다. 용도에 따라 키마다 백업 및 액세스 관리에 대한 요구 사항이 다릅니다. Web3 생태계에서는 한 계정의 손상이 다른 계정에 영향을 미치지 않도록 자산과 지갑 간에 키와 시드 문구를 분리하는 것이 모범 사례입니다.

요약하다

키 보관은 생성에서 저장, 사용에 이르기까지 상호 작용하는 많은 부분과 단계가 있는 까다로운 문제입니다. 키 소유권의 관리적 또는 비관리적 특성은 일반적인 통념처럼 흑백논리가 아닙니다. 키 생성에서 저장 및 사용에 이르기까지 키 관리와 관련된 많은 이동 부분으로 인해 상황이 복잡해집니다. 체인의 모든 하드웨어 또는 소프트웨어는 원래 수탁 지갑의 일부가 아닌 옵션을 수탁 위험에 노출시키는 경우에도 위험을 초래합니다.

앞으로 우리는 공격으로부터 지갑을 보호하고 위에서 논의한 위험을 줄이기 위해 더 많은 개발 작업을 하기를 희망합니다. 개선이 필요한 영역은 다음과 같습니다.

• 모바일 및 데스크톱 운영 체제에서 안전한 오픈 소스 키 관리 및 트랜잭션 서명 라이브러리를 공유합니다.
• 공유 오픈 소스 트랜잭션 승인 프레임워크입니다.

공유 및 오픈 소스 개발도 있습니다.

• 다양한 스토리지 백엔드(디스크의 암호화, 보안 하드웨어 등)에 걸쳐 최고의 보안 키 생성 라이브러리를 구현합니다.
• 모바일 및 데스크톱 운영 체제용 키 관리 및 트랜잭션 서명 라이브러리
• 생체인식, PKI 기반 승인, 권한 복구 등 특화된 검증이 가능한 거래 승인 프로세스 프레임워크