위키원
"리플레이 공격"의 두 판 사이의 차이
(→동영상) |
(→모든 리플레이 어택에 대한 일반적인 대책) |
||
| (사용자 3명의 중간 판 14개는 보이지 않습니다) | |||
| 2번째 줄: | 2번째 줄: | ||
==개요== | ==개요== | ||
| − | 리플레이 공격은 | + | 리플레이 공격은 [[플레이백]](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> | ||
| 12번째 줄: | 12번째 줄: | ||
===문제점=== | ===문제점=== | ||
| − | 중요한 결점이 되는 것은 아니지만, 리플레이 공격은 특히 암호화폐 거래 및 | + | 중요한 결점이 되는 것은 아니지만, 리플레이 공격은 특히 암호화폐 거래 및 블록체인 장부 환경과 관련이 있다. 그 이유는 블록체인 장부가 때때로 하드 포크 (hard forks)로 알려진 프로토콜 변경이나 업그레이드를 거쳐야하기 때문이다. 하드 포크를 진행하면 이전 장부는 소프트웨어의 이전 버전과 새로 업데이트된 버전으로 나누어져 분할된다. 일부 하드 포크는 장부를 업그레이드 하기위한 것이지만 다른 종류의 포크는 완전히 새로운 암호화폐를 발행하게 된다. 후자의 하드 포크 중 대표적인 사례 중 하나는 [[비트코인캐시]](Bitcoin Cash)가 2017 년 8월 1일, 대장격인 비트코인(Bitcoin) 장부로부터 포크를 할 수 있게 진행한 업그레이드 사례를 들 수 있다. |
| − | 하드 포크가 진행되면 이론적으로 공격자가 블록체인 장부에 대한 리플레이 공격이 가능하게 된다. 하드 포크 이전에 유효했던 지갑을 가진 사람이 이전 장부에서 처리한 거래는 다른 장부에서도 유효하게되므로 이는 결과적으로 한 장부를 통해 다른 사람으로부터 일정량의 암호화폐를 받은 사람은 다른 장부로 전환해 거래를 복제한 후, 허위로 동일한 양의 암호화폐를 자신의 계정으로 두 번째 전송을 할 수 있게 된다. 자신의 지갑이 공유된 장부 기록이 아니기때문에 하드 포크가 발생한 후 | + | 하드 포크가 진행되면 이론적으로 공격자가 블록체인 장부에 대한 리플레이 공격이 가능하게 된다. 하드 포크 이전에 유효했던 지갑을 가진 사람이 이전 장부에서 처리한 거래는 다른 장부에서도 유효하게되므로 이는 결과적으로 한 장부를 통해 다른 사람으로부터 일정량의 암호화폐를 받은 사람은 다른 장부로 전환해 거래를 복제한 후, 허위로 동일한 양의 암호화폐를 자신의 계정으로 두 번째 전송을 할 수 있게 된다. 자신의 지갑이 공유된 장부 기록이 아니기때문에 하드 포크가 발생한 후 블록체인을 이용하는 사용자는 이러한 공격에 취약하지 않다. |
==예방 및 대책== | ==예방 및 대책== | ||
===모든 리플레이 어택에 대한 일반적인 대책=== | ===모든 리플레이 어택에 대한 일반적인 대책=== | ||
| − | [[세션 ID]]와 구성요소 번호로 암호화된 각 구성요소에 태그를 지정하면 리플레이 어택을 방지할 수 있다. 이 솔루션 조합을 사용하면 서로 상호 | + | [[세션 ID]]와 구성요소 번호로 암호화된 각 구성요소에 태그를 지정하면 리플레이 어택을 방지할 수 있다. 이 솔루션 조합을 사용하면 서로 상호 의존적인 것은 사용하지 않는다. 상호 의존성이 없기 때문에 취약점이 줄어 든다. 이것은 프로그램의 각 실행에 대해 고유한 임의의 세션 ID가 생성되기 때문에 이전 실행이 복제하기가 더 어려워지므로 효과가 있다. 이 경우 새 실행시 세션 ID가 변경되었기 때문에 공격자가 재생을 수행 할 수 없다. |
===세션 식별자에 추가=== | ===세션 식별자에 추가=== | ||
| 37번째 줄: | 37번째 줄: | ||
===타임 스탬프=== | ===타임 스탬프=== | ||
| − | [[타임 스탬프]]는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 [[프로토콜]]을 사용하여 동기화를 수행 해야한다. 예를 들어 A는 주기적으로 시계와 함께 시간을 MAC과 함께 [[브로드 캐스트]]한다. B는 A에게 메시지를 보내려고 할 때 자신의 메시지에 자신의 시계에 대한 예상 시간을 포함시켜 인증한다. A은 타임 스탬프가 적절한 허용 범위 내에있는 메시지만 수락한다. 이 체계의 장점은 A가 난수를 | + | [[타임 스탬프]]는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 [[프로토콜]]을 사용하여 동기화를 수행 해야한다. 예를 들어 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)"을 지난 메시지는 오래된 것으로 간주되어 삭제된다. | ||
| + | 삼중 암호 체계 사용을 포함하여 개선 된 사항이 제안되었다. 이 세 가지 비밀번호는 인증 서버, 티켓 부여 서버 및 TGS와 함께 사용된다. 이 서버는 비밀번호를 사용 하여 다른 서버간에 비밀 키 를 사용하여 메시지를 암호화 한다. 암호화 이 세 키에 의해 제공되는 재생 공격을 방지에 도움을 도움이 된다. | ||
| + | |||
| + | ===애드혹 네트워크에서의 안전한 라우팅=== | ||
| + | 무선 애드혹 네트워크 도 공격을 받기 쉽다. 이 경우 AODV 프로토콜 을 확장하여 인증 시스템을 개선하고 강화할 수 있다. Ad Hoc 네트워크의 보안을 향상시키는이 방법은 적은 양의 오버 헤드로 네트워크의 보안을 향상시킨다. 광범위한 오버 헤드가 발생 하면 네트워크 속도가 느려지고 성능이 저하 될 위험이 있다. 따라서 상대적으로 낮은 오버 헤드를 유지함으로써 네트워크는 보안을 향상시키면서 더 나은 성능을 유지할 수 있다. | ||
| + | |||
| + | ===챌린지 핸드 셰이크 인증 프로토콜=== | ||
| + | 인증 및 로그인에 사용하는 클라이언트에 의해 지점 간 프로토콜 사용하는 경우 공격을 회신 취약 (PPP) 암호 인증 프로토콜 인증 클라이언트는 "자사의 사용자 이름과 비밀번호를 전송로, 자신의 ID를 확인 (PAP)을 맑은에 " 인증 서버는 이에 응답하여 그 확인 응답을 전송한다; 따라서 가로 채기 클라이언트는 전송 된 데이터를 읽고 클라이언트와 서버 각각을 다른 것으로 가장 할 수 있으며, 나중에 서버에 가장하기 위해 클라이언트 자격 증명을 저장할 수 있다. 챌린지 핸드 셰이크 인증 프로토콜(CHAP)는 인증 단계에서 클라이언트가 공유 비밀 (예 : 클라이언트의 비밀번호)을 기반으로 해시 계산 된 값으로 응답한다는 인증 자로부터의 "도전"메시지를 사용하여 인증 단계 동안 이러한 종류의 재생 공격으로부터 보호 한다. 클라이언트 인증을위한 자체 도전 과제 및 공유 비밀 계산과 비교한다. CHAP는 자체적으로 전송되지 않은 공유 비밀과 인증 자 제어 챌린지 반복, 식별자 및 챌린지 값 변경과 같은 다른 기능을 사용하여 재생 공격에 대한 제한적인 보호 기능을 제공한다. | ||
| + | |||
| + | ==활용== | ||
| + | 리플레이 공격이 사용 된 방법과 추가 공격을 방지하기 위해 문제를 감지하고 수정 한 방법에 대한 실제 사례가 몇 가지 있다. | ||
| + | |||
| + | ===차량용 원격 열쇠가없는 입력 시스템=== | ||
| + | 도로상의 많은 차량 은 사용자의 편의를 위해 원격 열쇠가없는 시스템 또는 열쇠 고리를 사용한다. 최신 시스템은 단순한 재생 공격에 대해 강화되었지만 버퍼링 된 재생 공격에 취약하다. 이 공격은 대상 차량의 범위 내에서 전파를 수신 및 전송할 수있는 장치를 배치하여 수행된다. 송신기는 RF 차량 잠금 해제 신호를 전송 한 후 나중에 사용할 수 있도록 버퍼에 배치하려고 시도한다. 차량 잠금을 해제하려고 시도하면 송신기는 새로운 신호를 걸러서 캐싱하고 기존 신호를 재생하여 차량보다 한 발 앞선 롤링 버퍼를 만든다. 나중에 공격자는이 버퍼링 된 코드를 사용하여 차량을 잠금 해제 할 수 있다. | ||
| + | |||
| + | ===텍스트에 따른 발표자 확인=== | ||
| + | 다양한 장치가 스피커 인식을 사용하여 스피커 의 신원을 확인한다. 텍스트 종속 시스템에서 공격자는 시스템에서 올바르게 확인한 대상 개인의 음성을 녹음 한 다음 시스템에서 확인하기 위해 녹음을 다시 재생할 수 있다. 검증 된 사용자의 저장된 음성으로부터의 스펙트럼 비트 맵을 사용하여 대응책이 고안되었다. 이 시나리오에서 재생 된 음성은 다른 패턴을 가지며 시스템에서 거부된다. | ||
{{각주}} | {{각주}} | ||
| 48번째 줄: | 67번째 줄: | ||
* 책갈피, 〈[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> | ||
2023년 7월 19일 (수) 01:53 기준 최신판
리플레이 공격 또는 리플레이 어택(replay attack)이란 기존 코인과 하드포크로 인해 나오는 새로운 코인이 동일 인증키를 사용하기 때문에 한쪽 코인의 출금정보를 가지고 다른 쪽 코인 출금을 시도하는 행위이다. 즉, 개인 지갑에 저장된 암호화폐가 중복 출금되는 현상을 말한다.
목차
개요[편집]
리플레이 공격은 플레이백(playback) 공격이라고도 하며,블록체인 하드포크시 한쪽 블록체인의 트랜잭션 데이터를 다른쪽 블록체인에 그대로 복사 재전송해 다른쪽 블록체인에도 같은 트랜잭션이 기록되도록 하는 행위이다. 이로 인해 원하지 않는 트랜잭션이 일어나게 된다. 예를 들어, 하드포크 전 1000 이더를 보유한 A라는 사람이 있다. A는 이더리움이 ETC와 ETH로 포크 된 뒤, 새로 생긴 ETC 1000개를 B라는 사람에게 ETH의 10분의 1 가격으로 팔았다. 그런데, 지갑을 열어보니, 남아있어야할 ETH가 모두 사라지고 없다. ETC 트랜잭션이 리플레이 돼 남아있어야 할 1000개의 ETH도 함께 B에게 전송된 것이다. A는 큰 손실을 본 것이고, B는 큰 이득을 본 것이다. 실제로 이 같은 일이 벌어지고 있어 거래소가 가장 큰 피해를 입고있다. 리플레이 어택은 해커의 소행이 아니라, 부실한 하드포크 코딩이 원인인 것으로 드러났다. 누군가 개입해 인위적으로 리플레이를 하는 것이 아니라, 하드포크가 불완전하게 이루어져, 한쪽 블록체인의 트랜잭션이 다른쪽 체인에도 자동으로 브로드캐스트 된다.[1]
사용[편집]
리플레이 공격은 겉보기에 유효한 자격 증명을 전달하여 보호된 네트워크의 저장된 정보에 액세스하는데 사용할 수 있다. 또한, 중복 거래를 하도록 금융기관을 속여 공격자가 공격대상의 계좌에서 직접 돈을 인출해낼 수 있다. 경우에 따라 해커는 서로 다른 암호화된 메시지의 일부를 결합하여 그 결과로 생긴 암호문을 네트워크에 전달하는데, 소위 '잘라내기-붙여넣기 공격'이라고 말한다. 이러한 공격에 대한 네트워크의 반응은 종종 해커에게 시스템을 악용하는데 사용할 수있는 유용한 정보를 제공하기도 한다.[2]
한계[편집]
이와 관련된 위험성에도 불구하고 해커가 리플레이 공격만으로 달성 할 수있는 것에는 한계가 있다. 공격자는 네트워크가 거부하지 않고 전송되는 데이터를 변경할 수 없으므로 과거 작업 반복의 공격의 효과가 확연히 떨어지게 된다. 따라서 이러한 공격들은 상대적으로 방어하기 쉬운데, 데이터 전송에 타임 스탬프를 추가하는 기본적인 방어정책 만으로도 리플레이 공격의 시도를 막을 수 있다. 또한 서버는 반복된 메시지를 캐시에 저장한 후 특정 반복 횟수를 제한하여 공격자가 빠르고 성공적인 리플레이 메시지를 통한 연속적인 공격 시도 횟수를 제한할 수 있다.
문제점[편집]
중요한 결점이 되는 것은 아니지만, 리플레이 공격은 특히 암호화폐 거래 및 블록체인 장부 환경과 관련이 있다. 그 이유는 블록체인 장부가 때때로 하드 포크 (hard forks)로 알려진 프로토콜 변경이나 업그레이드를 거쳐야하기 때문이다. 하드 포크를 진행하면 이전 장부는 소프트웨어의 이전 버전과 새로 업데이트된 버전으로 나누어져 분할된다. 일부 하드 포크는 장부를 업그레이드 하기위한 것이지만 다른 종류의 포크는 완전히 새로운 암호화폐를 발행하게 된다. 후자의 하드 포크 중 대표적인 사례 중 하나는 비트코인캐시(Bitcoin Cash)가 2017 년 8월 1일, 대장격인 비트코인(Bitcoin) 장부로부터 포크를 할 수 있게 진행한 업그레이드 사례를 들 수 있다.
하드 포크가 진행되면 이론적으로 공격자가 블록체인 장부에 대한 리플레이 공격이 가능하게 된다. 하드 포크 이전에 유효했던 지갑을 가진 사람이 이전 장부에서 처리한 거래는 다른 장부에서도 유효하게되므로 이는 결과적으로 한 장부를 통해 다른 사람으로부터 일정량의 암호화폐를 받은 사람은 다른 장부로 전환해 거래를 복제한 후, 허위로 동일한 양의 암호화폐를 자신의 계정으로 두 번째 전송을 할 수 있게 된다. 자신의 지갑이 공유된 장부 기록이 아니기때문에 하드 포크가 발생한 후 블록체인을 이용하는 사용자는 이러한 공격에 취약하지 않다.
예방 및 대책[편집]
모든 리플레이 어택에 대한 일반적인 대책[편집]
세션 ID와 구성요소 번호로 암호화된 각 구성요소에 태그를 지정하면 리플레이 어택을 방지할 수 있다. 이 솔루션 조합을 사용하면 서로 상호 의존적인 것은 사용하지 않는다. 상호 의존성이 없기 때문에 취약점이 줄어 든다. 이것은 프로그램의 각 실행에 대해 고유한 임의의 세션 ID가 생성되기 때문에 이전 실행이 복제하기가 더 어려워지므로 효과가 있다. 이 경우 새 실행시 세션 ID가 변경되었기 때문에 공격자가 재생을 수행 할 수 없다.
세션 식별자에 추가[편집]
세션 토큰이라고도하는 세션 ID는 리플레이 어택을 피하는 데 사용할 수 있는 메커니즘 중 하나다.
- A는 B에게 일회용 토큰을 보내는데, B는 암호를 변환하고 결과를 A에게 보낸다. 예를 들어, 토큰을 사용하여 세션 토큰의 해시 함수를 계산하고 사용할 암호에 추가한다.
- A는 세션 토큰으로 동일한 계산을 수행한다.
- B와 A의 값이 모두 일치하는 경우에만 로그인에 성공한다.
- 이제 공격자 C가이 값을 캡처하여 다른 세션에서 사용하려고한다고 가정했을때, A는 다른 세션 토큰을 보내며 C가 캡처 된 값으로 응답하면 A의 계산과 다르므로 B가 아니라는 것을 알게된다.
세션 토큰은 무작위 프로세스로 선택해야한다. 그렇지 않으면 C는 A로 위장하여 미래의 예측 토큰을 제시하고 B가 해당 토큰을 변환에 사용하도록 설득 할 수 있다. 그런 다음 C는 나중에 회신을 재생할 수 있으며 A은 인증 을 수락 한다.
일회성 비밀번호[편집]
일회용 암호는 사용 후 또는 매우 짧은 시간 후에 암호가 만료된다는 점에서 세션 토큰과 유사하다. 세션 외에도 개별 트랜잭션을 인증하는 데 사용할 수 있다. 또한 인증 프로세스 중에 서로 통신하는 두 당사자 간의 신뢰를 설정하는 데 사용될 수 있다.
Nonces와 MAC[편집]
A은 nonces 를 보낼 수도 있지만 B가 확인해야하는 메시지 인증 코드 (MAC)를 포함해야한다.
타임 스탬프[편집]
타임 스탬프는 리플레이 어택을 방지하는 또 다른 방법이다. 보안 프로토콜을 사용하여 동기화를 수행 해야한다. 예를 들어 A는 주기적으로 시계와 함께 시간을 MAC과 함께 브로드 캐스트한다. B는 A에게 메시지를 보내려고 할 때 자신의 메시지에 자신의 시계에 대한 예상 시간을 포함시켜 인증한다. A은 타임 스탬프가 적절한 허용 범위 내에있는 메시지만 수락한다. 이 체계의 장점은 A가 난수를 생성할 필요가없고 B가 A에게 난수를 요구할 필요가 없다는 것이다. 단방향 네트워크또는 단방향에 가까운 경우 이점이 될 수 있다. 리플레이 어택이 충분히 빠르게 수행된다면, 합리적 한계 내에서 성공할 수 있다는 것이 단점이다.[3]
특정 시나리오의 대책[편집]
Kerberos 프로토콜 방지[편집]
Kerberos 인증 프로토콜은 몇 가지 대책이 포함되어 있다. 전형적인 리플레이 공격의 경우, 메시지는 적에 의해 포착 된 후 나중에 재생되어 효과를 낸다. 예를 들어, 은행 공격이이 공격에 취약한 경우 자금 이체를 초래하는 메시지를 반복해서 재생하여 원래 의도 한 것보다 많은 자금을 이체 할 수 있다. 그러나 여러 버전의 LDAP 및 Microsoft Windows Active Directory에 구현 된 Kerberos 프로토콜에는 재생 스탬프의 효과를 심각하게 제한하기 위해 타임 스탬프와 관련된 체계를 사용하는 것이 포함된다. "TTL (Time to Live)"을 지난 메시지는 오래된 것으로 간주되어 삭제된다. 삼중 암호 체계 사용을 포함하여 개선 된 사항이 제안되었다. 이 세 가지 비밀번호는 인증 서버, 티켓 부여 서버 및 TGS와 함께 사용된다. 이 서버는 비밀번호를 사용 하여 다른 서버간에 비밀 키 를 사용하여 메시지를 암호화 한다. 암호화 이 세 키에 의해 제공되는 재생 공격을 방지에 도움을 도움이 된다.
애드혹 네트워크에서의 안전한 라우팅[편집]
무선 애드혹 네트워크 도 공격을 받기 쉽다. 이 경우 AODV 프로토콜 을 확장하여 인증 시스템을 개선하고 강화할 수 있다. Ad Hoc 네트워크의 보안을 향상시키는이 방법은 적은 양의 오버 헤드로 네트워크의 보안을 향상시킨다. 광범위한 오버 헤드가 발생 하면 네트워크 속도가 느려지고 성능이 저하 될 위험이 있다. 따라서 상대적으로 낮은 오버 헤드를 유지함으로써 네트워크는 보안을 향상시키면서 더 나은 성능을 유지할 수 있다.
챌린지 핸드 셰이크 인증 프로토콜[편집]
인증 및 로그인에 사용하는 클라이언트에 의해 지점 간 프로토콜 사용하는 경우 공격을 회신 취약 (PPP) 암호 인증 프로토콜 인증 클라이언트는 "자사의 사용자 이름과 비밀번호를 전송로, 자신의 ID를 확인 (PAP)을 맑은에 " 인증 서버는 이에 응답하여 그 확인 응답을 전송한다; 따라서 가로 채기 클라이언트는 전송 된 데이터를 읽고 클라이언트와 서버 각각을 다른 것으로 가장 할 수 있으며, 나중에 서버에 가장하기 위해 클라이언트 자격 증명을 저장할 수 있다. 챌린지 핸드 셰이크 인증 프로토콜(CHAP)는 인증 단계에서 클라이언트가 공유 비밀 (예 : 클라이언트의 비밀번호)을 기반으로 해시 계산 된 값으로 응답한다는 인증 자로부터의 "도전"메시지를 사용하여 인증 단계 동안 이러한 종류의 재생 공격으로부터 보호 한다. 클라이언트 인증을위한 자체 도전 과제 및 공유 비밀 계산과 비교한다. CHAP는 자체적으로 전송되지 않은 공유 비밀과 인증 자 제어 챌린지 반복, 식별자 및 챌린지 값 변경과 같은 다른 기능을 사용하여 재생 공격에 대한 제한적인 보호 기능을 제공한다.
활용[편집]
리플레이 공격이 사용 된 방법과 추가 공격을 방지하기 위해 문제를 감지하고 수정 한 방법에 대한 실제 사례가 몇 가지 있다.
차량용 원격 열쇠가없는 입력 시스템[편집]
도로상의 많은 차량 은 사용자의 편의를 위해 원격 열쇠가없는 시스템 또는 열쇠 고리를 사용한다. 최신 시스템은 단순한 재생 공격에 대해 강화되었지만 버퍼링 된 재생 공격에 취약하다. 이 공격은 대상 차량의 범위 내에서 전파를 수신 및 전송할 수있는 장치를 배치하여 수행된다. 송신기는 RF 차량 잠금 해제 신호를 전송 한 후 나중에 사용할 수 있도록 버퍼에 배치하려고 시도한다. 차량 잠금을 해제하려고 시도하면 송신기는 새로운 신호를 걸러서 캐싱하고 기존 신호를 재생하여 차량보다 한 발 앞선 롤링 버퍼를 만든다. 나중에 공격자는이 버퍼링 된 코드를 사용하여 차량을 잠금 해제 할 수 있다.
텍스트에 따른 발표자 확인[편집]
다양한 장치가 스피커 인식을 사용하여 스피커 의 신원을 확인한다. 텍스트 종속 시스템에서 공격자는 시스템에서 올바르게 확인한 대상 개인의 음성을 녹음 한 다음 시스템에서 확인하기 위해 녹음을 다시 재생할 수 있다. 검증 된 사용자의 저장된 음성으로부터의 스펙트럼 비트 맵을 사용하여 대응책이 고안되었다. 이 시나리오에서 재생 된 음성은 다른 패턴을 가지며 시스템에서 거부된다.
각주[편집]
- ↑ 비트공자, 〈부실한 하드포크 코딩이 초래한 재난, 리플레이 어택(replay attack)/Seoul Bitcoin Forum〉, 《서울비트코인포럼》, 2016-07-31
- ↑ 바이낸스아카데미, 〈리플레이 공격〉, 《Binanace Academy》, 2019-08
- ↑ 〈Replay attack〉, 《위키피디아》
참고자료[편집]
- 〈리플레이어택(Replay Attack), 비트코인 세그윗시 위험하다?〉, 《코인뉴스》, 2017-07-24
- 벤타스주식회사, 〈가상화폐, 리플레이 어택(Replay attack)이란?〉, 《네이버포스트》, 2017-11-01
- 비트공자, 〈부실한 하드포크 코딩이 초래한 재난, 리플레이 어택(replay attack)/Seoul Bitcoin Forum〉, 《서울비트코인포럼》, 2016-07-31
- CFun Korea, 〈(067)리플레이 어택이란〉, 《네이버블로그》, 2019-03-11
- 책갈피, 〈비트코인 리플레이 어택의 사례 / 세그윗 2X의 현재 이슈〉, 《네이버블로그》, 2017-09-26
- 〈Replay attack〉, 《위키피디아》
동영상[편집]
같이보기[편집]
