본문으로 이동

제품 키

위키백과, 우리 모두의 백과사전.
시디키는 여기로 연결됩니다. 파키스탄 출신의 테러리스트에 대해서는 아피아 시디키 문서를 참고하십시오.
윈도우 비스타 홈 프리미엄의 정품 인증서(COA)에 적힌 제품 키

제품 키(product key) 또는 소프트웨어 키(software key), 시리얼 키 또는 활성화 키컴퓨터 프로그램을 위한 특정한 소프트웨어 기반의 키이다. 이는 해당 프로그램의 복사본이 정품임을 증명한다.

제품 키는 일련의 숫자나 문자로 구성된다. 이 시퀀스는 일반적으로 사용자가 컴퓨터 소프트웨어를 설치하는 동안 입력하며, 이후 프로그램 내의 검증 함수로 전달된다. 이 함수는 알고리즘이나 수학적 공식에 따라 키 시퀀스를 조작하고 그 결과를 유효한 해답 세트와 일치시키려 시도한다. 일치하면 프로그램이 활성화되어 사용이 허가되거나 기능이 해제된다. 프로그램의 역공학 등을 통해 사용된 알고리즘에 대한 지식을 얻으면, 특정 프로그램에 대한 이러한 키를 생성하는 키젠이라는 프로그램을 만드는 것이 가능하다.

효과

[편집]

제품 키가 수학적으로 생성되는 표준 키 생성 방식은 이러한 키들이 유포될 수 있기 때문에 소프트웨어 저작권 침해를 차단하는 데 완전히 효과적이지는 않다. 또한 인터넷의 발달로 통신이 개선되면서 크랙(키의 필요성을 제거함)이나 제품 키 생성기와 같은 키에 대한 더 정교한 공격이 흔해졌다.

이 때문에 소프트웨어 출판사들은 키가 유효하고 노출되지 않았는지 확인하기 위해 추가적인 제품 활성화 방법을 사용한다. 한 방법은 구매자의 컴퓨터 하드웨어의 고유한 특징에 따라 제품 키를 할당하는 것인데, 이는 사용자의 하드웨어에 의존하므로 쉽게 복제될 수 없다. 다른 방법은 인터넷 서버를 통해 제품 키를 일회성 또는 주기적으로 검증하는 것이다(온라인 요소가 있는 게임의 경우 사용자가 로그인할 때마다 수행됨). 서버는 유효하지 않거나, 중복되거나, 누락되었거나, 혹은 노출된 키를 제시하는 수정되지 않은 클라이언트 소프트웨어를 비활성화할 수 있다. 수정된 클라이언트는 이러한 확인을 우회할 수 있지만,[1] 서버는 여전히 해당 클라이언트의 정보나 통신을 거부할 수 있다.

예시

[편집]

윈도우 95 리테일 키

[편집]

윈도우 95 리테일 제품 키는 XXX-XXXXXXX 형식을 취한다.[2] 키가 유효한지 확인하기 위해 윈도우 95는 다음 사항을 확인한다.

  • 처음 3글자는 333, 444, 555, 666, 777, 888 또는 999와 같아서는 안 된다.
  • 마지막 7글자는 모두 0-8 사이의 숫자여야 한다.
  • 마지막 7개 숫자의 합은 7로 나누어 떨어져야 한다.
  • 네 번째 글자는 확인하지 않는다.

모든 확인을 통과하면 제품 키는 유효하다. 결과적으로 000-0000000과 같은 제품 키는 이러한 조건 하에서 유효한 것으로 간주된다.

윈도우 95 OEM 키

[편집]

윈도우 95 OEM 키는 XXXXX-OEM-XXXXXXX-XXXXX 형식을 취한다.

  • 처음 3글자는 0-366 사이의 숫자여야 한다.
  • 다음 2글자는 04-93 사이의 숫자여야 한다.
  • 다음 3글자는 OEM이어야 한다.
  • 다음 7개 숫자의 합은 7로 나누어 떨어져야 한다.
  • 나머지 글자는 확인하지 않는다.

