라이트닝 월렛 보안 스펙트럼

저자: 잭 로널디

출처: https://vls.tech/posts/lightning-security-spectrum/

간단히 말해서

"비수탁형"이라는 표현은 라이트닝 월렛의 보안 모드를 설명하는 데 적합하지 않습니다. 서명에 인터넷 연결이 필수적이기 때문에, 핵심 질문은 연결된 노드가 해킹당할 경우 어떻게 되는가 입니다. 대부분의 라이트닝 월렛은 연결된 월렛(핫월렛)입니다. 단순히 돈을 쓰는 용도라면 문제가 없지만, 보유 자금이 많아질수록 리스크 급격히 상승. 레벨 3(향상된 환경)은 해킹 가능성을 줄여줍니다. 레벨 4(VLS)는 노드 외부에서 특정 지출 규칙을 적용하여 피해 범위를 제한하므로, 노드가 해킹당하더라도 자금이 유출되지 않습니다. 개발자, 노드 운영자 또는 대량 의 라이트닝 채널 자금을 보유한 서버 운영자라면 이러한 차이는 매우 중요합니다.

(역자 주: 저자의 아이디어는 완벽하게 작동하는 라이트닝 노드를 두 가지 모듈 로 나누는 것입니다. 하나는 네트워킹, 통신 및 라이트닝 채널 관리를 담당하는 "노드"이고, 다른 하나는 채널 상태 전환(수신 또는 지불) 시 서명을 담당하는 "서명자"입니다. 이 두 모듈 서로 다른 라이트닝 지갑 구현에서 통합되거나 분리될 수 있습니다.)

안전 스펙트럼 살펴보기

• 레벨 1: 서명 확인 없음 . 의미 없는 기능이므로 개발하지 마십시오.
• 1단계: 완전 관리형 핫월렛 . 서비스 제공업체가 사용자의 키를 보유합니다.
• 레벨 2: 비수탁형 핫월렛 . 키는 사용자 소유이며, 네트워크 장치 제공업체에 저장될 뿐입니다.
• 3단계: 향상된 노드 . 보안 영역과 하드웨어 서명 모듈(HSM)을 활용하여 더욱 강력한 격리를 제공합니다.
• 레벨 4: 검증된 라이트닝 채널 서명자(VLS) . 지출 조건을 시행하는 격리된 서명자입니다.
• 레벨 5: VLS + 임계값 시그니처 (향후)

유용한 구분

• 레벨 3 : 노드를 침입하기 어렵게 만듭니다.
• 레벨 4 : 노드 침해 위험을 줄입니다(노드는 지출 조건에서 허용되지 않는 행위를 통해 자금을 훔칠 수 없습니다).

지갑 개발자나 서비스 제공업체에 문의하세요.

• 노드가 해킹당할 경우, 서명을 획득하여 자금을 훔칠 수 있을까요?
• 지출 조건 서명은 노드 외부의 별도 모듈 에서 수행됩니까?
• 최악의 경우, 손실 규모는 얼마나 클까요? 출혈을 막을 수 있는 방법은 무엇일까요?
• 지갑의 현재 상태를 확인하세요.

서명 생성기 자체가 손상되면 어떤 조치도 효과가 없습니다. 따라서 우리의 목표는 노드 자체보다 서명 생성기를 더욱 손상시키기 어렵게 만드는 것입니다.

라이트닝 네트워크의 장점과 문제점

당신은 "개인키 없이는 코인을 얻을 수 없다"는 확고한 신념 때문에 신중하게 조사하여 "비수탁형" 라이트닝 지갑을 선택했습니다. 시드 키는 안전하게 보관하면서 개인 키는 직접 관리합니다.

어느 날 아침, 당신의 라이트닝 채널이 닫혀 있고, 당신의 사토시는 알 수 없는 주소로 전송되어 있는 것을 발견합니다. 소프트웨어 로그에는 노드가 모든 작업을 허용했다고 나와 있습니다. 그렇게 순식간에 당신의 비트코인은 사라져 버렸습니다. 라이트닝 지갑이 당신의 의자를 치워버린 것입니다.

