보안 초보의 라이브 게임 보안 설계 이야기

 

블록체인 게임사의 CTO로 일할 때, RPG 게임을 블록체인화 하는 계약을 체결했다.

블록체인 영역은 우리가 개발하고 게임 개발은 상대 개발사가 맡은 뒤 우리 블록체인 플랫폼에서 퍼블리싱 하는 계약이었다.

 

감사하게도 엑시 인피니티로 인해 P2E 시장의 붐으로 우리는 업비트 상장폐지라는 대형 악재를 맞았음에도 글로벌로 주목을 받게 되었다.

 

게임 출시 전에 우리 플랫폼에서 NFT 사전판매를 진행했는데 11만개 가량 판매를 완료했다.

 

여러 라운드로 나눠 진행한 NFT 선착순 판매가 수 초 안에 마감되는 등 당시 한국의 어떤 기업도 내지 못한 독보적인 성과를 냈고, 바이낸스 등 여러 글로벌 회사들이 먼저 우리에게 연락해 오며 다양한 행사에 공식적으로 참가하는 등 우리 프로젝트는 순항 중이었다.

 

그런데 오픈 전, 게임 개발사의 테스트 빌드를 미리 받아 테스트를 진행해 보는데 심각한 버그를 보게 되었다.

나는 게임 내 재화로 뽑기를 해서 아이템을 획득하는 시나리오를 진행해 보고 있었는데, 뽑기 버튼을 눌렀는데 동작하지 않아서 버튼을 연타했더니 재화만 차감되고 뽑기는 진행되지 않는 현상을 발견했다.

 

뽑기가 동작하지 않거나, 게임 자체가 특정 오류로 동작하지 않았으면 그럴 수 있다고, 고치면 된다고 생각했을 것이다.

 

하지만 저런 데이터 정합성 이슈는 담당 개발자의 기본적인 역량과 직결된 문제라 이것 외에도 게임에 많은 문제가 있을 것이라고 판단되어 해당 버그 리포팅과는 별개로 개발사에 적극적으로 개발을 도와주겠다고 얘기했다.

 

하지만, 당시 개발사는 자존심의 문제로 우리에게 개발과 관련된 그 어떤 정보제공도 하지 않았으며, 본인들이 잘할 수 있다고 답변을 해올 뿐이었다.

 

나는 어쩔 수 없이 모의해킹이라고 하기에도 민망한 수준으로 패킷 스니핑을 하며 게임의 패킷을 지켜봤는데, 그냥 클라이언트에서 재화 수치만 바꾸고 서버로 저장 패킷을 보내면 그대로 저장하는 구조이더라.

 

발견 즉시 개발사에게 피드백을 해주었고, 고쳤다는 답변을 받은 후 몇 주 뒤에 서비스를 오픈했는데 아니나 다를까 오픈 후 아이템 및 재화 복사가 수 시간 안에 발생되었다.

 

또한, NFT를 11만장 가량 판매한 만큼 수만 명의 유저가 우리 게임의 오픈을 기다리고 있었는데 하드웨어 스펙을 높게 잡았다고 들었음에도 불구하고 오픈 후 수십 초 안에 서버가 다운되는 현상이 빈번하게 발생되었다.

 

다운될 때마다 계속 높였다고 하는데도 오픈 후 조금 있으면 터지고의 반복이었고 버그도 굉장히 많아 도저히 서비스를 할 상황이 아니었다.

 

우리는 유저들에게 게임 완성도가 낮아 사과 후 서버를 임시로 종료하며 한 달 후 오픈하겠다는 공지를 했고, 게임 개발사를 설득하여 개발에 대한 전권을 얻어냈다.

 

이 포스팅에서는 게임 서버를 완전히 갈아엎으며 게임 보안에 대한 설계를 어떻게 결정하고 진행했는지 정리하고자 한다.

* 슬프게도 이 게임은 이제는 서비스를 종료하여 잊혀진 프로젝트가 되었다. 유저는 많았으나 우리가 새로이 개발한 후 개발사에게 인수인계를 했지만 이후 업데이트가 원활히 이루어지지 않았다.

 

(1) 게임의 보안은 99% 완벽할 수 없다

게임의 보안이 완벽하려면 방법은 단 한 가지밖에 존재하지 않는다.

클라이언트에서 보여지는 모든 행위들을 서버에서 계산하고, 클라이언트는 서버가 계산한 것들을 "콘솔"로서의 역할만 수행하는 것이다.

 

예를 들어, 캐릭터가 이동하다가 벽을 마주했는데 유저가 이동 액션을 하려고 한다고 가정하자.

대부분의 게임은 맵 데이터를 클라이언트에서 보유하고, 클라이언트에서 캐릭터의 이동이 되지 않게 막는다.

 

그러나 서버 시뮬레이션 방식을 도입한다면 유저가 발생시킨 인풋 액션을 서버로 보내고, 서버에서 이동한 좌표를 클라이언트로 보내어 처리하게 된다.

위의 예시에서는 벽이어서 이동이 되지 않으니 좌표를 변경하지 않은 채로 클라이언트에 패킷을 전송하는 것이 되겠다.

 

 

 

