리플레이 공격 편집하기
최신판 | 당신의 편집 | ||
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가 변경되었기 때문에 공격자가 재생을 수행 할 수 없다. |
===세션 식별자에 추가=== | ===세션 식별자에 추가=== | ||
38번째 줄: | 38번째 줄: | ||
===타임 스탬프=== | ===타임 스탬프=== | ||
[[타임 스탬프]]는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 [[프로토콜]]을 사용하여 동기화를 수행 해야한다. 예를 들어 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> | ||
+ | Kerberos 프로토콜 방지 | ||
+ | Kerberos 인증 프로토콜은 몇 가지 대책이 포함되어 있습니다. 전형적인 리플레이 공격의 경우, 메시지는 적에 의해 포착 된 후 나중에 재생되어 효과를냅니다. 예를 들어, 은행 공격이이 공격에 취약한 경우 자금 이체를 초래하는 메시지를 반복해서 재생하여 원래 의도 한 것보다 많은 자금을 이체 할 수 있습니다. 그러나 여러 버전의 LDAP 및 Microsoft Windows Active Directory에 구현 된 Kerberos 프로토콜에는 재생 스탬프의 효과를 심각하게 제한하기 위해 타임 스탬프와 관련된 체계를 사용하는 것이 포함됩니다. "TTL (Time to Live)"을 지난 메시지는 오래된 것으로 간주되어 삭제됩니다. [2] | ||
+ | 삼중 암호 체계 사용을 포함하여 개선 된 사항이 제안되었습니다. 이 세 가지 비밀번호는 인증 서버, 티켓 부여 서버 및 TGS와 함께 사용됩니다. 이 서버는 비밀번호를 사용 하여 다른 서버간에 비밀 키 를 사용하여 메시지를 암호화 합니다. 암호화 이 세 키에 의해 제공되는 재생 공격을 방지에 도움을 도움이됩니다. [삼] | ||
==특정 시나리오의 대책 == | ==특정 시나리오의 대책 == | ||
− | + | ==Kerberos 프로토콜 방지== | |
− | Kerberos 인증 프로토콜은 몇 가지 대책이 포함되어 | + | Kerberos 인증 프로토콜은 몇 가지 대책이 포함되어 있습니다. 전형적인 리플레이 공격의 경우, 메시지는 적에 의해 포착 된 후 나중에 재생되어 효과를냅니다. 예를 들어, 은행 공격이이 공격에 취약한 경우 자금 이체를 초래하는 메시지를 반복해서 재생하여 원래 의도 한 것보다 많은 자금을 이체 할 수 있습니다. 그러나 여러 버전의 LDAP 및 Microsoft Windows Active Directory에 구현 된 Kerberos 프로토콜에는 재생 스탬프의 효과를 심각하게 제한하기 위해 타임 스탬프와 관련된 체계를 사용하는 것이 포함됩니다. "TTL (Time to Live)"을 지난 메시지는 오래된 것으로 간주되어 삭제됩니다. [2] |
− | |||
− | + | 삼중 암호 체계 사용을 포함하여 개선 된 사항이 제안되었습니다. 이 세 가지 비밀번호는 인증 서버, 티켓 부여 서버 및 TGS와 함께 사용됩니다. 이 서버는 비밀번호를 사용 하여 다른 서버간에 비밀 키 를 사용하여 메시지를 암호화 합니다. 암호화 이 세 키에 의해 제공되는 재생 공격을 방지에 도움을 도움이됩니다. [삼] | |
− | |||
− | == | + | ==애드혹 네트워크에서의 안전한 라우팅 == |
− | + | 무선 애드혹 네트워크 도 공격을 받기 쉽습니다. 이 경우 AODV 프로토콜 을 확장하여 인증 시스템을 개선하고 강화할 수 있습니다. Ad Hoc 네트워크의 보안을 향상시키는이 방법은 적은 양의 오버 헤드로 네트워크의 보안을 향상시킵니다. [4] 광범위한 오버 헤드가 발생 하면 네트워크 속도가 느려지고 성능이 저하 될 위험이 있습니다. 따라서 상대적으로 낮은 오버 헤드를 유지함으로써 네트워크는 보안을 향상시키면서 더 나은 성능을 유지할 수 있습니다. | |
− | == | + | ==챌린지 핸드 셰이크 인증 프로토콜 == |
− | + | 인증 및 로그인에 사용하는 클라이언트에 의해 지점 간 프로토콜 사용하는 경우 공격을 회신 취약 (PPP) 암호 인증 프로토콜 인증 클라이언트는 "자사의 사용자 이름과 비밀번호를 전송로, 자신의 ID를 확인 (PAP)을 맑은에 " 인증 서버는 이에 응답하여 그 확인 응답을 전송한다; 따라서 가로 채기 클라이언트는 전송 된 데이터를 읽고 클라이언트와 서버 각각을 다른 것으로 가장 할 수 있으며, 나중에 서버에 가장하기 위해 클라이언트 자격 증명을 저장할 수 있습니다. 챌린지 핸드 셰이크 인증 프로토콜(CHAP)는 인증 단계에서 클라이언트가 공유 비밀 (예 : 클라이언트의 비밀번호)을 기반으로 해시 계산 된 값으로 응답한다는 인증 자로부터의 "도전"메시지를 사용하여 인증 단계 동안 이러한 종류의 재생 공격으로부터 보호 합니다. 클라이언트 인증을위한 자체 도전 과제 및 공유 비밀 계산과 비교합니다. CHAP는 자체적으로 전송되지 않은 공유 비밀과 인증 자 제어 챌린지 반복, 식별자 및 챌린지 값 변경과 같은 다른 기능을 사용하여 재생 공격에 대한 제한적인 보호 기능을 제공합니다. [5] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{각주}} | {{각주}} | ||