라이트닝 네트워크는 즉시 결제를 위해 비트코인의 보안 및 자체 보관 원칙을 유지할 것을 약속했습니다. 그러나 무언가 문제가 발생한 것 같습니다.

"관리되지 않음"은 보안 모델이 아닙니다.

비트코인 기본 계층에서 "비수탁형"은 보안과 명확하게 연결됩니다. 개인 키는 오프그리드 장치(콜드 스토리지)에 저장되며 사용자가 원할 때만 서명됩니다. 하지만 라이트닝 월렛은 이러한 제약을 바꿉니다. 결제, 해시 타임 락드 컨트랙트(HTLC), 채널 업데이트에는 모두 응답 시간 제한이 있으므로 서명 키는 인터넷에 연결되어 있어야 합니다. 즉, 휴대폰, 서비스 제공업체 또는 그 중간 어딘가에 연결되어 있어야 합니다. 라이트닝 월렛에서 "내가 개인 키를 가지고 있다"는 것이 "내 자금이 안전하다"는 것을 의미하는 것은 아닙니다.

• "비수탁형"이라는 용어는 여전히 필수적입니다 . 이는 서비스 제공업체가 임의로 자금을 이체할 수 없다는 것을 의미합니다.
• 하지만 단순히 "관리되지 않는" 것만으로는 충분하지 않습니다 . 서명이 온라인으로 이루어지기 때문에 재해 복구 모드가 필요합니다. 공격자가 라이트닝 노드를 장악했을 경우, 그들이 서명을 획득하고 자금을 훔치는 것을 막을 수 있는 방법은 무엇일까요?

(역자 주: 공격자가 개인 키를 탈취하거나 노드를 제어하지 않고도 자금을 훔칠 수 있는 이유는 라이트닝 채널 자체의 상태 변경에 서명, 즉 노드 신청과 서명자의 승인이 필요하기 때문입니다. 서명자가 신청 내용을 검증하지 않으면, 단순히 노드를 제어하는 ​​것만으로도 피해자의 채널 내 모든 자금을 이체할 수 있습니다.)

중요한 것은 다음과 같습니다.

라이트닝 노드가 탈취당하면 공격자는 다음에 무엇을 할 수 있을까요?

먼저 일반적인 라이트닝 지갑들을 살펴보겠습니다.

라이트닝 월렛 보안 스펙트럼

이 스펙트럼은 간단한 테스트에서 도출되었습니다. 공격자가 피해자의 자금을 훔치는 것이 얼마나 어려운가 ?

스펙트럼을 따라 이동하면서 우리는 단순성을 희생하는 대신 더 작은 공격 노드와 더 강력한 재해 복구 기능을 얻게 됩니다.

서명이 확인되지 않았습니다(잘못된 모드).

작동 방식 : 서명자는 노드와 별개이지만, 노드가 보낸 모든 요청을 독립적으로 보안 검증 없이 승인합니다.

노드가 탈취되면 어떤 일이 발생하나요 ? 노드(또는 노드에 영향을 줄 수 있는 모듈)가 손상되면 서명자가 악의적인 행위를 승인하도록 속일 수 있습니다.

단점 : 표준 핫월렛보다 복잡하고 보안성이 떨어집니다. 공격 경로가 하나가 아닌 두 개(노드와 서명자)가 되기 때문입니다.

예시 : 오늘날 주류 제품들은 이런 방식으로 작동하지 않습니다. 개발자들은 이 점을 명심해야 합니다. 이런 방식으로 제품을 개발하지 마십시오 .

호스팅된 핫월렛

작동 방식 : 서비스 제공업체가 키를 관리하고 사용자를 대신하여 라이트닝 노드를 실행합니다.

노드가 탈취되면 어떻게 될까요 ? 공급업체의 부정행위나 내부자 활동으로 인해 자금이 이체될 수 있습니다.

절충점 : 최상의 사용자 경험, 최소한의 사용자 책임, 최고의 신뢰도 및 기업 책임.

소량 구매 및 초보자 에게 가장 적합합니다 .

사례 연구 : 캐시앱 , 스트라이크 , 리버

비수탁형 핫월렛

작동 방식은 다음과 같습니다 . 사용자가 직접 키를 보유하지만, 해당 키는 라이트닝 노드(지갑)가 실행되는 네트워크 환경(장치)에 저장됩니다.

