it-swarm-korea.com

라이센스 키 / 일련 번호 생성기 및 검사기

일련 번호 생성기와 함께 제공되는 검사기가 필요합니다. 나는 소금 (그리고 아마도 길이)을 설정할 수 있기를 원합니다. 생성기는 검사기의 테스트를 통과 한 일련 번호 만 생성해야합니다. 이 숫자는 주어진 길이에서 가능한 모든 숫자의 작은 부분만을 설명해야합니다.

알고리즘 암호 적으로 안전하지 않아야 함. 오히려 (자바 스크립트로) 구현하기가 매우 쉬워야하며 매우 빠릅니다.

확인하려면 : 상용 소프트웨어를 구입하는 경우 때로는 일련 번호/키로 보호됩니다. 입력하면 큰 데이터베이스를 검색하지 않고 소프트웨어가 특정 속성을 충족하는지 확인하여 알고리즘 방식으로 확인합니다. 또한 키가 모두 수작업이 아닌 알고리즘 방식으로 생성되었다고 확신합니다. 주어진 길이의 가능한 모든 키 중 작은 부분 만 실제로 유효하므로 키를 추측하기가 어렵습니다.

솔트 : 솔트가 올바른 단어인지는 모르겠지만 알고리즘에는 하나 이상의 매개 변수가 있어야합니다.이 매개 변수는 생성 된 키를 변경하여 여러 사람이 동일한 알고리즘을 사용할 수 있고 충돌을 두려워 할 필요가 없습니다.

16
Dave

보안이 실제로 필요하지 않은 경우 검사기를 갖춘 매우 빠른 일련 번호 생성기가 있습니다.

  • 카운터를 사용하십시오. 0에서 초기화하십시오. 새 일련 번호를 원할 경우 카운터를 1000 씩 늘리십시오. 새 카운터 값은 일련 번호입니다. 체커는 다음과 같이 작동합니다. 일련 번호가 3으로 끝나는 경우 유효합니다. 체커는 1000 개의 숫자 중 하나만 허용합니다.

이 솔루션이 마음에 들지 않으면 do 보안이 필요하며 암호화가 필요합니다.

암호로 안전한 솔루션은 일련 번호에 서명 한 것입니다. 일련 번호는 일부 페이로드 (예 : 생성 한 모든 일련 번호의 카운터)의 인코딩 및 페이로드에 대한 서명입니다. 생성기에는 서명을 계산하는 데 사용되는 개인 키가 있습니다. 검사기는 해당 공개 키만 알고 있습니다. 이 설정의 문제점은 실제로 자바 스크립트에서도 검증 시간에 관한 것이 아닙니다. 오히려 그것은 문제의 서명의 size입니다. 일련 번호는 어느 시점에서 사용자가 입력한다고 가정합니다. 암호로 안전한 서명의 이론상 최소 크기는 약 80 비트입니다 (서명은 공개 키로 만 확인할 수 있기 때문에 공격자는 가능한 모든 비트 시퀀스를 시도 할 수 있으며 일반적으로 최소 2 이상의 보안 수준이 필요합니다)80). 그러나 "안전하다고 가정"중 가장 작은 서명은 160 비트에 가깝습니다 ( BLS ). 구현하려면) 또는 320 비트 ( DSA 또는 ECDSA ) 서명이 더 짧은 서명 시스템 ( Quartz 또는 McEliece-Niederreiter )이있는 서명 시스템에 대한 작업이 있지만 보안에 대한 논란이 있습니다.

대문자와 숫자 (36 개의 가능한 문자, 그리고 'I'와 '1', 그리고 'O'와 '0')를 모두 사용하더라도 160 비트 서명은 31자를 사용합니다. 페이로드와 함께 길이가 35 정도 인 일련 번호로 끝날 것입니다. 일반 사용자가 입력하기에는 너무 많을 수 있습니다 (그러나 큰 마진이 아니라 80 비트 서명이 잘 맞습니다).

서명 체계를 사용하지 않으면 합리적으로 결정된 공격자 will 일부 해체를 통해 체커를 우회하거나 검사 할 수있을 정도로 충분히 배울 수 있음을 알아야합니다. 자신의 일련 번호를 생성하십시오 (체커가 행복하게 받아 들일 것입니다). 그 시점에서, 당신은 정량화 된 보안을 얻지 못할 것입니다. "내 계획은 최대 38 억 달러의 예산까지 안전합니다"라고 말할 수 없습니다. "제대로 짜여진 지루한 학생이 와서 검사원 코드를 리버스 엔지니어링하고 결과를 Facebook에 게시 할 때까지 제 계획은 안전합니다".

실제로 안전하지 않은 고전 체계는 다음과 같습니다.

  • 이전 구성표의 카운터를 사용하십시오 (세 개의 0으로 끝나는 것). 64 비트 블록으로 인코딩하십시오. 블록 암호를 사용하여 하드 코딩 된 대칭 키로 해당 블록을 암호화하십시오. 검사기는 키를 알고 있으며 동일한 하드 코드 된 대칭 키를 사용하여 키를 해독하고 최종 0을 확인하여 일련 번호를 확인합니다.

