라이센스 키 생성을위한 보안 알고리즘?

Question

응용 프로그램을 배포하고 싶지만 잠금을 해제하기 위해 입력 할 수있는 라이센스 키가 있습니다. 구매 한 버전에 대한 정보와 라이센스 기간 등과 같은 추가 사항이 포함 된 간결한 키를 만들기위한 좋은 알고리즘은 무엇입니까?

나는이 보호가 깨질 수 있다는 것을 알고 있지만 정직한 사람들을 정직하게 유지합니다. 온라인 활성화를 구현하거나 구현하지 않을 수도 있지만 주로 이러한 키를 생성하는 좋은 방법에 관심이 있습니다.

우리는이 상황을 모두 보았습니다. 어떤 알고리즘이 가장 잘 작동합니까? 사용자의 일반 텍스트 이름을 요청하고 자신의 정보를 기반으로 고유 한 제품 키를 만들기 위해 사용해야합니까?

유효한 키를 생성하는 데 거의 불가능하게 만드는 데 사용할 수있는 시스템이 있습니까?

아마도 제조업체 만 개인 키를 가지고 있고 공개 키에 의해 데이터를 검증 할 수있는 공개/개인 키어 암호화 상황 일 수 있지만 유효한 키를 만들기 위해 공개 키를 납치 할 수는 없습니다.

이것은 제품 키이므로 상당히 짧거나 64 자 또는 128 개의 최대가 될 경우 좋을 것입니다. 그러나 더 짧을수록 32 이하가 더 좋습니다.

Answer 1

당신은 당신이 어떤 플랫폼에 있는지 말하지 않았지만 여기에 Microsoft .net의 플랫폼이 있습니다.

http://jclement.ca/devel/dotnet/reallysimplelicensing.html

이 페이지는 .NET 응용 프로그램에서 사용할 수있는 매우 간단한 라이센스 체계를 기록합니다. 상당히 안전하고 구현하기 쉽고 확장하기 쉽습니다. 샘플 버전을 사용하면 클라이언트 이름이 포함 된 라이센스 파일을 제공 할 수 있지만 다른 식별 정보, 기계 바인딩, 만료 날짜 등을 추가하기 위해 쉽게 확장 할 수 있습니다.

이 체계는 Microsoft의 RSA 라이브러리 및 XML 서명을 사용합니다. 기본적으로 원하는 것을 XML 문서에 넣고 해당 문서에 서명합니다. 그런 다음 해당 파일을 고객에게 제공 할 수 있으며 응용 프로그램은 해당 파일에서 라이센스 정보를 읽을 수 있습니다. 파일이 디지털로 서명되어 있으므로 개인 키를 릴리스하지 않으면 라이센스 파일을 변조 할 수 없습니다 (실제로하지 말아야합니다).

Answer 2

인터넷 액세스 및 샷 키가 없습니다

직렬 키 크기와 관련하여 짧은/인간 읽기 쉬운 키 사이에 트레이드 오프가 있습니다 (덜 안전합니다) 및 긴 키나 라이센스 파일을 가질 수 있습니다 (더 안전합니다).

만료 날짜 및 기능과 같은 물건을 저장할 수있는 짧고 인간 읽기 쉬운 키를 원한다면 오픈 소스 인 Software Protector와 함께 Skgl을 사용할 수 있습니다 (https://help.cryptolens.io/faq/what-is-skgl).

그러나 단점은 대칭 암호화를 사용하거나 응용 프로그램 내에 주요 생성 알고리즘을 저장할 가능성이 높다는 것입니다. 이것은 최종 사용자가 암호화 키 및/또는 알고리즘을 찾으려고 시도 할 수 있음을 의미합니다 ( http://www.codeproject.com/articles/764610/licensing-systems-in-net).

인터넷 액세스 (또는 활성화 파일의 오프라인)

더 나은 대안은 모든 라이센스 키를 추적하고 언제든지 수정할 수있는 클라우드 기반 시스템을 사용하는 것입니다.

웹 기반 라이센스 시스템이있는 경우 키를 짧게 유지하고 실제 키 안에 정보를 저장할 필요가 없습니다 (대부분의 오프라인 기반 시스템의 경우).

또한 구독 기반 모델과 같은 더 많은 라이센스 모델을 지원할 수 있습니다.

솔루션은 다음과 같습니다.

• 그러한 시스템을 직접 구축하십시오 - 많은 시간이 걸리고 앱의 핵심 기능에서 산만 해집니다.

• 기존 오픈 소스 시스템을 시작점으로 사용하십시오. - 오픈 소스와 무료이기 때문에 유혹적 일 수 있지만 클라우드로 가져 오는 데 시간이 걸립니다 + 특정 요구 사항으로 구성 + 유지 관리. 내가 관찰 한 오픈 소스 시스템은 기능이 매우 넓은 경향이있어 복잡성에 기여합니다.

• 제 3 자에게 아웃소싱 - 단점은 대부분이 무료가 아니라는 것입니다.

내 마음에, 전체 절차는 특정 구성 요소를 개발하는 데 특화된 제 3 자에게 아웃소싱해야합니다. 일단 확장되면 라이센스 로직을 변경해야 할 수도 있습니다. 직접 개발하는 대신 제 3자가 이미 해당 시나리오를지지 할 가능성이 있습니다.

몇 가지 해결책이 있습니다 (웹 기반의 사람들을 찾으십시오.), 크립토 렌스 한 예입니다. .NET 애플리케이션을 개발하는 경우 단계별 예입니다. https://help.cryptolens.io/examples/key-verification.

---

부인 성명: 저는 SkGL/Software Protector, 라이센스 시스템에 관한 기사 및 Cryptolens의 저자입니다.