윈도우 XP 리테일 키

[편집]

윈도우 XP는 활성화를 위해 설치 ID, 제품 ID 및 제품 키를 사용한다.[3][4]

설치 ID

[편집]

설치 ID는 6자리씩 8개 그룹과 마지막 2자리로 나뉘어 총 50자리의 10진수 문자열로, XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX 형식을 취한다. 설치 ID는 msoobe.exe가 실행될 때마다 다시 생성된다.

체크 디지트
[편집]

설치 ID의 각 그룹에서 가장 오른쪽에 있는 숫자는 체크 디지트이다.

  • 각 체크 디지트는 해당 그룹의 다른 다섯 자리를 더하여 계산된다.
  • 그런 다음 해당 그룹에서 짝수 위치에 있는 숫자를 한 번 더 더한다.
  • 그 합계를 7로 나눈다.
  • 나머지가 해당 그룹의 체크 디지트 값이 된다.
디코딩
[편집]

체크 디지트를 제거하면 41자리의 10진수로 인코딩된 136비트 다배정 정수가 되며, 이는 바이트 배열로서 리틀 엔디언 바이트 순서로 저장된다.

복호화
[편집]

설치 ID의 하위 16바이트는 암호화되는 반면, 가장 중요한 바이트는 평문으로 유지된다. 설치 ID를 암호화하는 데 사용되는 암호화 알고리즘은 독자적인 4라운드 파이스텔 암호이다. 파이스텔 암호에 전달되는 입력 바이트 블록은 동일한 크기의 두 블록으로 나뉘기 때문에, 이 종류의 암호는 일반적으로 짝수 바이트로 구성된 입력 블록(이 경우 17개 입력 바이트 중 하위 16개)에 적용된다. 암호의 라운드 함수는 4바이트 시퀀스로 키가 지정된 SHA-1 메시지 요약 알고리즘이다.

+를 두 바이트 시퀀스의 연결, ^를 XOR 연산, L과 R을 한 라운드에 대한 왼쪽 및 오른쪽 8바이트 입력 절반, L'과 R'을 해당 라운드의 출력 절반, 그리고 First-8()을 SHA-1 메시지 요약의 처음 8바이트를 반환하는 함수라고 하자.

그러면 복호화의 한 라운드는 다음과 같다.

L' = R ^ First-8(SHA-1(L + Key))

R' = L

복호화 결과는 16바이트의 평문이며, 암호화되지 않은 17번째 바이트와 함께 리틀 엔디언 바이트 순서의 4개 더블 워드와 그 뒤의 단일 바이트로 해석된다.

이름 크기 오프셋
H1 더블 워드 0
H2 더블 워드 4
P1 더블 워드 8
P2 더블 워드 12
P3 바이트 16

H1과 H2는 설치 ID가 연결된 하드웨어 구성을 지정한다. P1, P2 및 나머지 바이트 P3에는 설치 ID와 관련된 제품 ID가 포함된다.

제품 ID

[편집]

제품 ID는 AAAAA-BBB-CCCCCCC-DDEEE와 같이 5개의 10진수 그룹으로 구성된다.

디코딩
[편집]

10진수 표현의 제품 ID와 더블 워드 P1, P2 및 바이트 P3의 이진 인코딩 간의 매핑은 다음 표에 요약되어 있다.

자릿수 길이 인코딩 의미
AAAAA 17 비트 P1의 0비트부터 16비트까지 항상 55034 (윈도우 XP RC1 기준)
BBB 10 비트 P1의 17비트부터 26비트까지 원시 제품 키(Raw Product Key)의 상위 3자리
CCCCCCC 28 비트 P1의 27비트부터 31비트까지 (하위 5비트) 및 P2의 0비트부터 22비트까지 (상위 23비트) 원시 제품 키의 하위 6자리 및 체크 디지트
DDEEE 17 비트 P2의 23비트부터 31비트까지 (하위 9비트) 및 P3의 0비트부터 7비트까지 (상위 8비트) DD = 제품 키를 확인하는 데 사용되는 공개 키의 인덱스
EEE = 랜덤 값

