기본적으로 세 가지 요구 사항이 있습니다.
- 여러 클라이언트 인스턴스에 동일한 키를 사용하는 것은 쉽지 않습니다.
- 유효한 새 키를 생성하기 쉽지 않아야합니다.
- 합법적 인 고객의 열쇠를 훔치기가 쉽지 않습니다.
첫 번째 부분은 매우 간단합니다. 두 명의 플레이어가 같은 키를 사용하여 같은 서버에 동시에 로그인하지 못하게하십시오. 서버가 로그인 한 사용자에 대한 정보를 교환하거나 공유 인증 서버에 접속하도록하여 서로 다른 서버의 다른 플레이어에 대해 동일한 키를 사용하더라도 동시에 실패 할 수 있습니다. 또한 의심스러운 키 사용 패턴을 찾아보고 키가 누출 된 것으로 확인되면 금지 된 키 목록에 추가하십시오.
두 번째 부분의 한 가지 방법은 모든 유효한 발급 키의 데이터베이스를 유지 관리하는 것입니다. 키가 충분히 길고 (예 : 128 비트 이상) 무작위로 (보안 RNG를 사용하여) 선택하는 한 유효한 키를 추측 할 수있는 사람은 기본적으로 0입니다. (실패한 로그인으로 실패한 로그인 시도에 일종의 속도 제한을 사용하여 무차별 강제로 유효한 키를 찾으려고 시도하는 경우 훨씬 더 짧은 키도 안전 할 수 있습니다.)
또는 고유 식별자를 사용하고 비밀 마스터 키를 사용하여 계산 된 메시지 인증 코드 (예 : HMAC )를 추가하여 키를 생성 할 수 있습니다 . 다시 말하지만, MAC이 충분히 길다면 마스터 키를 모르는 사람이라면 누구나 ID에 대해 유효한 MAC을 추측 할 가능성은 무시할 수 있습니다. 이 방법의 한 가지 장점은 키 데이터베이스의 필요성을 제거하는 것 외에도 식별자가 고유 한 문자열 일 수 있으며 키가 발행 된 클라이언트에 대한 정보를 인코딩 할 수 있다는 것입니다.
MAC 사용의 한 가지 문제점은 공식 게임 서버 (또는 최소한 인증 서버)가 MAC을 확인하기 위해 마스터 키를 알아야한다는 것입니다. 즉, 서버가 해킹되면 마스터 키가 유출 될 수 있습니다. 이 위험을 완화하는 한 가지 방법은 다른 마스터 키를 사용하여 각 ID에 대해 여러 개의 MAC을 계산하는 것이지만 마스터 서버 중 하나만 게임 서버에 저장하는 것입니다. 이렇게하면 해당 마스터 키가 유출되어 가짜 ID를 생성하는 데 사용 된 경우이를 취소하고 다른 마스터 키로 전환 할 수 있습니다. 또는 MAC을 디지털 서명으로 대체 할 수 있으며 마스터 키의 공개 절반 만 사용하여 확인할 수 있습니다.
세 번째 부분의 한 가지 방법은받는 사람이 실제로 합법적 인 공식 서버인지 확인하지 않고 클라이언트가 다른 사람에게 키를 보내지 않도록하는 것입니다. 예를 들어, 로그인 프로세스에 SSL / TLS (또는 DTLS )를 사용하고 게임 서버에 대한 사용자 지정 인증서를 발급하며 클라이언트가 발급 한 클라이언트 신뢰 인증서 만 가질 수 있습니다. 편리하게도 TLS를 사용하면 공용 WLAN 등의 도청으로부터 클라이언트 키 (및 기타 인증 데이터)를 보호 할 수 있습니다.
불행히도이 방법은 타사 서버가 원하는 경우에도 클라이언트 키를 확인할 수 없습니다. 타사 게임 서버가 사용할 수있는 공식 인증 서버를 설정하여 (예 : 클라이언트가 인증 서버에 로그인하여 서버에 로그인하는 데 사용할 수있는 임의의 일회용 토큰을 받음)이 문제를 해결할 수 있습니다. 게임 서버 (토큰을 인증 서버에 제출하여 확인)
또는 실제 클라이언트 인증서 또는 이와 유사한 인증서를 클라이언트에 발급 할 수 있습니다. 클라이언트 인증서 인증 (권장)을 지원하는 기존 프로토콜 (TLS와 같은)을 사용하거나 다음과 같이 고유 한 프로토콜을 구현할 수 있습니다.
- 클라이언트 인증서는 임의의 ID 문자열, 공개 / 개인 키 쌍 및 마스터 키를 사용하는 ID 및 공개 키의 디지털 서명으로 구성됩니다.
- 로그인하기 위해 클라이언트는 자신의 ID, 공개 키 및 서명을 보냅니다. 서버는 클라이언트가 개인 키로 서명하고 (키를 알고 있음을 증명하기 위해) 서버에 서명을 보내는 고유 한 챌린지 문자열 (바람직하게는 서버 ID 및 클라이언트가 확인해야하는 타임 스탬프를 포함)으로 응답합니다.
- 서버는 두 가지 서명을 모두 검사하여 ID + 공개 키가 합법적 인 클라이언트 키를 형성하고 (마스터 키로 서명 했으므로) 클라이언트 키가 실제로 클라이언트에 속한다는 것을 증명합니다 (클라이언트가 개인과의 서버 챌린지에 서명 할 수 있으므로) 키).
(이 프로토콜은 클라이언트가 서버 ID와 타임 스탬프로 구성된 "도전"을 생성하고 서명함으로써 더 단순화 될 수 있습니다. 물론 서버는 ID와 타임 스탬프가 유효한지 확인해야합니다. 이 간단한 프로토콜만으로도 중개인 공격자가 클라이언트 세션을 가로채는 것을 막을 수는 없지만 향후 로그인에 필요한 클라이언트의 개인 키를 얻을 수는 없습니다.)