리플레이 공격 편집하기
최신판 | 당신의 편집 | ||
2번째 줄: | 2번째 줄: | ||
==개요== | ==개요== | ||
− | 리플레이 공격은 [[플레이백]](playback) 공격이라고도 하며,[[블록체인]] [[하드포크]]시 한쪽 블록체인의 [[트랜잭션]] 데이터를 다른쪽 블록체인에 그대로 복사 재전송해 다른쪽 블록체인에도 같은 트랜잭션이 기록되도록 하는 행위이다. 이로 인해 원하지 않는 트랜잭션이 일어나게 된다. 예를 들어, 하드포크 전 1000 이더를 보유한 A라는 사람이 있다. A는 [[이더리움]]이 [[ETC]]와 [[ETH]]로 포크 된 뒤, 새로 생긴 ETC 1000개를 B라는 사람에게 ETH의 10분의 1 가격으로 팔았다. 그런데, 지갑을 열어보니, 남아있어야할 ETH가 모두 사라지고 없다. ETC 트랜잭션이 리플레이 돼 남아있어야 할 1000개의 ETH도 함께 B에게 전송된 것이다. A는 큰 손실을 본 것이고, B는 큰 | + | 리플레이 공격은 [[플레이백]](playback) 공격이라고도 하며,[[블록체인]] [[하드포크]]시 한쪽 블록체인의 [[트랜잭션]] 데이터를 다른쪽 블록체인에 그대로 복사 재전송해 다른쪽 블록체인에도 같은 트랜잭션이 기록되도록 하는 행위이다. 이로 인해 원하지 않는 트랜잭션이 일어나게 된다. 예를 들어, 하드포크 전 1000 이더를 보유한 A라는 사람이 있다. A는 [[이더리움]]이 [[ETC]]와 [[ETH]]로 포크 된 뒤, 새로 생긴 ETC 1000개를 B라는 사람에게 ETH의 10분의 1 가격으로 팔았다. 그런데, 지갑을 열어보니, 남아있어야할 ETH가 모두 사라지고 없다. ETC 트랜잭션이 리플레이 돼 남아있어야 할 1000개의 ETH도 함께 B에게 전송된 것이다. A는 큰 손실을 본 것이고, B는 큰 이들을 본 것이다. 실제로 이 같은 일이 벌어지고 있어 거래소가 가장 큰 피해를 입고있다. |
리플레이 어택은 해커의 소행이 아니라, 부실한 하드포크 코딩이 원인인 것으로 드러났다. 누군가 개입해 인위적으로 리플레이를 하는 것이 아니라, 하드포크가 불완전하게 이루어져, 한쪽 블록체인의 트랜잭션이 다른쪽 체인에도 자동으로 브로드캐스트 된다.<ref>비트공자, 〈[https://cafe.naver.com/seoulbitcoin/358 부실한 하드포크 코딩이 초래한 재난, 리플레이 어택(replay attack)/Seoul Bitcoin Forum]〉, 《서울비트코인포럼》, 2016-07-31</ref> | 리플레이 어택은 해커의 소행이 아니라, 부실한 하드포크 코딩이 원인인 것으로 드러났다. 누군가 개입해 인위적으로 리플레이를 하는 것이 아니라, 하드포크가 불완전하게 이루어져, 한쪽 블록체인의 트랜잭션이 다른쪽 체인에도 자동으로 브로드캐스트 된다.<ref>비트공자, 〈[https://cafe.naver.com/seoulbitcoin/358 부실한 하드포크 코딩이 초래한 재난, 리플레이 어택(replay attack)/Seoul Bitcoin Forum]〉, 《서울비트코인포럼》, 2016-07-31</ref> | ||
18번째 줄: | 18번째 줄: | ||
==예방 및 대책== | ==예방 및 대책== | ||
===모든 리플레이 어택에 대한 일반적인 대책=== | ===모든 리플레이 어택에 대한 일반적인 대책=== | ||
− | [[세션 ID]]와 구성요소 번호로 암호화된 각 구성요소에 태그를 지정하면 리플레이 어택을 방지할 수 있다. 이 솔루션 조합을 사용하면 서로 상호 | + | [[세션 ID]]와 구성요소 번호로 암호화된 각 구성요소에 태그를 지정하면 리플레이 어택을 방지할 수 있다. 이 솔루션 조합을 사용하면 서로 상호 의존적 인 것은 사용하지 않는다. 상호 의존성이 없기 때문에 취약점이 줄어 든다. 이것은 프로그램의 각 실행에 대해 고유한 임의의 세션 ID가 생성되기 때문에 이전 실행이 복제하기가 더 어려워지므로 효과가 있다. 이 경우 새 실행시 세션 ID가 변경되었기 때문에 공격자가 재생을 수행 할 수 없다. |
===세션 식별자에 추가=== | ===세션 식별자에 추가=== | ||
48번째 줄: | 48번째 줄: | ||
===챌린지 핸드 셰이크 인증 프로토콜=== | ===챌린지 핸드 셰이크 인증 프로토콜=== | ||
− | 인증 및 로그인에 사용하는 클라이언트에 의해 지점 간 프로토콜 사용하는 경우 공격을 회신 취약 (PPP) 암호 인증 프로토콜 인증 클라이언트는 "자사의 사용자 이름과 비밀번호를 전송로, 자신의 ID를 확인 (PAP)을 맑은에 " 인증 서버는 이에 응답하여 그 확인 응답을 전송한다; 따라서 가로 채기 클라이언트는 전송 된 데이터를 읽고 클라이언트와 서버 각각을 다른 것으로 가장 할 수 있으며, 나중에 서버에 가장하기 위해 클라이언트 자격 증명을 저장할 수 | + | 인증 및 로그인에 사용하는 클라이언트에 의해 지점 간 프로토콜 사용하는 경우 공격을 회신 취약 (PPP) 암호 인증 프로토콜 인증 클라이언트는 "자사의 사용자 이름과 비밀번호를 전송로, 자신의 ID를 확인 (PAP)을 맑은에 " 인증 서버는 이에 응답하여 그 확인 응답을 전송한다; 따라서 가로 채기 클라이언트는 전송 된 데이터를 읽고 클라이언트와 서버 각각을 다른 것으로 가장 할 수 있으며, 나중에 서버에 가장하기 위해 클라이언트 자격 증명을 저장할 수 있습니다. 챌린지 핸드 셰이크 인증 프로토콜(CHAP)는 인증 단계에서 클라이언트가 공유 비밀 (예 : 클라이언트의 비밀번호)을 기반으로 해시 계산 된 값으로 응답한다는 인증 자로부터의 "도전"메시지를 사용하여 인증 단계 동안 이러한 종류의 재생 공격으로부터 보호 합니다. 클라이언트 인증을위한 자체 도전 과제 및 공유 비밀 계산과 비교합니다. CHAP는 자체적으로 전송되지 않은 공유 비밀과 인증 자 제어 챌린지 반복, 식별자 및 챌린지 값 변경과 같은 다른 기능을 사용하여 재생 공격에 대한 제한적인 보호 기능을 제공합니다. [5] |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{각주}} | {{각주}} | ||