제품 키

[편집]

제품 키는 XXXXX-XXXXX-XXXXX-XXXXX-XXXXX 형식을 취한다. 각 문자는 다음 24개의 문자와 숫자 중 하나이다: B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9

제품 키의 25개 문자는 제품 키의 이진 표현을 24진법으로 인코딩한 것이다. 제품 키는 약 115비트의 다배정 정수이며, 15바이트 배열에 리틀 엔디언 바이트 순서로 저장된다. 이 15바이트 중 하위 4바이트에는 리틀 엔디언 바이트 순서의 원시 제품 키가 포함된다. 최하위 비트는 이 32비트 값을 왼쪽으로 한 비트 위치 이동하여 제거된다. 나머지 11바이트는 디지털 서명을 형성하여 하드코딩된 공개 키를 통해 제품 키의 진위 여부를 확인할 수 있게 한다.

CCCCCCC 구성 요소를 얻기 위해 체크 디지트가 추가되며, 체크 디지트를 포함한 모든 숫자의 합이 7로 나누어 떨어지도록 선택된다. 제품 키를 확인하기 위해 두 개 이상의 공개 키 암호 방식 공개 키를 사용할 수 있다. 첫 번째 공개 키로 확인에 실패하면 두 번째 키를 시도하는 식이다. 제품 ID의 DD 구성 요소는 이 시퀀스의 공개 키 중 어느 것이 제품 키를 확인하는 데 성공적으로 사용되었는지를 지정한다.

하드웨어 정보 비트 필드
[편집]

설치 ID와 연결된 하드웨어 구성은 두 개의 더블 워드 H1과 H2로 표현된다. 이를 위해 더블 워드는 12개의 비트 필드로 나뉜다.

더블 워드 오프셋 길이 비트 필드 값 기준
H1 0 10 시스템 볼륨의 볼륨 일련번호 문자열
H1 10 10 네트워크 어댑터 MAC 주소 문자열
H1 20 7 CD-ROM 드라이브 하드웨어 식별 문자열
H1 27 5 그래픽 어댑터 하드웨어 식별 문자열
H2 0 3 사용되지 않음, 001로 설정
H2 3 6 CPU 일련번호 문자열
H2 9 7 하드 드라이브 하드웨어 식별 문자열
H2 16 5 SCSI 호스트 어댑터 하드웨어 식별 문자열
H2 21 4 IDE 컨트롤러 하드웨어 식별 문자열
H2 25 3 프로세서 모델 문자열
H2 28 3 RAM 크기
H2 31 1 1 = 도킹 가능, 0 = 도킹 불가

도킹이 가능한 경우, 활성화 메커니즘은 향후 하드웨어 변경에 대해 더 관대한 기준을 적용한다. 나머지 10개 비트 필드 중 하나에 해당하는 하드웨어 구성 요소가 있는 경우, 해당 비트 필드에는 해당 구성 요소를 설명하는 0이 아닌 값이 포함된다. 0 값은 하드웨어 구성 요소가 없음을 나타낸다. 모든 하드웨어 구성 요소는 레지스트리에서 가져온 하드웨어 식별 문자열로 식별된다. 이 문자열을 해싱하면 해당 비트 필드의 값이 제공된다.

해싱
[편집]

