나는 사용자에게 암호화 된 형식으로 라이센스를 보낼 수있는 작은 프로그램을 만들었습니다. 순간라이센스 파일의 정적 또는 무작위 IV
내가 가진
AES와 공개 키는 모두 장치에 하드 코딩되어 있습니다.
라이센스를 요청할 때 IV를 처리해야합니까? 생성 된 새 라이센스마다 디바이스에 정적 버전을 만들거나 새로운 라이센스를 보내야합니까?
대부분의 라이선스 체계와 마찬가지로 내가하려는 일을 이해한다면 기본적으로 DRM 스키마입니다. 암호화 문제 만 해결할 것입니다. 물론 해커로부터 숨바꼭질을하는 문제는 있습니다. 아니요 DRM 체계는 보안 측면에서 (보안 하드웨어가 포함되어 있지 않는 한) 측정 가능한 보안을 제공하지만, 여전히 일반적이며 일부 개발자는 그 뒤에있는 논리에 익숙합니다.
라이선스 데이터를 생성하고 사용자가 합법적 인 사용자로부터 유효한 라이선스 파일을 단순히 복사하지 못하도록하는 정보를 포함하고 싶습니다. 예를 들어 MAC 주소, 전화 번호 등이 있습니다. 그러면 sign이 데이터입니다. 라이센스는 암호화되지 않은 라이센스와 서명 바이트로 구성됩니다. 사용자 측에서는 설치 소프트웨어가 하드 코딩 된 공개 키를 사용하여 서명을 확인하고 다른 주소 확인 (MAC 주소 일치, 전화 번호 일치 등)을 수행합니다.
이것은 계획의 핵심이며 대부분의 개발자에게 충분합니다. 이 코어를 가져다가 숨 막히는 게임을 얼마나 멀리 가고 싶은지에 따라 암호화, 분할 등의 임시 작업을 사용하여 난독화할 수 있습니다.
는 편집 : 나는 제안을 할 수있는 경우
, 나는 책 Beginning Cryptography With Java 현명한 투자가 될 것이라고 생각합니다. 여기에는 Bouncycastle 라이브러리를 사용하는 예제가 포함되어 있습니다. 동일한 웹 사이트에서 예제를 무료로 다운로드 할 수 있습니다.
이 제안이 완전히 바보가 아닌가요?
개인 키가 아닌 RSA 공개 키로 암호화해야합니다. 공개 키에 대한 액세스 권한을 가진 모든 사람이 AES 키를 학습하고 모든 것을 해독하거나 위조 할 수 있습니다. 물론 동일한 이유로 동일한 수신자에게 동일한 AES 키를 사용하지 않아야합니다.
질문에 대답하려면 각 AES/CBC 암호화에 대해 새로운 임의의 IV를 사용해야합니다.
모두 잘못되었습니다. 개인 RSA 키로 AES 키를 암호화하지 마십시오. 아무도 그것을 해독하고, AES 키를 검색하고, 라이센스를 수정할 수 있기 때문에 쓸모가 없습니다. 내가 당신의 다른 실에서 말했듯이, 당신이하려고하는 것은 서명이라고 불립니다. 서명 클래스를 사용해야합니다. –
와우 ... 지금 정말로 혼란 스럽네요. – jax
@GregS 그래서 3면 데이터 (예 : deviceID, 이메일, 만료)를 내 라이센스에서 사용하고 싶습니다. 어떻게 서명을 사용합니까? 전화 deviceID와 라이센스 deviceID를 비교할 수 있기를 원합니다? 면허 만료 등 현재 날짜 – jax