이것은 평범한 카운터보다 실제로 안전하지는 않지만 최소한 일련 번호는 무작위로 보입니다. 알파벳 34 자 ( 'O'및 'I'를 제외한 숫자 및 대문자)의 64 비트 블록에는 13자가 필요합니다 (일반적인 Microsoft 일련 번호는 25 자임). 64 비트 블록 암호의 경우 XTEA 를 권장합니다. 구현하기에 빠르고 간단해야합니다.

26
Thomas Pornin

암호로 안전한 방법을 원한다면 인터넷 연결을 통해 시리얼을 확인하지 않아도됩니다. 즉, 이러한 보호 체계는 기존 선반 소프트웨어보다 가입 기반 소프트웨어에 더 적합합니다.

인터넷 연결을 사용하면 간단합니다 (JS를 사용하기 때문에 원하는 것으로 가정합니다).

  1. 누군가 열쇠를 만들면 상대방은 비밀을 알아야합니다
  2. 서버는 비밀을 알고 데이터를 해독 할 수 있습니다
  3. 클라이언트는 Base32 로 인코딩 된 이진 Blob 인 키를 보냅니다 ( this 참조).
  4. 서버는 키를 해독하고 키가 유효한지 (구문 적으로 또는 의미 적으로) 확인합니다.

인터넷에 연결되어 있지 않아도 사용자가 입력 한 얼룩이 사용자에 의해 생성되도록 verify PGP 서명과 비슷한 구성표를 계속 사용할 수 있습니다. 암호 해독은 항상 비밀을 알아야하고 여기에서 큰 문제는 다음과 같이 암호화가 동일하게 작동하지 않습니다.

  1. 사용자를 신뢰하지 않습니다 (그렇지 않으면 보호 체계가 필요하지 않습니다)
  2. 바이너리로 컴파일 된 비밀을 사용자에게 제공합니다.

분명히 두 지점이 서로 모순됩니다. 한편으로는 사용자를 신뢰하지 않는 반면, 암호 해독에 사용되는 비밀을 배포해야합니다.

인터넷 연결과 서버 기반 유효성 검사 없이는 어떤 지식 (예를 들어, 오랫동안 만 유용한 콘텐츠)의 계시를 초래한다는 결론을 내릴 필요가 있습니다. 지금까지 크래커와 공급 업체 간의 무기 경쟁이 어느 정도인지 보았습니다.


이제 암호로 안전한 시스템을 갖추는 것이 중요하지 않다면 간단한 CRC 등을 사용하여 보안을 유지할 수있는 이진 데이터를 계속 사용할 것입니다. 생각 나는 것은 :

  1. 단조 증가하는 일련 번호를 가짐
  2. 소금 값 (또는 다른 가역적 조작)으로 XOR
  3. 그 가치의 CRC32 (또는 Adler32 또는 무엇이든)를 가져 가십시오-필요한 경우 여기에 소금을 더 넣으십시오
  4. Base32 (읽기 쉬움 등)으로 인코딩하십시오.
  5. CRC32가 유효한지 확인하십시오 ...
6
0xC0000022L

OP는 "자바 스크립트로 구현하기가 매우 쉬워야하고 매우 빠르다"고 썼다.

"자바 스크립트에서"가 생성기 또는 검사기 또는 둘 다를 나타내는 지 또는 "브라우저에서 자바 스크립트"를 나타내는 지 또는 다른 Java/ecmascript 구현 (예 : 웹 서버의 서버 측)을 나타내는 지 여부는 확실하지 않습니다.

구현 언어로서의 자바 스크립트가 반드시 문제가되는 것은 아니며 자바 스크립트 (MD5, DES, AES, SHA, PBKDF2, HMAC 지원)를위한 몇 가지 암호화 라이브러리가 있습니다.

속도는 너무 큰 문제가되어서는 안됩니다 (IE6/7을 지나면 브라우저 자바 스크립트 엔진이 그 점에서 상당히 유용 해집니다).

그러나 위의 어느 것도 공개 키 암호화를 지원하지 않습니다 ( "체커"가 신뢰할 수없는 사용자에게 배포되어 일련 번호를 만드는 데 사용 된 키에 액세스 할 수없는 경우 보안에 필요함). 토마스. 구글은 자바 스크립트에서 공개 키 구현에 대한 히트를 쳤다 (http://www-cs-students.stanford.edu/~tjw/jsbn/, http://ohdave.com/rsa/ =, http://www.hanewin.net/encrypt/rsa/rsa.htm ) 그러나 개인적으로 나는 위의 "더 큰"라이브러리보다 버그가없는 것에 대해 더 긴장할 것입니다. .

공개 키 기반 접근 방식을 사용하더라도 생성자 또는 검사기가 신뢰할 수없는 사용자에게 배포 된 경우 체계가 안전하지 않을 수 있습니다. 생성자 코드를 신뢰할 수없는 사용자가 사용할 수있는 경우 원하는만큼 키를 생성 할 수 있지만, 신뢰할 수없는 사용자가 검사기를 사용할 수있는 경우 검사를 건너 뛰기 위해 간단히 자바 스크립트 코드를 수정할 수 있습니다. 물론 동일한 문제가 네이티브 코드에서도 발생하지만 난독 처리를하더라도 JavaScript는 로컬 수정을 통해 공격하기가 훨씬 간단합니다.]

JavaScript로 보안 체계를 구현하기 전에 더 넓은 신뢰 문제를 고려해야합니다. http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ 유용한 요약을 위해.

3
Misha