해시 결과는 하드웨어 식별 문자열을 MD5 메시지 요약 알고리즘에 입력하고 결과 메시지 요약의 미리 정해진 위치에서 비트 필드에 필요한 비트 수를 선택하여 얻는다. 비트 필드마다 서로 다른 미리 정해진 위치가 사용된다. 또한, 을 계산하여 해시 결과가 0이 되는 것을 방지한다. 여기서 BitFieldMax는 해당 비트 필드에 저장될 수 있는 최대값(예: 10비트 비트 필드의 경우 1023)이며, 'x % y'는 x를 y로 나눈 나머지를 나타낸다. 결과 값은 1에서 BitFieldMax 사이가 된다. 얻은 값은 해당 비트 필드에 저장된다.

RAM 비트 필드
[편집]

운영 체제가 사용할 수 있는 RAM 용량과 관련된 비트 필드는 표에 표시된 대로 다른 비트 필드와 다르게 계산된다.

가능한 RAM 용량
0 (비트 필드 미사용)
1 32 MB 미만
2 32 MB에서 63 MB 사이
3 64 MB에서 127 MB 사이
4 128 MB에서 255 MB 사이
5 256 MB에서 511 MB 사이
6 512 MB에서 1023 MB 사이
7 1023 MB 초과

RAM 용량은 GlobalMemoryStatus() 함수를 호출하여 가져오는데, 이 함수는 물리적으로 설치된 RAM 용량보다 몇 백 킬로바이트 적게 보고한다. 따라서 128 MB의 RAM은 일반적으로 "64 MB에서 127 MB 사이"로 분류된다.

하드웨어 변경

[편집]

wpa.dbl은 만료 정보, 활성화된 설치의 확인 ID, 현재 하드웨어 구성을 나타내는 비트 필드 값, 제품 활성화 당시의 하드웨어 구성을 나타내는 비트 필드 값 등을 저장하는 RC4 암호화 데이터베이스이다. 현재 하드웨어 구성은 변경 사항을 반영하기 위해 하드웨어 구성이 수정될 때마다 자동으로 업데이트되지만, 제품 활성화 당시의 하드웨어 구성을 나타내는 값은 고정된다. 재활성화가 필요한지 판단할 때 현재 하드웨어 구성의 비트 필드 값을 활성화 당시의 하드웨어 구성과 비교한다.

도킹 불가 컴퓨터
[편집]

사용되지 않는 필드와 '도킹 가능' 필드를 제외한 모든 비트 필드를 비교한다. 제품 활성화 이후 현재 하드웨어 구성에서 이 10개 비트 필드 중 3개 이상이 변경된 경우 재활성화가 필요하다.

도킹 가능 컴퓨터
[편집]

H2의 31번 비트가 컴퓨터가 도킹 스테이션을 지원함을 나타내는 경우, 위에서 언급한 10개 비트 필드 중 7개만 비교한다. SCSI 호스트 어댑터, IDE 컨트롤러 및 그래픽 카드에 해당하는 비트 필드는 생략된다. 이 남은 7개 비트 필드 중 최대 3개까지만 변경되어야 재활성화 없이 사용할 수 있다.

논란

[편집]

가장 효과적인 제품 키 보호 방식 중 일부는 불편함, 엄격한 집행, 가혹한 처벌, 그리고 일부 경우 오탐지로 인해 논란의 여지가 있다. 일부 제품 키는 라이선스 계약을 강제하기 위해 타협 없는 디지털 절차를 사용한다.

불편함

[편집]

제품 키는 최종 사용자에게 다소 불편하다. 프로그램을 설치할 때마다 입력해야 할 뿐만 아니라, 사용자가 키를 분실하지 않도록 주의해야 한다. 제품 키를 분실하면 삭제 전 키 복구 애플리케이션을 사용하지 않는 한(모든 프로그램이 이를 지원하는 것은 아님), 소프트웨어를 삭제한 후에는 무용지물이 된다.[5]

제품 키는 유통 과정에서 문제가 발생할 수 있는 새로운 가능성도 제공한다. 제품이 키가 누락되거나 유효하지 않은 상태로 배송되면 제품 자체가 무용지물이 된다. 예를 들어, 스플린터 셀: 판도라 투머로우의 오스트레일리아 배송본 전체가 원래 제품 키 없이 배송된 적이 있다.[6]