노드가 탈취되면 어떻게 되나요 ? 노드가 탈취되면 자금이 도난당할 수 있습니다.

절충점 : 자율성이 있지만 보안은 노드의 운영 환경이 얼마나 안전한지에 크게 좌우됩니다.

일상적인 지출 에 가장 적합합니다 .

사례 연구 : Phoenix (ACINQ) , ZEUS , Voltage

온프레미스 vs. 클라우드 : 비수탁형 지갑은 사용자의 기기(온프레미스) 또는 전문 팀이 운영하는 서버(클라우드)에서 실행될 수 있습니다. 클라우드가 반드시 더 안전하거나 더 위험한 것은 아닙니다. 클라우드는 사용자 오류를 줄이고 전문 팀의 운영 효율성을 향상시킬 수 있지만, 원격 공격에 취약해지고 인프라 접근에 대한 리스크 집중될 수 있습니다.

향상된 노드 환경(보안 영역/HSM)

겉보기에는 일반적인 라이트닝 노드 모드와 같지만 , 강화된 환경(보안 인클레이브, HSM, 인증 기반 비밀 키 배포)에서 실행됩니다.

이는 민감한 메모리를 격리하고 키 관리를 강화함으로써 "서버 탈취" 및 "관리자 권한"이 키 추출로 이어지는 것을 어렵게 만든다는 점에서 의미가 있습니다 .

노드 탈취 시 발생하는 상황 : 공격자가 노드에서 악성 로직을 성공적으로 실행하면(예: 소프트웨어 취약점 악용 또는 소프트웨어 업데이트 소스 탈취), 해당 노드는 무단 사용 권한을 획득하게 됩니다. 보안 강화 조치는 탈취 가능성을 줄일 수 있지만, 무차별 대입 공격의 범위를 제한하지는 못합니다.

절충점 : 일반적으로 보안 강화 조치는 매우 비용이 많이 들며, 특수 인프라, 툴체인 및 운영 절차(인증, 개인 키 주입, 통제된 소프트웨어 배포)를 필요로 합니다. 세계 최고 수준의 운영사들조차도 만족스러운 수준에 도달하는 데 수년이 걸렸다고 말합니다.

이 솔루션은 (a) 단기간에 인프라를 변경할 수 없고, (b) 보안 및 운영 예산을 충분히 확보한 대규모 운영자 에게 가장 적합합니다 . 일반적인 핫월렛의 경우 이 솔루션이 적절한 "시작점"이 될 수 있지만, 매우 강력한 보안을 원한다면 최종적인 해결책은 아닙니다.

사례 연구 : LEXE(Intel SGX) , ACINQ: 약 1억 달러 규모의 라이트닝 노드(Nitro Enclaves) 보안 강화 ( 중국어 번역 )

VLS(유효성 검증 기능이 있는 라이트닝 채널 서명자)

절차는 다음과 같습니다 . 서명자는 요청을 검증하고 지출 조건을 확인한 후 서명합니다.

이것이 향상시키는 점 : 실패 방식을 변경합니다. 노드가 해킹당하더라도 지출 조건에서 허용되지 않은 작업을 통해 자금을 훔칠 수 없습니다.

노드가 탈취되면 어떻게 되나요 ? 노드 탈취는 큰 영향을 미치지 않습니다. 서명자가 핵심 보안 경계입니다.

절충점 : 더 강력한 보안을 보장받는 대신 소프트웨어 사전 통합 및 지속적인 유지 관리가 필요합니다.

다음과 같은 경우에 가장 적합합니다 : 특히 클라우드 지갑과 같이 금액 관리에 대한 우려가 있는 경우.

사례 : 블록스트림 그린라이트 , 블록스트림 앱

VLS + 임계값 시그니처(향후)

이는 다음과 같습니다 . 라이트닝 채널 상태 변경 서명을 위해서는 N명의 서명자 중 M명 이상의 승인이 필요합니다(예: 5명 중 3명).

현재 상태 : 아직 라이트닝 노드의 표준 모델은 아니지만, 수요가 있다면 실행 가능한 방향입니다.

