XRPL Docs (Korean)
  • XRPL Docs(Kor)
  • Introduction
    • XRP Ledger란?
    • XRP란?
    • Crypto Wallets
    • Transactions and Requests
    • Software Ecosystem
  • Use Cases
    • 결제(Payments)
      • P2P 결제(Peer-to-Peer Payments)
      • 예금 제한(Restricting Deposits)
      • 스마트 컨트랙트(Smart Contracts)
    • 토큰화(Tokenization)
      • 스테이블코인 발행인(Stablecoin Issuer)
      • NFT 마켓플레이스 개요(NFT Marketplace Overview)
    • 탈중앙화 금융(Decentralized Finance)
      • 알고리즘 트레이딩(Algorithmic Trading)
      • 거래소에 XRP 상장하기((List XRP as an Exchange)
  • Concepts
    • 소개
      • 컨센서스 소개
      • XRP
      • 소프트웨어 생태계
    • XRP Ledger 서버
      • rippled 서버 모드(rippled Server Modes)
      • 클러스터링(Clustering)
      • Ledger 역사
      • 피어 프로토콜(Peer Protocol)
      • 트랜잭션 검열 감지(Transaction Censorship Detection)
      • 병렬 네트워크(Parallel Networks)
      • 수정안(Amendments)
        • XRP Ledger에 코드를 기여하는 방법
        • 알려진 수정안
      • 클리오 서버(The Clio Server)
    • 컨센서스 네트워크(Consensus Protocol)
      • 컨센서스 구조(Consensus Structure)
      • 컨센서스 원칙과 규칙(Consensus Principles and Rules)
      • 공격과 실패 모드에 대한 컨센서스 보호(Consensus Protections Against Attacks and Failure Modes)
      • 불변성 체크
      • 부정 UNL
      • 트랜잭션 취소 정보
      • 트랜잭션 변조 가능성
      • 수수료 투표
      • 컨센서스 연구
    • Ledgers
      • Ledger 구조(Ledger Structure)
      • 개방형, 폐쇄형, 검증형 Ledgers(Open, Closed, and Validated Ledgers)
      • Ledger 마감 시간(Ledger Close Times)
    • 트랜잭션(Transactions)
      • 수수료(Fees)
      • 신뢰할 수 있는 트랜잭션 제출(Reliable Transaction Submission)
      • 보안 서명(Secure Signing)
      • 출발, 데스티네이션 태그(Source and Destination Tags)
      • 트랜잭션 비용(Transaction Cost)
      • 트랜잭션 대기열(Transaction Queue)
      • 결과의 불변성(Finality of Results)
        • 트랜잭션 결과 조회(Look Up Transaction Results)
        • Transaction Malleability
    • 결제 유형
      • XRP 직접 결제
      • 교차 화폐 결제
      • 수표
      • 에스크로
      • 부분 결제
      • 결제 채널
    • 토큰(Tokens)
      • Non-Fungible Tokens
        • NFT 정보 저장소(NFT Payload Storage)
        • XRP Ledger에서 NFT 토큰 거래(Trading NFTokens on the XRP Ledger)
        • NFT Reserve Requirements
        • 일괄 발행(Batch minting)
        • 다른 계정에게 NFT 발행 권한 부여(Authorizing Another Account to Mint Your NFTs)
        • NFT 경매 진행하기(Running an NFT Auction)
        • NFT를 컬렉션으로 발행하기(Minting NFTs into Collections)
        • NFT의 고정 공급 보장하기(Guaranteeing a Fixed Supply of NFTs)
        • NFT 관련 API(NFT APIs)
      • 신뢰선과 발급(Trust Lines and Issuing)
      • 승인된 신뢰선(Authorized Trust Lines)
      • 토큰 환수(Clawing Back Tokens)
      • Freezing Tokens(토큰 동결)
        • 동결에 대한 일반적인 오해(Common Misunderstandings about Freezes )
      • Rippling
      • 이체 수수료(Transfer Fees)
      • 경로(Paths)
      • Demurrage(과잉보유비용)
      • 탈중앙화 거래소(Decentralized Exchange)
        • 제안(Offers)
        • Auto-Bridging
        • Tick Size
        • AMM(Automated Market Makers)
    • 계정
      • 다중 서명
      • 티켓
      • 계정 유형
      • 계정 삭제
      • 준비금(Reserves)
      • 주소(Addresses)
      • 암호화 키(Cryptographic Keys)
      • 입금 승인(Deposit Authorization)
  • Tutorials
    • 퍼블릭 서버(Public Servers)
    • Python
      • Python으로 시작하기(Get Started Using Python)
      • python 모듈형 튜토리얼(Modular Tutorials in Python)
        • python을 이용한 Send Payments(Send Payments Using Python)
          • 계정 생성 및 XRP 전송(Create Accounts and Send XRP Using Python)
          • 신뢰 생성 및 Currency 전송 (Create Trust Line and Send Currency Using Python)
          • 시간 보류 에스크로 생성(Create Time-based Escrows Using Python)
        • python을 이용한 NFTs(NFTs Using Python)
          • NFTs 발행과 소각(Mint and Burn NFTs Using Python)
          • NFTs 전송 (Transfer NFTs Using Python)
          • NFT 판매 중개 (Broker an NFT Sale Using Python)
          • 공인 발행인 지정 (Assign an Authorized Minter Using Python)
          • NFTs 일괄 발행 (Batch Mint NFTs Using Python)
        • Python에서 데스크톱 지갑 구축(Build a Desktop Wallet in Python)
    • JavaScript
      • JavaScript로 시작하기(Get Started Using JavaScript)
      • JavaScript 모듈형 튜토리얼(Modular Tutorials in JavaScript)
        • JavaScript를 이용한 Send Payments(Send Payments Using JavaScript)
          • JavaScript를 이용한 계정 생성 및 XRP 전송(Create Accounts and Send XRP Using JavaScript)
          • JavaScript를 이용한 신뢰선 생성 및 화폐 전송(Create Trust Line and Send Currency Using JavaScript)
          • 시간 기반 에스크로 생성하기(Create Time-based Escrows Using JavaScript)
          • 조건부 에스크로 생성하기(Create Conditional Escrows Using JavaScript)
        • JavaScript를 이용한 NFTs(NFTs Using JavaScript)
          • JavaScript를 이용한 NFTs 발행 및 소각(Mint and Burn NFTs Using JavaScript)
          • JavaScript를 이용한 NFTs 전송(Transfer NFTs Using JavaScript)
          • JavaScript를 이용한 NFT 판매 중개(Broker an NFT Sale Using JavaScript)
          • JavaScript를 이용한 공인 발행인 지정(Assign an Authorized Minter Using JavaScript)
          • JavaScript를 이용한 NFTs 일괄 발행(Batch Mint NFTs Using JavaScript)
      • JavaScript를 이용한 브라우저 지갑 개발(Build a Browser Wallet in JavaScript)
      • JavaScript를 이용한 데스크탑 지갑 개발(Build a Desktop Wallet in JavaScript)
    • Java
      • Java로 시작하기(Get Started Using Java)
    • HTTP / Websocket APIs
      • HTTP/WebSocket API 사용 시작하기(Get Started Using HTTP / WebSocket APIs)
      • WebSocket으로 수신 결제 모니터링(Monitor Incoming Payments with WebSocket)
    • Tasks
      • 계정 설정 관리(Manage Account Settings)
        • 일반 키 쌍 할당
        • 일반 키 쌍 변경 또는 제거
        • 마스터 키 쌍 비활성화
        • 다중 서명 설정
        • 다중 서명 트랜잭션 전송
        • 데스티네이션 태그 필요
        • 오프라인 계정 설정 튜토리얼
        • 티켓 사용(Use Tickets)
      • XRP 보내기(Send XRP)
      • 특수 결제 유형 사용(Use Specialized Payment Types)
        • 에스크로 사용(Use escrow)
          • 시간 보류 에스크로 보내기(Send a Time-Held Escrow)
          • 조건부 보류 에스크로 보내기(Send a Conditionally-Held Escrow)
          • 만료된 에스크로 취소(Cancel an Expired Escrow)
          • 에스크로 조회(Look up Escrows)
          • 에스크로를 스마트 컨트랙트로 사용(Use an Escrow as a Smart Contract)
        • 결제 채널 사용(Use Payment Channels)
          • 결제 채널을 열어 거래소 간 네트워크 활성화(Open a Payment Channel to Enable an Inter-Exchange Network)
        • 수표 사용(Use Checks)
          • 수표 전송(Send a Check)
          • 정확한 금액의 수표 현금화(Cash a Check for an Exact Amount)
          • 유연한 금액의 수표 현금화(Cash a Check for a Flexible Amount)
          • 수표 취소(Cancel a Check)
          • 발신자별 수표 조회(Look Up Checks by Sender)
          • 수취인별 수표 조회(Look Up Checks by Recipient)
      • 토큰 사용(Use Tokens)
        • 대체가능한 토큰 발행(Issue a Fungible Token)
        • 탈중앙화 거래소에서 거래(Trade in the Decentralized Exchange)
        • 동결 금지 활성화
        • 글로벌 동결 시행
        • 신뢰선 동결하기
    • Apps 구축
      • JS에서 데스크톱 지갑 구축
      • JS에서 브라우저 지갑 구축
    • XRP Ledger 비즈니스
      • XRP 차트에 거래소 등록하기
      • 스테이블코인 발행자 되기
    • rippled 서버 관리
      • rippled 설치
        • 시스템 요구 사항
        • CentOS/Red Hat에 yum으로 설치하기
        • 우분투 또는 데비안 리눅스에 설치
        • 리눅스에서 자동 업데이트
        • CentOS/Red Hat에서 수동 업데이트
        • 우분투 또는 데비안에서 수동 업데이트
        • 리포팅 모드에서 rippled 빌드 및 실행
        • 용량 계획
        • rippled v1.3.x 마이그레이션 지침
      • rippled 구성
        • rippled를 검증인으로 실행하기
        • rippled를 스톡 서버로 실행
        • 수정안 투표 구성
        • 수정안 테스트
        • StatsD 구성
        • rippled를 병렬 네트워크에 연결하기
        • 온라인 삭제 구성
        • 권고 삭제 구성
        • 히스토리 샤딩 구성
        • 전체 히스토리 구성
        • gRPC 구성
        • 공개 서명 사용
      • 피어링 구성
        • 클러스터 rippled 서버
        • 비공개 서버 구성
        • 피어 크롤러 구성
        • 링크 압축 사용
        • 피어링을 위한 포트 포워드
        • 특정 피어에 수동으로 연결
        • 최대 피어 수 설정
        • 피어 예약 사용
      • stand-alone 모드에서 rippled 기능 테스트하기
        • stand-alone 모드에서 새 제네시스 ledger 시작하기
        • stand-alone 모드에서 저장된 ledger 불러오기
        • stand-alone 모드에서 ledger 진행하기
      • 문제 해결
        • rippled 문제 진단하기
        • 상태 확인 개입
        • 로그 메시지 이해
        • rippled 서버가 동기화되지 않음
        • rippled 서버가 수정이 차단됨
        • rippled 서버가 시작되지 않음
        • SQLite 트랜잭션 데이터베이스 페이지 크기 문제 해결
    • 클리오 서버 관리
      • 우분투 리눅스에 클리오 설치
  • References
    • XRP Ledger 프로토콜 참조(XRP Ledger Protocol Reference)
      • 기본 데이터 유형(Basic Data Types)
        • base58 인코딩(base58 Encodings)
        • 화폐 형식(Currency Formats)
        • NFToken
      • Ledger 데이터 형식(Ledger Data Formats)
        • Ledger 헤더(Ledger Header)
        • Ledger 객체 IDs
        • Ledger 객체 유형
          • AccountRoot
          • Amendments
          • AMM(experimental - 수정중)
          • Check
          • DepositPreauth
          • DirectoryNode
          • Escrow
          • FeeSettings
          • LedgerHashes
          • NegativeUNL
          • NFTokenOffer
          • NFTokenPage
          • Offer
          • PayChannel
          • RippleState
          • SignerList
          • Ticket
      • 트랜잭션 참조(Transaction Reference)
        • 트랜잭션 공통 필드(Transaction Common Fields)
        • 트랜잭션 유형(Transaction Types)
          • AccountSet
          • AccountDelete
          • AMMBid
          • AMMCreate
          • AMMDelete
          • AMMDeposit
          • CheckCancel
          • CheckCash
          • CheckCreate
          • DepositPreauth
          • EscrowCancel
          • EscrowCreate
          • EscrowFinish
          • NFTokenAcceptOffer
          • NFTokenBurn
          • NFTokenCancelOffer
          • NFTokenCreateOffer
          • NFTokenMint
          • OfferCancel
          • OfferCreate
          • Payment
          • PaymentChannelClaim
          • PaymentChannelCreate
          • PaymentChannelFund
          • SetRegularKey
          • SignerListSet
          • TicketCreate
          • TrustSet
        • Pseudo-Transactions
          • EnableAmendment
          • SetFee
          • UNLModify
        • 트랜잭션 결과(Transaction Results)
          • tec Codes
          • tef Codes
          • tel Codes
          • tem Codes
          • ter Codes
          • tes Success
        • 트랜잭션 메타데이터(Transaction Metadata)
      • Binary Format
    • 클라이언트 라이브러리
      • JavaScript / TypeScript 클라이언트 라이브러
        • ripple-lib 1.x에서 xrpl.js 2.x로의 마이그레이션 가이드
      • Python 클라이언트 라이브러리
      • Java 클라이언트 라이브러리
      • Ruby 클라이언트 라이브러리
    • HTTP / WebSocket APIs
      • API 규칙
        • 요청 형식
        • 응답 형식
        • 오류 형식
        • 마커 및 페이지네이션
        • 속도 제한
        • rippled 서버 상태
      • 공개 API 메소드
        • 계정 메소드
          • account_channels
          • account_currencies
          • account_info
          • account_lines
          • account_nfts
          • account_objects
          • account_offers
          • account_tx
          • gateway_balances
          • noripple_check
        • Ledger 메소드
          • ledger
          • ledger_closed
          • ledger_current
          • ledger_data
          • ledger_entry
        • 트랜잭션 메소드
          • submit
          • submit_multisigned
          • transaction_entry
          • tx
          • tx_history
        • 경로와 오더북 메소드
          • book_offers
          • deposit_authorized
          • nft_buy_offers
          • nft_sell_offers
          • path_find
          • ripple_path_find
        • 결제 채널 메소드
          • channel_authorize
          • channel_verify
        • 구독 메소드
          • 구독
          • 구독 취소
        • Server Info 메소드
          • fee
          • manifest
          • server_info (rippled)
          • server_state
        • 클리오 서버
          • server_info
          • ledger
          • nft_history
          • nft_info
        • 유틸리티 메소드
          • json
          • ping
          • random
      • 관리자 API 메소드
        • 키 생성 방법
          • validation_create
          • wallet_propose
        • 로깅 및 데이터 관리 메소드
          • can_delete
          • crawl_shards
          • download_shard
          • ledger_cleaner
          • ledger_request
          • log_level
          • logrotate
          • node_to_shard
        • 서버 컨트롤 메소드
          • ledger_accept
          • stop
          • validation_seed
        • 서명 메소드
          • sign
          • sign_for
        • 피어 관리 메소드
          • connect
          • peer_reservations_add
          • peer_reservations_del
          • peer_reservations_list
          • peers
        • 상태 및 디버깅 메소드
          • consensus_info
          • feature
          • fetch_info
          • get_counts
          • print
          • validator_info
          • validators
        • rippled 커맨드라인 사용 참조
        • 피어 포트 메소드
          • 상태 확인
          • 피어 크롤러
          • 유효성 검증인 목록 메소드
    • xrp-ledger.toml File
  • Infrastructure
    • 커맨드 라인 사용법(Commandline Usage)
    • Install rippled
      • System Requirements
      • Install on CentOS/RedHat with yum
      • Install on Ubuntu or Debian Linux
      • Update Automatically on Linux
      • Update Manually on CentOS/Red Hat
      • Update Manually on Ubuntu or Debian
      • Build and Run rippled in Reporting Mode
      • Capacity Planning
    • Configure rippled
      • Server Modes
        • Run rippled as a Validator
        • Run rippled as a Stock Server
      • Data Retention
        • Configure Full History
        • 온라인 삭제(Online Deletion)
        • Configure Online Deletion
        • Configure Advisory Deletion
        • 히스토리 샤딩(History Sharding)
        • Configure History Sharding
      • Configure Amendment Voting
      • Test Amendments
      • Configure StatsD
      • Connect Your rippled to a Parallel Network
      • Configure gRPC
      • Enable Public Signing
    • Peering
      • Cluster rippled Servers
      • Configure a Private Server
      • Configure the Peer Crawler
      • Enable Link Compression
      • Forward Ports for Peering
      • Manually Connect to a Specific Peer
      • Set Maximum Number of Peers
      • Use a Peer Reservation
    • Testing and Auditing
      • Start a New Genesis Ledger in Stand-Alone Mode
      • Load a Saved Ledger in Stand-Alone Mode
      • Advance the Ledger in Stand-Alone Mode
    • Troubleshooting
      • Diagnosing Problems with rippled
      • Health Check Interventions
      • Understanding Log Messages
      • rippled Server Doesn't Sync
      • rippled Server is Amendment Blocked
      • rippled Server Won't Start
    • Install Clio on Ubuntu Linux
    • Run a Private Network with Docker
Powered by GitBook
On this page
  • 배경
  • 대체 secp256k1 서명
  • 다중 서명과의 변조 가능성
  • 다중 서명의 변조 가능성에 대한 완화책
  • 트랜잭션 변조를 통한 악용
  • 악용 시나리오 단계
  1. Concepts
  2. 컨센서스 네트워크(Consensus Protocol)

트랜잭션 변조 가능성

Previous트랜잭션 취소 정보Next수수료 투표

Last updated 1 year ago

트랜잭션이 서명된 후에는 해당 트랜잭션의 키 없이 어떤 방식으로든 변경될 수 있다면 해당 트랜잭션은 "변조 가능"하다고 합니다. XRP Ledger에서는 서명된 트랜잭션의 기능이 변경되지 않습니다. 그러나 특정 상황에서 제3자가 트랜잭션의 서명 및 식별 해시를 변경할 수 있습니다.

약점이 있는 소프트웨어가 변조 가능한 트랜잭션을 제출하고 해당 트랜잭션이 원래의 해시 아래에서만 실행될 수 있다고 가정한다면, 시스템은 트랜잭션을 추적하지 못할 수 있습니다. 최악의 경우, 악의적인 사용자는 이를 악용하여 취약한 시스템으로부터 자금을 도난할 수 있습니다.

XRP Ledger의 메인넷에서는 다중 서명 트랜잭션이 변조 가능할 수 있습니다. 이는 필요한 서명보다 많은 서명이 있는 경우나 권한이 있는 서명자가 필요 이상의 서명을 제공하는 경우에 해당됩니다. 우수한 운영 보안은 이러한 문제에 대해 보호해 줄 수 있습니다. 지침은 문서에서 확인할 수 있습니다.

2014년 이전까지는 기본 서명 알고리즘인 secp256k1 곡선을 사용하는 ECDSA로 인해 단일 서명 트랜잭션도 변조 가능할 수 있었습니다. 호환성을 위해 이 2020년 7월 3일에 활성화될 때까지 변조 가능한 단일 서명 트랜잭션을 생성하고 제출할 수 있었습니다. (된 트랜잭션은 이러한 문제에 대해 항상 취약하지 않았습니다.)

배경

XRP Ledger에서 트랜잭션이 실행되기 위해서는 다음과 같은 조건을 충족해야 합니다:

  • 서명을 제외한 가 서명되어야 합니다.

  • 트랜잭션에 사용된 키 쌍은 해당 계정을 대신하여

  • 서명은 규범적이며 트랜잭션의 명령어와 일치해야 합니다.

서명이 포함된 필드에 어떤 변경이 있더라도 서명이 무효화되므로, 서명 자체를 제외한 트랜잭션의 어떤 부분도 변조 가능하지 않습니다. 대부분의 경우, 서명 자체에 대한 변경도 서명을 무효화시키지만, 특정한 예외 사항이 있습니다. 이에 대한 설명은 아래에서 제시합니다.

서명은 트랜잭션의 식별 해시를 계산하는 데 사용되는 데이터 중 하나이므로, 변조 가능한 트랜잭션의 어떤 변경이든 다른 해시를 생성합니다.

대체 secp256k1 서명

"규범적"인 ECDSA 알고리즘과 secp256k1 곡선(기본값)을 사용하여 생성된 서명은 다음 요구 사항을 충족해야 합니다:

  • 서명은 올바르게 된 데이터여야 합니다.

  • 서명은 DER로 인코딩된 데이터 외에 어떤 채움 바이트도 포함해서는 안 됩니다.

  • 서명의 구성 정수는 음수일 수 없으며, secp256k1 그룹 순서보다 크지 않아야 합니다.

일반적으로 표준 ECDSA 구현은 이러한 요구 사항을 자동으로 처리합니다. 그러나 secp256k1에서는 이러한 요구 사항이 변조 가능성을 방지하기에 충분하지 않습니다. 따라서 XRP Ledger에는 이러한 문제가 없는 "완전 규범적" 서명 개념이 있습니다.

ECDSA 서명은 R과 S라는 두 정수로 구성됩니다. secp256k1 그룹 순서인 N은 모든 secp256k1 서명에 대해 상수 값입니다. 구체적으로, N은 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141의 값을 가집니다. 주어진 서명 (R,S)에 대해 서명 (R, N-S) (즉, S 대신 N에서 S를 뺀 값을 사용하는 경우)도 유효합니다.

따라서 완전 규범적 서명을 얻기 위해서는 두 가지 가능성 중 어떤 것을 선호하고 다른 것을 무효로 선언해야 합니다. XRP Ledger의 개발자들은 임의로 S와 N-S 중 더 작은 값을 선호하는 방향으로 결정했습니다. 트랜잭션은 선호되는(S가 더 작은) S 값으로 완전 규범적인 경우로 간주되며, 규범적인 트랜잭션에 필요한 모든 일반적인 규칙을 따릅니다. 완전 규범적인 ECDSA 서명을 계산하려면 S와 N-S를 비교하여 작은 값으로 사용해야 합니다.

RequireFullyCanonicalSig 개선안이 활성화되면(2020년) 모든 트랜잭션은 완전 규범적인 서명만 사용해야 합니다.

다중 서명과의 변조 가능성

다중 서명의 중요한 명시적인 특징은 여러 다른 구성이 트랜잭션을 유효하게 만들 수 있다는 것입니다. 예를 들어, 계정은 5명의 서명자 중 3명의 서명만 허용하여 트랜잭션을 승인할 수 있도록 구성될 수 있습니다. 그러나 이는 트랜잭션의 여러 가지 유효한 변형이 가능하다는 것을 의미합니다. 각 변형은 서로 다른 식별 해시를 가지게 됩니다.

다음의 모든 경우에서 트랜잭션 변조 가능성이 발생할 수 있습니다:

  • 하나 이상의 서명을 제거하여 트랜잭션의 쿼럼을 충족시킬 수 있는 경우. 제3자는 서명을 제거하고 해당 트랜잭션을 다시 제출할 수 있습니다.

  • 이미 쿼럼을 충족하는 트랜잭션에 유효한 서명을 추가할 수 있는 경우. 송신자의 다중 서명 설정에 따라, 이는 트랜잭션에 기존 서명을 제거하거나 추가하는 것과 관련될 수 있습니다.

  • 트랜잭션의 서명 중 하나를 다른 유효한 서명으로 바꿀 수 있는 경우. 송신자의 다중 서명 설정에 따라, 이는 트랜잭션에 새로운 서명을 추가하거나 기존 서명을 교체하는 것과 관련될 수 있습니다.

권한 있는 서명자가 악의적이지 않더라도 혼란이나 미흡한 조율로 인해 여러 서명자가 동일한 트랜잭션의 서로 다른 유효한 버전을 제출할 수 있습니다.

다중 서명의 변조 가능성에 대한 완화책

좋은 운영 보안은 이러한 문제에 대해 보호할 수 있습니다. 다중 서명의 경우, 다음과 같은 좋은 운영 보안 관행을 따른다면 변조 가능성 문제를 피할 수 있습니다:

  • 필요한 서명보다 많은 서명을 수집하지 않습니다.

  • 필요한 서명 수집 후에는 트랜잭션을 조립하는 한 당사자를 지정하거나, 서명자에게 트랜잭션 명령어를 일렬로 전달하도록 지시합니다.

  • 불필요한 또는 신뢰할 수 없는 서명자를 다중 서명 목록에 추가하지 않습니다. 그들의 키에 연결된 가중치 값이 트랜잭션을 승인하기에 부족하더라도 추가하지 않습니다.

  • 트랜잭션의 식별 해시와 서명 집합이 예상과 다른 상태에서 실행될 가능성을 대비합니다. 계정의 전송된 트랜잭션을 주의 깊게 모니터링합니다(예: account_tx 메소드 사용.)

  • 계정의 시퀀스 번호를 모니터링합니다(예: account_info 메소드 사용.) 이 번호는 계정이 트랜잭션을 성공적으로 전송할 때마다 정확히 1씩 증가하며, 다른 방식으로는 절대로 증가하지 않습니다. 예상한 번호와 일치하지 않는 경우, 최근 트랜잭션을 확인하여 확인해야 합니다(변조 가능한 트랜잭션 외에도 다른 이유로 인해 발생할 수 있습니다. 다른 애플리케이션을 통해 트랜잭션을 보내도록 구성한 경우일 수 있습니다. 악의적인 사용자가 비밀 키에 액세스한 경우일 수 있습니다. 또는 애플리케이션이 데이터를 손실하여 전송한 트랜잭션을 잊어버린 경우일 수 있습니다.)

  • 다중 서명을 다시 생성할 때, 의도한 작업이 이미 실행되지 않았음을 수동으로 확인하지 않는 한 Sequence 번호를 변경하지 않습니다.

  • 서명하기 전에 tfFullyCanonicalSig 플래그가 활성화되어 있는지 확인합니다.

보다 높은 보안을 위해 이러한 지침들은 여러 계층의 보호를 제공합니다.

트랜잭션 변조를 통한 악용

XRP Ledger와 상호 작용하는 소프트웨어가 변조 가능한 트랜잭션을 전송하는 경우, 악의적인 사용자는 해당 소프트웨어를 속여 트랜잭션의 최종 결과를 추적하지 못하게 하고, 최악의 경우 등가의 지불을 여러 번 보낼 수 있습니다.

단일 서명만 사용하는 경우에는 이러한 악용에 취약하지 않습니다. 다중 서명을 사용하는 경우에는 필요 이상의 서명을 제공하는 경우 취약할 수 있습니다.

악용 시나리오 단계

취약한 시스템을 악용하는 과정은 다음과 같은 단계로 이루어집니다:

  1. 취약한 시스템이 다중 서명 트랜잭션을 구성하고 필요한 이상의 서명을 수집합니다. 권한이 있는 서명자가 악의적이거나 무책임한 경우, 해당 서명자의 서명이 포함되지 않았지만 추가될 수 있기 때문에 트랜잭션도 취약할 수 있습니다.

  2. 시스템은 취약한 트랜잭션의 식별 해시를 기록하고, XRP Ledger 네트워크에 제출한 다음, 해당 해시가 유효한 ledger 버전에 포함되기를 모니터링합니다.

  3. 악의적인 사용자는 트랜잭션이 네트워크를 통해 전파되는 것을 확인합니다.

  4. 악의적인 사용자는 취약한 트랜잭션에서 하나의 추가 서명을 제거합니다. 다른 트랜잭션 명령을 위해 서명을 생성하는 것과는 달리, 이 작업은 큰 계산 작업이 필요하지 않습니다. 첫 번째로 서명을 생성하는 것보다 훨씬 짧은 시간에 수행될 수 있습니다. 또는 이미 트랜잭션에 포함되지 않은 권한이 있는 서명자가 취약한 트랜잭션의 서명 목록에 자신의 서명을 추가할 수 있습니다. 송신자의 다중 서명 설정에 따라, 다른 서명을 제거하는 대신에도 서명을 추가할 수 있습니다. 서명 목록의 수정으로 인해 다른 식별 해시가 생성됩니다. (네트워크에 제출하기 전에 해시를 계산할 필요는 없지만, 나중에 트랜잭션 상태를 확인하기 쉽게 하기 위해 해시를 알고 있는 것이 좋습니다.)

  5. 악의적인 사용자는 수정된 트랜잭션을 네트워크에 제출합니다. 이로써 원래 제출된 트랜잭션과 악의적인 사용자가 제출한 수정된 버전 간에 "경주"가 발생합니다. 두 트랜잭션은 상호 배타적입니다. 둘 다 유효하지만, 시퀀스 번호를 포함한 정확히 동일한 트랜잭션 데이터를 가지고 있으므로 최대 한 개의 트랜잭션만 유효한 ledger에 포함될 수 있습니다. P2P 네트워크의 서버는 어떤 트랜잭션이 "먼저" 도착했는지 또는 원래 송신자의 의도였는지 알 수 없습니다. 네트워크 연결의 지연이나 다른 우연한 사건으로 인해 유효성 제안을 최종화할 때 검증기가 둘 중 하나만 볼 수 있으므로 둘 중 하나가 "경주"에서 이기게 될 수 있습니다. 악의적인 사용자는 일부 연결이 우수한 서버를 제어한다면(그 서버가 검증기로서 신뢰받지 않더라도) 비정규적인 트랜잭션을 확인받는 가능성을 높일 수 있습니다. 악의적인 사용자가 취약한 시스템이 트랜잭션을 제출한 유일한 서버를 제어하는 경우, 악의적인 사용자는 어떤 버전이 네트워크 전체로 분산되는지 쉽게 제어할 수 있습니다.

  6. 악의적인 사용자의 트랜잭션 버전은 컨센서스를 이루고 유효한 ledger에 포함됩니다. 이 시점에서 트랜잭션은 실행되었으며 취소할 수 없습니다. 해당 트랜잭션의 효과(예: XRP 전송)는 최종적입니다. 원래 트랜잭션의 버전은 시퀀스 번호가 사용되었기 때문에 더 이상 유효하지 않습니다. XRP Ledger에서의 트랜잭션의 효과는 원래 버전이 실행된 것과 정확히 동일합니다.

  7. 취약한 시스템은 기대하는 트랜잭션 해시를 볼 수 없으며, 잘못된 결론을 내리며 해당 트랜잭션이 실행되지 않았다고 가정합니다. 만약 트랜잭션이 LastLedgerSequence 필드를 포함한 경우, 이는 지정된 ledger 인덱스가 지나간 후에 발생합니다. 트랜잭션이 LastLedgerSequence 필드를 포함하지 않은 경우, 다른 방식으로 잘못될 수 있습니다: 동일한 송신자에서 동일한 시퀀스 번호를 사용하는 다른 트랜잭션이 없는 경우, 트랜잭션은 이론적으로 얼마나 시간이 지났든 이후에도 성공할 수 있습니다(자세한 내용은 Reliable Transaction Submission을 참조).

  8. 취약한 시스템은 트랜잭션이 실패했다고 가정하고 이에 따른 조치를 취합니다. 예를 들어, XRP Ledger에 보낸 금액이 전송되지 않은 것으로 생각하여 고객의 잔액을 환불(또는 차감)할 수 있습니다. 더 나쁜 경우, 취약한 시스템은 원래 트랜잭션과 동일한 내용을 가진 새로운 트랜잭션을 구성하여 시퀀스, LastLedgerSequence 및 수수료 매개변수를 변경할 수 있습니다. 이 새로운 트랜잭션이 변조 가능하다면 시스템은 동일한 방식으로 계속해서 악용될 수 있습니다.

2014년부터 2020년까지, XRP Ledger는 완전 규범적 서명을 항상 생성하지 않는 기존 소프트웨어와 호환성이 있었으며, 이러한 문제에 대해 호환성 있는 서명 소프트웨어를 보호하기 위해 플래그를 사용했습니다. 호환 가능한 서명 소프트웨어는 기본적으로 이 플래그를 활성화하며, 트랜잭션이 유효하려면 완전 규범적인 서명을 사용해야 했습니다. 이 활성화된 이후로는 이 플래그는 더 이상 필요하지 않지만, 그래도 활성화하는 데는 해가 없습니다.

tfFullyCanonicalSig
RequireFullyCanonicalSig 수정안
RequireFullyCanonicalSig 수정안
Ed25519 키로 서명
트랜잭션의 모든 필드
트랜잭션을 보낼 권한이 있어야 합니다.
DER로 인코딩
다중 서명의 변조 가능성에 대한 완화책