Web3는 급속도로 확장되고 있습니다: 새로운 애플리케이션, 프로토콜, 기능이 매일 등장합니다. 하지만 많은 사용자에게 진입 장벽은 온체인 기능의 부족함이 아니라, 지갑 키를 안전하게 보호하고 복구하는 데 따르는 어려움입니다.

현재 업계 표준은 여전히 시드 구문(니모닉)입니다. 하지만 이 방식은 현실적인 어려움을 안고 있습니다. 사용자들이 종종 구문을 스크린샷으로 찍어 클라우드 앨범에 실수로 동기화하거나, 종이에 적어두었다가 분실하거나 손상되어 자산을 영구적으로 잃어버리는 경우가 많습니다. 이러한 사례는 너무나 흔합니다. 이러한 위험은 종종 기술적 실패가 아닌 일상 습관의 소홀함에서 비롯됩니다.

최근 몇 년 동안 사용자 친화적인 로그인 방식을 사용하여 지갑을 생성, 백업 및 복구할 수 있는 수많은 "Web2 스타일" 지갑 솔루션이 등장했습니다. 이들의 목표는 진입 장벽을 낮추는 것이지만, 구현 방식에는 중요한 차이가 있으며, 특히 진정한 분산형 및 자체 수탁(self-custodial) 방식을 유지하는지에 차이가 있습니다.

OneKey 키리스 지갑이 다른 점

OneKey의 키리스 지갑은 "Google/Apple 로그인 + PIN" 방식을 사용하여 사용 편의성과 진정한 자체 수탁을 단일 디자인으로 통합합니다.

익숙한 계정 시스템을 사용하여 로그인 및 복구를 수행하지만, 기본 아키텍처는 분산형 키 관리 및 서명 메커니즘을 사용합니다. 이를 통해 OneKey를 포함한 그 어떤 단일 주체도 사용자의 전체 키를 재구성하거나 일방적으로 전송을 시작할 수 없도록 보장합니다.

다시 말해, 당사의 서버, 특정 구성 요소 또는 단일 참여 주체가 손상되더라도 공격자가 단순히 OneKey에 침입하여 "귀하의 지갑을 훔치는" 것은 불가능합니다.

OneKey의 키리스 지갑은 분산형 키 관리 메커니즘을 기반으로 구축되었습니다. 목표는 시드 구문을 기록, 저장 및 전송해야 하는 높은 위험 부담에서 사용자를 해방하는 것입니다. 대신, 이미 알고 있는 방법인 Google / Apple 로그인 + PIN을 사용하여 지갑을 생성하고 복구할 수 있습니다.

전통적인 지갑은 시드 구문(일반적으로 12개 또는 24개의 단어)에 의존하며, 사용자가 필요할 때 이를 안전하게 보관하고 수동으로 복원해야 합니다. 키리스 지갑을 사용하면 단순히 PIN을 기억하는 것만으로 자산을 관리할 수 있습니다. 지갑 복구 기능은 분산형 아키텍처를 기반으로 구축되어 전체 제어 권한이 단일 서비스 제공업체에 넘어가지 않도록 보장합니다.

키리스 지갑은 두 가지 인증 요소를 사용합니다:

이는 Google 또는 Apple 계정이 손상되더라도 PIN 없이는 중요한 작업을 수행할 수 없음을 의미합니다. 반대로, PIN만으로는 연결된 계정에 로그인하지 않고는 지갑을 복구하거나 액세스하기에 불충분합니다. 두 요소 모두 필수적이므로 단일 장애 지점의 위험이 크게 줄어듭니다.

키리스 지갑 디자인에서 전체 시드 구문 또는 개인 키는 단일 위치에 장기간 평문으로 저장되지 않습니다. 장치에서 계정과 PIN을 모두 성공적으로 인증할 때만 지갑이 로컬에서 필요한 복구 및 활성화 프로세스를 완료합니다.

백업 및 복구 방법:

따라서 사용자가 장치에서 인증을 완료하고 복구를 트리거하지 않는 한, OneKey를 포함한 그 어떤 단일 당사자도 이를 사용 가능한 평문 키로 일방적으로 재구성할 수 없습니다.

이 섹션에서는 Google 또는 Apple을 사용하여 새 키리스 지갑을 생성할 때 클라이언트 측(사용자 장치)과 서버 측에서 발생하는 상황을 설명합니다. 또한 "백업" 및 "복구" 프로세스가 사용자 친화적이면서도 단일 당사자가 전체 개인 키에 액세스할 수 없도록 보장하는 이유를 명확히 합니다.

온보딩 프로세스 중에 키리스 지갑을 생성할 때 다음을 수행할 수 있습니다:

중요 참고 사항: 키리스 지갑과 전통적인 시드 구문 지갑은 서로 다른 독립적인 시스템입니다. 현재 "기존 시드 구문 지갑"을 키리스 지갑으로 마이그레이션하는 것은 지원되지 않으며, 두 지갑은 병렬로 존재합니다.

사용자가 Google 또는 Apple 계정을 사용하여 지갑을 생성할 때 발생하는 기술적 프로세스를 살펴보겠습니다.