절충점 : 가장 강력한 보안을 보장하지만, 가장 복잡하며 (운영 부담이 더 클 수 있음)

다음과 같은 경우에 가장 적합합니다 : 재무부 스타일의 신속 자금 운용 펀드로, 여러 당사자가 통제권을 행사하기 위해 마찰을 극복하는 것이 가치 있는 경우.

사례 연구 : 아직은 아니지만, 사람들의 관심이 높아지고 있습니다.

수요 신호 : 일부 라이트닝 노드 운영자는 라이트닝 채널 서명 프로세스가 내부 기업 재무 관리(예: 다중 사용자 권한)와 호환되기를 원합니다. Flowrate는 최근 VLS 프로젝트에 연락하여 고객 자금 보호를 위해 임계값 권한 사용에 대한 관심을 표명했습니다. 현재 노드에 대한 검토가 진행 중이며, 상용화 준비가 완료된 "라이트닝 채널 다중 서명" 아키텍처는 아직 개발되지 않았습니다.

올바른 보안 수준을 선택하는 방법

라이트닝 월렛의 보안은 두 가지 핵심 요소에 달려 있습니다. 하나는 월렛이 해킹당할 가능성 (누군가가 해킹할 확률)이고, 다른 하나는 해킹에 성공했을 경우 발생할 수 있는 막대한 손실 가능성입니다 .

실용적인 접근 방식은 실제로 고장이 났을 때 얼마나 많은 손실을 감수할 의향이 있는지를 고려하는 것입니다.

소액을 보호할 때는 더 간단한 접근 방식을 사용하십시오. 금액이 증가하거나, 중요해지거나, 사업에 필수적인 금액이 되면, 재난 발생 확률을 줄이는 설계가 아니라 최악의 시나리오에서 손실을 최소화하는 설계를 선택하십시오.

보안은 제품 선택의 문제입니다. 적절한 보안 수준은 보호해야 할 정도, 감수할 수 있는 리스크 수준, 그리고 처리할 수 있는 장애 유형에 따라 달라집니다.

향상된 노드 환경(보안 영역/HSM)

레벨 3은 일반적인 접근 방식입니다. 노드의 운영 환경이 리스크 하다면 이를 강화해야 합니다. 강력한 격리, 엄격한 접근 권한 설정, 하드웨어 기반 보호조치"서버 침해"가 "키 도난"으로 이어질 가능성을 줄일 수 있습니다.

이 접근 방식은 진입 장벽을 상당히 높여 보안 및 구축 경험이 풍부한 운영자에게 특히 적합합니다. 그러나 여전히 네트워크 시스템이므로 최악의 시나리오는 변하지 않습니다. 즉, 손상된 노드가 어떤 서명을 하게 될까요?

레벨 3의 실제 모습은 다음과 같습니다.