집행 및 처벌

[편집]

기업이 사용 위반을 감지하여 영구 정지를 집행하는 사례가 많다. 온라인 시스템이 크랙이나 일부 경우 치트 사용이 적발된 계정을 즉시 블랙리스트에 올리는 것은 흔한 일이다. 이는 영구 정지로 이어진다. 소프트웨어를 계속 사용하려는 플레이어는 소프트웨어를 다시 구매해야 한다. 이는 필연적으로 영구 정지 집행의 동기에 대한 비판으로 이어졌다.

특히 여러 제품의 키가 하나로 묶여 있는 상황이 논란이 된다. 제품이 다른 제품에 의존성을 갖는 경우(확장팩의 경우처럼), 기업이 묶여 있는 모든 제품을 정지시키는 것이 일반적이다. 예를 들어 확장팩에서 가짜 키를 사용하면 서버가 원본 게임의 정품 키까지 정지시킬 수 있다. 마찬가지로 밸브의 스팀 서비스의 경우 사용자가 구매한 모든 제품이 하나의 계정에 묶여 있다. 이 계정이 정지되면 사용자는 동일한 계정과 연결된 모든 제품에 대한 접근 권한을 잃게 된다.[7]

이러한 "다중 정지"는 사용자가 정당하게 구매하고 사용해 온 제품까지 금지하기 때문에 매우 논란이 많다.

오탐지

[편집]

정지는 일반적으로 사람의 개입 없이 크랙이나 치트가 감지되는 즉시 서버에 의해 집행된다. 때때로 정당한 사용자가 라이선스 위반으로 잘못 판단되어 정지되기도 한다. 대규모 오탐지 사례의 경우(월드 오브 워크래프트에서 발생한 것처럼) 때때로 수정되기도 한다.[8] 그러나 개별적인 사례는 주목받지 못할 수 있다.

오탐지의 흔한 원인(위의 월드 오브 워크래프트 사례와 같이)은 지원되지 않는 플랫폼 사용자이다. 예를 들어 리눅스 사용자는 와인이나 Cedega와 같은 호환성 계층을 통해 윈도우 애플리케이션을 실행할 수 있다. 이러한 소프트웨어 조합은 때때로 게임 서버의 안티 치트 소프트웨어를 작동시키는데, 와인이나 Cedega가 리눅스용 윈도우 API 호환성 계층이기 때문에 게임 서버에 의해 제3자(치트) 소프트웨어로 간주되어 정지될 수 있다.[9]

같이 보기

[편집]

각주

[편집]
  1. Chang, Hoi; Atallah, Mikhail J. (2002). Protecting Software Codes by Guards. Security and Privacy in Digital Rights Management. Springer. 160-175쪽. doi:10.1007/3-540-47870-1_10. ISBN 978-3-540-47870-6.
  2. Upadhyay, Saket (2021년 5월 14일). Reversing Microsoft's Windows95 Product Key Check Mechanism.
  3. Purdy, Kevin (2023년 5월 26일). Green hills forever: Windows XP activation algorithm cracked after 21 years (미국 영어). Ars Technica. 2024년 6월 29일에 확인함.
  4. Chaussee, Rudower (July 2001). Inside Windows Product Activation. Licenturion. 2024년 6월 28일에 확인함.
  5. ProduKey - Recover lost product key (CD-Key) of Windows/MS-Office/SQL Server. NirSoft. 2021년 2월 9일에 확인함.
  6. Australian Pandora Tomorrow CD-Key Problems Shack News
  7. Valve suspends 20,000 Steam accounts. GameSpot. 2013년 5월 15일에 확인함.
  8. Blizzard Unbans Linux World of Warcraft Players Softpedia
  9. Linux users banned from Diablo 3- End Gamers. 2012년 7월 10일에 원본 문서에서 보존된 문서. 2012년 8월 14일에 확인함.