조금 더 쉽게 이해하자면, 최근 트렌드 기술 중 하나인 클라우드 게이밍과 느낌이 유사하다.

 

차이점은 클라우드 게이밍은 서버에서 그래픽 등 컴퓨팅 자원을 크게 소모하는 작업까지 한 후 영상 결과물을 스트리밍 하는 것이라면 이건 서버에서 필수 작업들만 시뮬레이션 후 실제 그래픽을 찍어내는 등의 작업은 클라이언트에서 한다는 점이다.

 

하지만 우리는 문서도 없는 상황에서 게임 클라이언트에만 구현된 기획 내용을 세세하게 전부 이해하여 시뮬레이션 하기에는 시간이 턱없이 부족했기에 몬스터의 수치, 유저의 전투력 및 대미지 등 최소한의 어뷰징 및 조작을 할 수 없도록 서버에서 처리를 했다.

 

 

 

(2) SSL 보다 상위 레이어에서 암호화를 적용하자

모바일 게임 점유율이 올라가며 게임 서버에 웹을 적용하는 것은 어느덧 당연한 시대가 되었다.

다양한 이유로 수시로 아이피가 변경되는 상황에서 웹으로 게임서버를 개발한다는 것은 오히려 게임이 커넥션 중단이 없는 것처럼 매끄럽게 보이게 되어 굉장히 큰 장점이 있다.

 

해당 게임도 대부분 웹으로 개발되어 있었는데 SSL 이상의 암호화가 필요하다고 판단했다.

 

SSL 프로토콜은 HTTP와 TCP의 중간에 위치한 레이어로, HTTPS에서는 HTTP 메시지가 암호화 되기는 하지만 주의할 점이 있다.

SSL은 현재 PC를 벗어난 라우팅 과정에서 스니핑을 방지할 때에나 유의미한 결과를 얻을 수 있다. 즉, 로컬 PC에서는 의미가 없다.

생각해 보면 너무 당연하다. 암호화 하기 전의 패킷 콘텐츠는 고스란히 로컬 PC에 있기 때문이다.

 

더군다나, SSL은 굉장히 범용적이기 때문에 별도의 개발/분석 없이 로컬 HTTPS 패킷을 평문으로 캡쳐할 수 있는 툴도 시중에 나와있다.

 

따라서 통신에 필요한 HTTP 프로토콜을 제외한 나머지 내용들은 Body로 전송했고, Body 영역 전체를 암호화했다.

 

 

 

(3) 암호화 키를 통신 없이 Real-time으로 변경하자

제일 고민을 많이 하고 신경을 썼던 부분이다.

리서치와 팀원 및 지인들과 대화를 나누며 토론했을 때, 가장 좋은 구조는 암호화 키를 주기적으로 변경하는 것이었다.

 

그렇지만 암호화 키를 서버 <-> 클라이언트끼리 통신하고 싶지는 않았다.

여기서 생각난 아이디어가 바로 OTP이다.

 

OTP는 크게 HOTP와 TOTP로 나뉘는데, 나는 TOTP에 착안했다.

TOTP는 특정 Secret Key에서 주기적인 시간 기반으로 변경된 결과를 계산해 주는 알고리즘이다.

 

실생활에서는 은행 업무나 로그인 2차인증 등에서 많이 사용되기도 한다.

 

내가 생각한 구조는 서버, 클라이언트 모두 같은 Base Key를 두고, TOTP를 오프셋으로 한 키를 추가로 생성 후 이를 해싱하는 것이다.

 

여기서 주의할 점은 클라이언트의 시스템 시간은 유저가 OS 설정에서 수정할 수 있으므로 신뢰해서는 안 된다는 것이다.

그래서 게임 최초 실행 시 클라이언트에서 시스템 시간을 사용하는 것이 아닌 서버의 시간으로 초기화 하는 작업이 필요하다.

 

그리고, 통신 도중 TOTP의 오프셋이 변경될 가능성도 있었기 때문에 실제로 암호화를 진행한 시간도 함께 패킷에 포함했었고 서버에서 시간이 수 초 이상 지나지 않은 것이라면 해당 시간으로 초기화 후 TOTP 오프셋을 도출하여 복호화 키를 만들어냈다.

 

 

결과

서비스는 큰 문제없이 한 달 뒤에 잘 오픈했고 우려했던 해킹 이슈는 서비스 운영 도중 단 한 건도 발생하지 않았다.

 

거창하게 설명하고 고민을 많이 했던 것 같지만 사실 시간이 굉장히 부족했다.

중요한 고민이었음에도 최종 의사결정까지 반나절 정도 소요했다.

보안 설계만 한 것이 아니라 게임의 전반적인 아키텍처를 재구성해야 했으므로 그 이상의 시간을 사용할 수도 없기는 했다.

 

몸을 갈아대며 개발했던 서비스이고 전성기 시절에는 스팀으로 치면 게임 최상위권에 들어갈 정도의 동시접속이 발생할 정도로 많은 유저에게 사랑받는 게임이었는데 서비스 종료가 아쉬울 따름이다.