실제 사례 연구 : ACINQ 팀의 블로그 게시물 " 1억 달러 규모 라이트닝 노드 보안 "( https://acinq.co/blog/securing-a-100M-lightning-node) (중국어 번역본은 https://www.btcstudy.org/2023/08/21/securing-a-100M-lightning-node/에서 확인 가능)에서는 그들의 경험을 설명합니다. 그들은 AWS Nitro 보안 영역 (격리 + 인증) 내에서 자체 노드를 운영하고 Ledger 하드웨어 서명기를 사용하여 소프트웨어 배포와 같은 중요한 작업을 수동으로 검증했습니다. 이를 통해 운영자 리스크 과 서버 접근 리스크 크게 줄였습니다.

ACINQ는 이것이 "궁극적인" 보안은 아니라는 점도 강조합니다.

• 보안 영역이 있다고 해서 종속성이 신뢰할 수 있는 것은 아닙니다 . 애플리케이션은 여전히 ​​올바른 서버와 통신하고 있는지 확인해야 합니다.
• 노드가 여전히 온라인 상태입니다 . 심각한 노드 소프트웨어 취약점으로 인해 서명 인증 악용 사례가 발생할 수 있습니다.
• 이는 운영에 크게 의존합니다 . 매우 복잡한 보안 설계로 인해 실질적인 운영 부담이 발생했습니다.

실제 발생 사례 및 공개된 취약점

라이트닝 네트워크와 관련된 몇 가지 실제 사건(그중 하나는 도난을 허용하는 취약점을 드러냈습니다)은 "라이트닝 네트워크 암호화를 해킹"하지 않고도 재정적 손실이 발생할 수 있음을 보여줍니다. 이러한 사건들은 모두 공통적인 특징을 가지고 있습니다. 공격자가 서명 내용에 영향을 미칠 수 있다면 자금을 훔칠 수 있다는 것입니다.

LNBank(BTCPay 서버 플러그인): 동시 출금 경쟁으로 약 4.07 BTC가 소진되었습니다.

LNBank의 잔액 처리 과정에서 발생하는 경쟁 조건으로 인해 공격자는 데이터베이스에 실제 차감 내역이 반영되기 전에 여러 건의 동시 인출을 시도할 수 있으며, 이는 사실상 라이트닝 지갑에서 자금을 인출하여 잔액을 모두 소진시키는 결과를 초래할 수 있습니다.

• 스펙트럼 위치 : 통신사업자용 레벨 2. 참고: LNBank 자체는 사용자용 호스팅 계층(레벨 1)입니다.
• 영향 : 407,361,805 사토시(약 4.07 BTC)가 전송된 것으로 보고되었습니다.
• 문제의 근본 원인 : 동시 실행 환경에서 잔액 확인 시 오래된 상태 데이터가 사용될 수 있습니다.
• 이 문제의 중요성은 다음과 같습니다 . "노드가 무엇이든 필요로 한다"는 것은 개인 키를 추출하지 않더라도 위험할 수 있습니다.

출처 : 피해자 진술서 , 피고인 평가

자세한 내용 :

• 공격 방식 : 공격자는 대량의 동시 출금/지불 요청을 제출하여 소프트웨어 상태가 "요청 수락 중"과 "데이터베이스 업데이트 중" 사이를 끊임없이 오가도록 만듭니다.
• 관찰된 상황 : 라이트닝 네트워크에서 급격한 자금 유출이 발생하여 잔액 소진되었습니다.
• 대응 : 문제가 드러난 후 신속하게 수정 패치가 배포되었으며, 공개 보고서도 발표되었습니다.

LNbits: 악의적인 라우팅 수수료로 0.1 BTC 이상 빼돌려짐

공개된 보고서(LNbits 코드베이스의 문제점으로 제기됨)에 따르면, 공격자들이 과도한 수수료를 부과하는 노드를 통해 출금을 강제함으로써 LNbits 기반 지갑의 잔액을 모두 빼돌렸다고 합니다. 단일 거래 수수료에 대한 엄격한 제한이 없었다면, 라우팅 비용 때문에 지갑이 완전히 비워졌을 것입니다.

• 스펙트럼 위치 : 레벨 1과 레벨 2 사이 (핫월렛 로직 및 수수료 비용 제한이 포함되며, LNbits 배포 방식에 따라 달라집니다).
• 영향 : 보고서에 따르면 "총 0.1 BTC 이상의 손실"이 발생했습니다.
• 문제의 근본 원인은 단일 거래 수수료 상한선이 없다는 점과 "결제 금액 + 수수료" 시스템에 대한 감독이 부족하다는 점(또는 허점이 있을 수 있음)입니다.
• 이 문제의 중요성 : 라이트닝 네트워크에서 거래 수수료는 곧 가치입니다. 거래 수수료 제한은 보안 경계의 일부이기도 합니다.

출처 : LNbits 발행

자세한 내용 :

• 메커니즘 : 공격자는 결제 경로 선택에 영향을 미쳐, 유일하게 실행 가능한 경로가 공격자가 제어하는 ​​노드를 포함하게 되었고, 이 노드는 비싼 라우팅 수수료를 부과했습니다.
• 관찰된 동작 : 결제는 성공했지만, 지갑 잔액 의 상당 부분이 송금 수수료 지불에 사용되었습니다.
• 답변 : 해당 보고서는 공개되었으며, 이후 (다양한 해결 및 배포 방법을 통해) 문제가 종결되었습니다.

LND "대체 거래 중단"(도난을 허용하는 공개된 취약점)

LND 취약점("대체 트랜잭션 지연")에 대한 공개 내용은 채널을 강제로 닫아 피해 노드가 미처리 HTLC를 정리하고 대체 트랜잭션을 전송하도록 유도하는 시나리오를 설명하며, 업그레이드 방법도 권장합니다.

• 스펙트럼 위치 : 레벨 2와 레벨 3 사이(핫 노드, 인프라 강화로도 이 리스크 제거할 수 없음).
• 영향 : 절도를 허용하는 취약점 (공개된 정보에 항상 확인된 손실이 포함되는 것은 아닙니다).
• 근본 원인 : 자금 정산이라는 드문 상황에서 발생한 구현 단계의 오류.
• 문제의 중요성 : 강력한 인프라 제어 시스템을 갖추더라도 소프트웨어 버그는 여전히 손실로 이어질 수 있습니다.

출처 : 정보공개 보고서

자세한 내용 :

• 영향을 받는 사용자 : 해당 LND 버전을 사용하여 노드를 실행하는 사용자.
• 중요성 : 강제 종료 및 온체인 스윕을 둘러싼 적대적인 환경.
• 해결 방법 : 수정된 버전으로 업그레이드하십시오.

이러한 공격은 드문 일이 아닙니다. 흔히 발생하는 소프트웨어 및 운영상의 결함이, 모든 작업을 승인할 권한을 가진 핫월렛이 손상된 노드로 인해 심각한 사고로 확대되는 것입니다.

VLS: 공격 인터페이스가 더 작은 독립형 서명 도구

VLS는 기존 아키텍처를 단순히 강화하는 것이 아니라 아키텍처 자체를 변경함으로써 하이재킹에 대응하는 것을 목표로 합니다.

그것은 세 가지 일을 동시에 수행했습니다.

1. 격리 : 개인 키와 서명 결정 권한이 노드에서 분리되어 전용 서명자에게 저장됩니다.
2. 축소 : 서명자는 노드보다 훨씬 적은 역할을 수행합니다. 의존성이 적을수록 공격 경로도 줄어듭니다.
3. 강제 서명 : 서명자는 서명하기 전에 일련의 지출 조건에 따라 요청을 검증하므로, 탈취된 노드가 악의적인 행위를 수행할 수 없습니다.

그 약속은 다음과 같습니다:

노드가 손상되더라도 공격자는 지출 조건을 위반하는 행위에 대한 서명을 얻을 수 없습니다.

지출 조항의 예시:

• 해당 채널이 폐쇄되면 허용된 주소로만 자금을 보낼 수 있습니다.
• 총 거래 수수료 및 수수료율 한도
• 지불 금액 한도 및 지불 빈도 한도
• "비상 버튼"(문제가 발생한 경우 서명 기능을 중지하기 위한 버튼)
• 그리고 더 많은 것들

VLS 작동 모습

실질적인 증거: 그린라이트

Greenlight는 클라우드 노드의 편리함과 VLS 기반 서명 검증 도구가 결합된 레벨 4 모드의 실제 사례입니다.

이는 흔히 묻는 질문에 대한 답변입니다.

"격리와 검증은 분명 좋은 것이지만, 그것들이 사용자 경험을 망치지 않을 것이라는 것을 어떻게 증명할 수 있을까요?"

Greenlight는 "서버 핫 프라이빗 키"로 인한 보안 리스크 높이지 않고도 클라우드 노드의 편리함을 누릴 수 있음을 입증했습니다.

사용 중인 기기를 확인하는 방법

대부분의 라이트닝 월렛 제품은 수탁형인지 비수탁형인지 여부를 알려줍니다. 하지만 특정 모듈 손상될 경우 어떤 일이 발생하는지 명확하게 알려주는 제품은 거의 없습니다. 아래 체크리스트를 통해 정확한 답변을 확인해 보세요.

질문 1: "노드 환경이 공격받으면 공격자가 제 돈을 훔칠 수 있나요?"

강력한 답변 : "서명자가 노드 외부에서 지출 조건을 적용하기 때문에 노드 하이재킹 문제도 해결할 수 있습니다."

답변할 수 없음 : "지갑은 사용자의 소유이며, 개인 지갑이지 수탁형 지갑이 아닙니다."

솔직히 말씀드리면 , "네. 노드가 해킹당하면 자금이 유출될 수 있습니다." (레벨 2 또는 레벨 3 공격으로 간주하십시오.)

질문 2: "서명 권한은 어디에 있습니까?"

"앱/노드 프로세스 내에서"라는 말은 전체 런타임 환경을 신뢰해야 한다는 의미입니다.
"별도의 서명자가 있으면 지출 조항을 강제하게 되는데, 이는 다른 보안 경계를 의미합니다."

질문 3: "노드 외부 에서 어떤 특정 지출 조항이 시행되었습니까?"

• 채널이 폐쇄되면 허용된 주소로만 출금이 가능합니다.
• 지불 금액 한도 및 지불 빈도 한도
• 수수료 제한 및 기본 보안 설정
• 서명을 중지하는 비상 잠금 또는 "비상 모드"입니다.

"보안 조치가 마련되어 있습니다."라고 말하지만 구체적인 내용을 밝히지 않는 것은 대개 "그냥 날 믿어."라는 의미입니다.

심층 탐구: 더 많은 질문

최악의 시나리오 분석, 관찰 가능성, 내부자 리스크 및 복구 계획.

질문 4: "문제가 발생할 경우, 제가 입게 될 최악의 손실 시나리오는 무엇입니까?"

유능한 팀이라면 출혈을 멈출 수 있는 조치를 자세히 설명하는 긴 문단으로 답변해 줄 것입니다.

만약 그들이 최악의 시나리오를 설명하지 못한다면, 그들의 대답은 "돈을 모두 잃는다"라고 가정하십시오.

질문 5: "만약 공격자가 내 돈을 훔치려고 시도한다면, 로그에서 무엇을 볼 수 있을까요?"

명확한 감사 기록을 통해 거부된 시도를 기록하고 지출 조건 위반에 대해 경고했습니다.

"모르겠습니다" 또는 "상황에 따라 다릅니다"라는 답변은 관측 가능성이 낮다는 것을 의미합니다.

질문 6: "횡령을 예방하는 방법은 무엇입니까?"

책임 분리, 통제된 배포 프로세스, 관리자 권한 제한, 위험한 작업에 대한 수동 확인 요구 사항.

관리자 키로 무엇이든 할 수 있다면, 그건 보안 모드라고 할 수 없죠!

질문 7: "납치 사건이 발생할 경우 어떻게 복구할 수 있습니까?"

여기에는 상세한 사고 대응 계획, 비상 봉쇄 절차, 접근 차단 전략 및 열쇠 순환 또는 재설정 계획이 포함됩니다.

서면 계획이 없으면 당신은 사실상 실험 대상이 되는 것입니다.

만약 "이것은 비수탁형 지갑입니다"라는 말만 들었다면, 사실상 답을 얻은 것이 아닙니다.

개발자들이 조치를 취합니다

이 어려운 질문에 답할 때 "비보호"라는 용어를 핑계로 삼지 마십시오. 명확한 안전장치를 제시해 주십시오.

1. 최악의 경우를 가정한 차량 탈취 패턴을 정의하고 (글로 적어주세요).
2. 승인되지 않은 채널 폐쇄 및 지출 조건 위반 행위를 방지하기 위해 취할 수 있는 조치를 설명하십시오.
3. 복구, 감사 및 운영 안전 조치에 대한 문서를 작성하십시오.
4. 클라우드 서비스 경험을 원하신다면, 서명 검증 모드를 선택하세요. 그래야 노드가 해킹당하더라도 자금이 지정된 지출 범위를 벗어나 이체되지 않습니다.

보안은 아키텍처 설계에서 선택 사항이며, 해야 할 일 목록이 아닙니다.

현재 상황: 당신의 지갑은 얼마나 안전한가요?

다음은 주요 라이트닝 지갑 및 라이트닝 네트워크 서비스 제공업체의 보안 수준을 분석한 내용입니다.

참고 : 본 분류는 2026년 2월 11일 기준 공개된 정보를 바탕으로 합니다. 공급업체는 언제든지 자체 상태를 확인하고 업데이트할 수 있습니다.

(위에)