2단계 — 대칭 키를 두 개의 "2-of-2" 공유로 분할

장치로 돌아와서 대칭 키는 Shamir의 비밀 공유(SSS)와 2-of-2 임계값을 사용하여 두 개의 공유로 분할됩니다:

2-of-2 임계값에서는 단일 공유만으로는 대칭 키를 재구성하기에 충분하지 않습니다. OneKey가 "시드 암호문"과 "백엔드 공유"를 모두 보유하더라도 지갑을 일방적으로 복구하거나 트랜잭션 서명을 시작할 수 없습니다.

OneKey 키리스 지갑의 디자인 목표는 단일 당사자에게 "제어권"을 중앙 집중화하지 않으면서 진입 장벽을 최소화하는 것입니다. 지갑 복구는 가장 민감한 작업 중 하나이므로, 프로토콜의 보안 경계와 위협 모델을 설계의 핵심에 두었습니다. 이를 통해 사용 편의성 향상이 보안을 희생하지 않도록 보장합니다.

당사의 아키텍처는 다음 두 가지 중요한 목표를 충족하도록 설계되었습니다:

장치에서 사용 가능한 시드 구문 또는 키 자료를 복원하려면 다음 모든 요소가 동시에 존재해야 합니다:

이 아키텍처는 다음과 같은 몇 가지 직접적인 결론으로 이어집니다:

ID 및 액세스 제어와 관련하여 키리스 지갑은 "귀하가 누구인지(계정 ID)"와 "귀하가 무엇을 아는지(PIN)"를 분리합니다:

암호화 및 키 분할 수준에서 키리스 지갑은 "암호문은 저장될 수 있지만 키는 절대 중앙 집중화되어서는 안 된다"는 원칙을 준수합니다:

OneKey 키리스 지갑에 대해 이해해야 할 중요한 점은 복구는 두 가지 조건이 동시에 충족되는 것에 의존한다는 것입니다. 즉, 해당 Google 또는 Apple 계정에 로그인할 수 있어야 하며 PIN을 기억해야 합니다.

전통적인 Web2 "비밀번호 찾기" 흐름과 달리, OneKey는 귀하를 위해 PIN을 검색할 수 없으며, 귀하를 대신하여 개인 키 또는 시드 구문을 재구성할 수도 없습니다. 이는 제품 결함이 아니라 보안 경계의 의도적인 부분입니다. 서비스 제공업체가 이러한 요소 중 하나라도 액세스할 수 있다면 "자체 수탁"의 핵심 속성은 근본적으로 손상될 것입니다.

따라서 진정한 "제로 트러스트" 솔루션은 불가피하게 사용자에게 책임의 일부를 요구합니다. 즉, 계정에 대한 액세스 권한을 유지하고 PIN을 기억해야 합니다.

하지만 안전망이 있습니다. 키리스 지갑의 시드 구문은 이미 로그인된 장치에서 사용 가능한 형태로 존재합니다.

PIN을 잊어버렸더라도 지갑이 로그인되어 작동 중인 장치에 대한 액세스 권한이 여전히 있는 경우, 일반적으로 해당 장치에서 PIN을 재설정할 수 있습니다. 이 프로세스는 새로운 백업 구성을 생성하여 향후 장치 간 복구 능력을 유지하도록 보장합니다.

시간 경과에 따라 PIN을 잊어버릴 위험을 완화하기 위해 OneKey는 적절한 간격으로 PIN을 확인하도록 요청할 것입니다.

이러한 확인 중 하나에서 PIN을 기억할 수 없음을 깨닫는다면, 장치에 액세스할 수 있는 동안 즉시 PIN을 재설정하고 백업 구성을 다시 생성/업데이트할 기회를 가져야 합니다.

요약하자면, 다음 조건 중 적어도 하나를 충족하는 한 키리스 지갑 액세스 권한이 유지됩니다:

복구 프로세스는 본질적으로 "계정으로 로그인 + PIN 입력"이므로, 키리스 지갑을 생성한 직후 두 번째 장치에서 복구 연습을 수행할 것을 강력히 권장합니다.

그렇게 함으로써 다음을 확보하게 됩니다:

많은 신규 사용자에게 시드 구문은 업계 표준이지만, 이를 사용하는 것은 직관적이지 않은 경우가 많습니다. 새 장치에 시드 구문을 입력하는 것은 상당한 마찰을 수반하며, 이를 안전하게 보관할 방법이나 위치를 아는 것은 종종 혼란의 원인이 됩니다.

OneKey 키리스 지갑은 다른 균형을 맞추는 것을 목표로 합니다:

익숙한 방법(Google / Apple + PIN)을 사용하여 진입 장벽을 낮춥니다. 동시에, 분산형 키 관리 아키텍처를 통해 OneKey를 포함한 그 어떤 단일 당사자도 사용자의 전체 키를 일방적으로 재구성할 수 없도록 보장합니다. 이는 "사용 편의성"과 "자체 수탁 보안 경계" 사이의 타협점을 달성하며, 일반 대중에게 매우 적합합니다.