Wifi Network - IEEE 802.1X Authentication process

오늘은 지난 10월에 세미나를 통해 학습했던 내용 중 WIFI WPA2/3 의 인증 과정 중 하나인 IEEE 802.1X의 패킷 분석 내용에 대해 설명하려고 한다.

 

 

802.1X Authentication Protocol

 

 

먼저 802.1X란 WIFI의 수많은 통신 프로토콜인 802.11x와 매우 유사한 이름을 가지고 있지만, 그 특성 자체는 전혀 다른 종류의 프로토콜이다.

 

이 프로토콜은 WPA2 이후의 암호화 방식에서 Enterprise 모드의 더 고급화된 암호화 방식을 추가하기 위해 생겨난 방식이다.

 

web에서 TLS를 활용하여 HTTPS로 통신 패킷을 보안하듯이 이 보안 방식 또한 TLS 터널링이라는 과정을 포함하여 패킷을 보안하여, 이후 암호화 과정에서 통신을 수행할 때 사용하는 Key를 안전하게 전달한다.

 

오늘은 이 과정을 Wireshark 프로그램을 통해 패킷을 훔쳐 내용을 확인하고, 과정을 분석해보자.

 

---

 

1. 외부 ID를 통한 신원 요청 & 응답 (EAPOL start)

 

지금부터는 IEEE 802.1X 과정을 패킷과 함께 분석하며 과정들을 살펴본 내용이다.

먼저 AP가 주변 기기들에게 존재를 알리는 브로드캐스팅 통신을 수행하면 클라이언트는 주변 와이파이 목록에 해당 AP가 뜨게 된다.

이를 통해 사용자는 연결 요청을 시작하게 된다.

그러면 사전에 사용자가 연결할 때 제출한 Anonymous identity 의 정보가 외부 id라는것으로 radius 서버에 전달되어서 해당 외부 id의 신원을 검토한다.

오른쪽 사진을 보면 Anonymous identity에 justin.son을 입력하고 연결을 요청했더니 패킷에 해당 내용이 드러나는 것을 볼 수 있다.

​이는 패킷이 암호화되기 이전에 통신이기 때문에 해당 id 내용을 패킷을 직접 까서 확인할 수 있는데,

따라서 외부 id는 민감한 정보를 직접 사용해서는 안되고,

요청한 Client의 신원을 기록하기 위해서 수행되는 형식적인 과정으로 이해되었다.

보통은 Wifi 테스트 수행 시 Anonymous identity를 비워두고 연결을 요청했었는데, 

그렇게 되면 실제 id가 외부 id 대신 전송되서 패킷에 드러나게 된다.

이는 보안상으로는 조금 더 취약해지게 되는 것이어서 외부 ID를 작성해주는 것을 권장한다고 한다.

 

 

2. LDAP 서버에서 Client 신원 조회

​외부 id 검증은 앞서 얘기한 것처럼 외부 ID가 블랙리스트 처리가 되지 않았는지 등의 여부를 LDAP 데이터베이스에서 조회하며 수행한다.

외부 id가 아닌 실제 id의 인증 과정은​ TLS 터널이 생성된 이후에 암호화된 통신으로 수행하기에 ​
여기서는 실질적인 검증 과정을 수행하는 것은 아니다.

 

3. EAP 방식 확인

​검증을 마친 후 RADIUS 서버는 AP를 통해 Client에게 어떤 EAP 방식을 선택했는지 확인한다.

​클라이언트는 RADIUS 서버가 전송한 EAP 방식이 아니라면 NAK 를, 맞다면 Client Hello를 전송한다.

​패킷 분석 시 PEAP를 통해 요청했으므로

화면과 같이 TLS에서는 NAK를, PEAP에서는 Client Hello를 전송한 것을 확인할 수 있다.

 

 

 

4. TLS 암호화 통신 Tunnel Setup

 

 

EAP Method를 확인했다면 인증 정보를 전달받기 위한 암호화 통로인 TLS 터널을 생성하는 과정을 수행한다.

이때, TLS Handshake를 통해 RADIUS 서버의 인증서를 Client로 전송하는데, 

패킷의 크기가 인증서보다 작아 여러 단위로 쪼개서 전달을 수행하고 있다.

 

이때 따로 패킷의 내용을 직접 확인하면 해당 기업의 정보를 담고있는 내용을 직접 확인할 수 있는데,

이는 아직 패킷이 암호화되지 않았기 때문이고

이처럼 패킷을 직접 확인하는 해커들의 접근을 막기 위해 Tunnel을 Setup 한다고 이해하면 된다.

 

 

 

 

인증서 통신이 끝나면 클라이언트는 Server에게 받은 TLS 공개키를 통해 
이후 통신 내용을 암호화함을 서버에게 알리고 본격적으로 EAP 인증 과정을 시작한다.

 

5. Inner EAP MSCHAPv2 신원 요청 및 응답​

 

이후부터는 EAP 인증 방식을 통해 Client가 RADIUS 서버로부터 인증받는 과정인데,
TLS 터널링이 형성되었기 때문에 WireShark 패킷 분석으로 내부 데이터를 확인할 수는 없다.

따라서 절차의 순서 상, 주고 받는 데이터의 목적을 유추하며 분석을 계속 진행했다.

먼저 TLS 터널링 셋업이 되고 첫번째 데이터 왕래는 실제 Identity의 신원 검증이다.

초기 수행했던 외부 id 검증했던 방식과 동일하게 이번엔 실제 identity의 검증을 수행한다.

 

6. MSCHAPv2 Challenge EAP 요청 및 응답​

 

 

검증을 마치면 Client의 EAP를 검증한다.

PEAP의 MS-CHAPv2를 검증하는데 방법이 조금 특이했다.

먼저 서버에서 MS-CHAPv2 검증 요청 시에 난수를 전송하는데, 

클라이언트는 해당 난수를 받아서 비밀번호를 조합해 암호를 생성하여 서버에 전달한다.

그러면 서버는 가지고 있던 난수로 전달받은 암호를 복호화한다.
​
이러한 메커니즘은 비밀번호의 보안을 강화하는 목적으로 사용되었다.

 

7. MSCHAPv2 인증 결과 확인 및 최종적인 EAP 인증 완료​

 

 

검증을 완료하면 검증 결과를 Client에게 전달하는 통신 한번과 EAP 인증과정 완료에 대한 통신 한번으로 

EAP 인증을 마치겠다는 신호를 주고 받는다.

 

8. EAPOL 성공 메시지 전송 후 4-Hand shake 진행​

 

 

EAP 인증을 마쳤다는 통신을 잘 받은 Client가 확인 신호를 보내면 

이후 진행되는 4-handshake와 데이터 통신할 때 필요한 암호화 키를 전달하며 IEEE 802.1X의 인증과정은 끝이 난다.