리플레이 공격 편집하기
최신판 | 당신의 편집 | ||
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가 변경되었기 때문에 공격자가 재생을 수행 할 수 없다. |
===세션 식별자에 추가=== | ===세션 식별자에 추가=== | ||
39번째 줄: | 39번째 줄: | ||
[[타임 스탬프]]는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 [[프로토콜]]을 사용하여 동기화를 수행 해야한다. 예를 들어 A는 주기적으로 시계와 함께 시간을 MAC과 함께 [[브로드 캐스트]]한다. B는 A에게 메시지를 보내려고 할 때 자신의 메시지에 자신의 시계에 대한 예상 시간을 포함시켜 인증한다. A은 타임 스탬프가 적절한 허용 범위 내에있는 메시지만 수락한다. 이 체계의 장점은 A가 난수를 생성할 필요가없고 B가 A에게 난수를 요구할 필요가 없다는 것이다. 단방향 [[네트워크]]또는 단방향에 가까운 경우 이점이 될 수 있다. 리플레이 어택이 충분히 빠르게 수행된다면, 합리적 한계 내에서 성공할 수 있다는 것이 단점이다.<ref>〈[https://en.wikipedia.org/wiki/Replay_attack Replay attack]〉, 《위키피디아》</ref> | [[타임 스탬프]]는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 [[프로토콜]]을 사용하여 동기화를 수행 해야한다. 예를 들어 A는 주기적으로 시계와 함께 시간을 MAC과 함께 [[브로드 캐스트]]한다. B는 A에게 메시지를 보내려고 할 때 자신의 메시지에 자신의 시계에 대한 예상 시간을 포함시켜 인증한다. A은 타임 스탬프가 적절한 허용 범위 내에있는 메시지만 수락한다. 이 체계의 장점은 A가 난수를 생성할 필요가없고 B가 A에게 난수를 요구할 필요가 없다는 것이다. 단방향 [[네트워크]]또는 단방향에 가까운 경우 이점이 될 수 있다. 리플레이 어택이 충분히 빠르게 수행된다면, 합리적 한계 내에서 성공할 수 있다는 것이 단점이다.<ref>〈[https://en.wikipedia.org/wiki/Replay_attack Replay attack]〉, 《위키피디아》</ref> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{각주}} | {{각주}} | ||
67번째 줄: | 48번째 줄: | ||
* 책갈피, 〈[https://blog.naver.com/imga0712/221105932783 비트코인 리플레이 어택의 사례 / 세그윗 2X의 현재 이슈]〉, 《네이버블로그》, 2017-09-26 | * 책갈피, 〈[https://blog.naver.com/imga0712/221105932783 비트코인 리플레이 어택의 사례 / 세그윗 2X의 현재 이슈]〉, 《네이버블로그》, 2017-09-26 | ||
* 〈[https://en.wikipedia.org/wiki/Replay_attack Replay attack]〉, 《위키피디아》 | * 〈[https://en.wikipedia.org/wiki/Replay_attack Replay attack]〉, 《위키피디아》 | ||
− | + | ||
==동영상== | ==동영상== | ||
<youtube>oxywoZxZ1ZM</youtube> | <youtube>oxywoZxZ1ZM</youtube> |