Come generare e convalidare una chiave di licenza del software?

Sono attualmente coinvolto nello sviluppo di un prodotto (sviluppato in C #) che sarà disponibile per il download e l’installazione gratuitamente ma in una versione molto limitata. Per accedere a tutte le funzionalità l’utente deve pagare un canone e ricevere una chiave. Quella chiave verrà quindi inserita nell’applicazione per “sbloccare” la versione completa.

Dato che usare una chiave di licenza come quella è una cosa normale, mi chiedo:

  1. Come si risolve di solito?
  2. Come posso generare la chiave e come può essere convalidata dall’applicazione?
  3. Come posso anche evitare che una chiave venga pubblicata su Internet e utilizzata da altri che non hanno pagato la licenza (una chiave che fondamentalmente non è la “loro”).

Suppongo che dovrei anche bind la chiave alla versione dell’applicazione in qualche modo quindi sarà ansible caricare nuove chiavi nelle versioni delle funzionalità.

Qualcos’altro che dovrei pensare in questo scenario?

    Avvertenza: non è ansible impedire agli utenti di piratare, ma rendere più semplice per gli utenti onesti fare la cosa giusta.

    Supponendo che tu non voglia fare una build speciale per ogni utente, allora:

    • Genera te stesso una chiave segreta per il prodotto
    • Prendi il nome dell’utente
    • Concatenare il nome utente e la chiave segreta e l’hash con (ad esempio) SHA1
    • Disimballare l’hash SHA1 come stringa alfanumerica. Questo è il “codice” del singolo utente
    • All’interno del programma, eseguire lo stesso hash e confrontarlo con il codice prodotto. Se uguale, OK.

    Ma, ripeto: ciò non impedirà la pirateria


    Ho letto di recente che questo approccio non è crittograficamente molto valido. Ma questa soluzione è già debole (dal momento che il software stesso deve includere la chiave segreta da qualche parte ), quindi non credo che questa scoperta invalida la soluzione fino a che punto.

    Ho solo pensato che dovrei menzionarlo, però; se hai in programma di ricavarne qualcos’altro, fai attenzione.

    Esistono molti modi per generare i codici di licenza, ma pochissimi di questi modi sono veramente sicuri. Ed è un peccato, perché per le aziende le chiavi di licenza hanno quasi lo stesso valore del denaro reale.

    Idealmente, vorrai che le tue chiavi di licenza abbiano le seguenti proprietà:

    1. Solo la tua azienda dovrebbe essere in grado di generare le chiavi di licenza per i tuoi prodotti, anche se qualcuno invertirà completamente i tuoi prodotti (cosa che avverrà, parlo per esperienza). Obfuscare l’algoritmo o hide una chiave di crittografia all’interno del tuo software è davvero fuori questione se sei seriamente interessato a controllare le licenze. Se il tuo prodotto ha successo, qualcuno farà un generatore di chiavi in ​​pochi giorni dal rilascio.

    2. Una chiave di licenza dovrebbe essere utilizzabile su un solo computer (o almeno dovresti essere in grado di controllarla molto strettamente)

    3. Una chiave di licenza dovrebbe essere breve e facile da digitare o dettare al telefono. Non vuoi che ogni cliente chiami il supporto tecnico perché non capisce se la chiave contiene una “l” o una “1”. Il vostro servizio di supporto vi ringrazierà per questo, e avrete costi più bassi in quest’area.

    Quindi come risolvi queste sfide?

    1. La risposta è semplice ma tecnicamente impegnativa: le firme digitali che utilizzano la crittografia a chiave pubblica. Le tue chiavi di licenza dovrebbero infatti essere firmate “documenti”, contenenti alcuni dati utili, firmati con la chiave privata della tua azienda. Le firme dovrebbero essere parte della chiave di licenza. Il prodotto deve convalidare le chiavi di licenza con la chiave pubblica corrispondente. In questo modo, anche se qualcuno ha accesso completo alla logica del tuo prodotto, non possono generare chiavi di licenza perché non hanno la chiave privata. Una chiave di licenza sarebbe simile a questa: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) La sfida più grande qui è che gli algoritmi di chiave pubblica classica hanno dimensioni di firma grandi. RSA512 ha una firma a 1024 bit. Non vuoi che le tue chiavi di licenza abbiano centinaia di caratteri. Uno degli approcci più potenti è l’uso della crittografia a curve ellittiche (con attente implementazioni per evitare i brevetti esistenti). Le chiavi ECC sono 6 volte più corte delle chiavi RSA, con la stessa intensità. È ansible ridurre ulteriormente le dimensioni della firma utilizzando algoritmi come l’algoritmo di firma digitale Schnorr (brevetto scaduto nel 2008 – buono :))

    2. Ciò è ottenibile tramite l’triggerszione del prodotto (Windows è un buon esempio). Fondamentalmente, per un cliente con una chiave di licenza valida, è necessario generare alcuni “dati di triggerszione” che è un messaggio firmato che incorpora l’ID hardware del computer come i dati firmati. Di solito questo avviene su Internet, ma solo una volta: il prodotto invia la chiave di licenza e l’ID hardware del computer a un server di triggerszione, e il server di triggerszione restituisce il messaggio firmato (che può anche essere reso breve e facile da dettare sul Telefono). Da quel momento in poi, il prodotto non controlla la chiave di licenza all’avvio, ma i dati di triggerszione, che richiedono che il computer sia lo stesso per la convalida (altrimenti, i DATI sarebbero diversi e la firma digitale non sarebbe valida). Si noti che il controllo dei dati di triggerszione non richiede la verifica su Internet: è sufficiente verificare la firma digitale dei dati di triggerszione con la chiave pubblica già incorporata nel prodotto.

    3. Bene, elimina i caratteri ridondanti come “1”, “l”, “0”, “o” dai tuoi tasti. Dividere la stringa della chiave di licenza in gruppi di caratteri.

    Risposta semplice: non importa quale schema tu possa utilizzare può essere rotto.

    Non punire i clienti onesti con un sistema inteso a prevenire gli hacker, dato che gli hacker lo violeranno a prescindere.

    Un semplice codice hash legato alla loro email o simile è probabilmente abbastanza buono. Gli ID basati su hardware diventano sempre un problema quando le persone devono reinstallare o aggiornare l’hardware.

    Buona discussione sul problema: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

    Quando si genera la chiave, non dimenticare di concatenare la versione e il numero di build nella stringa su cui si calcola l’hash. In questo modo non ci sarà una sola chiave che sblocchi tutto ciò che hai mai rilasciato.

    Dopo aver trovato alcune chiavi o patch fluttuanti in astalavista.box.sk saprai che sei riuscito a fare qualcosa di abbastanza popolare che qualcuno si è preso la briga di crackare. Rallegrarsi!

    Oltre a ciò che è già stato detto ….

    Qualsiasi utilizzo di applicazioni .NET è intrinsecamente irrisolvibile a causa di problemi linguistici intermedi. Un semplice disassemblaggio del codice .NET aprirà il tuo prodotto a chiunque. Possono facilmente aggirare il tuo codice di licenza a quel punto.

    Non puoi nemmeno usare i valori dell’hardware per creare più una chiave. Le macchine virtuali ora consentono a qualcuno di creare un’immagine di una macchina “con licenza” ed eseguirla su qualsiasi piattaforma che scelgono.

    Se è un software costoso ci sono altre soluzioni. Se non lo è, basta renderlo abbastanza difficile per l’hacker occasionale. E accetta il fatto che alla fine ci saranno copie senza licenza.

    Se il tuo prodotto è complicato, i problemi di supporto inerente ti creeranno una certa protezione.

    Il motore C # / .NET che usiamo per la generazione della chiave di licenza è ora mantenuto come open source:

    https://github.com/appsoftware/.NET-Licence-Key-Generator .

    Si basa su un sistema di “verifica parziale delle chiavi” che significa che solo un sottoinsieme della chiave che si utilizza per generare la chiave deve essere compilato nella propria distribuzione. Tu crei le chiavi da te, quindi l’implementazione della licenza è unica per il tuo software.

    Come detto sopra, se il codice può essere decompilato, è relativamente facile aggirare la maggior parte dei sistemi di licenza.

    Non so quanto tu voglia elaborare

    ma credo che .net possa accedere al numero di serie del disco rigido.

    potresti avere il programma che ti manda questo e qualcosa di diverso (come il nome utente e l’indirizzo mac del nic)

    calcoli un codice basandoti su quello e rispedisci via email la chiave.

    li manterranno dalle macchine di commutazione dopo che avranno la chiave.

    Ho usato Crypkey in passato. È uno dei tanti disponibili.

    È ansible proteggere il software solo fino a un certo punto con qualsiasi schema di licenza.

    L’unico modo per fare tutto ciò che hai richiesto è richiedere un accesso a Internet e la verifica con un server. L’applicazione deve accedere al server con la chiave e quindi è necessario memorizzare i dettagli della sessione, come l’indirizzo IP. Ciò impedirà l’utilizzo della chiave su diverse macchine. Questo di solito non è molto popolare tra gli utenti dell’applicazione e, a meno che non si tratti di un’applicazione molto costosa e complicata, non ne vale la pena.

    Si può semplicemente avere una chiave di licenza per l’applicazione, quindi controllare il lato client se la chiave è buona, ma è facile distribuire questa chiave ad altri utenti e con un decompilatore possono essere generate nuove chiavi.

    Ho implementato un’triggerszione una tantum basata su Internet sul software della mia azienda (C # .net) che richiede una chiave di licenza che fa riferimento a una licenza memorizzata nel database del server. Il software colpisce il server con la chiave e riceve le informazioni sulla licenza che vengono poi crittografate localmente utilizzando una chiave RSA generata da alcune variabili (una combinazione di CPUID e altre cose che non cambieranno spesso) sul computer client e quindi la memorizzerà in il registro.

    Richiede una codifica sul lato server, ma ha funzionato molto bene per noi e sono stato in grado di utilizzare lo stesso sistema quando abbiamo ampliato il software basato su browser. Inoltre, offre ai tuoi venditori informazioni interessanti su chi, dove e quando viene utilizzato il software. Qualsiasi sistema di licenze gestito solo localmente è completamente vulnerabile allo sfruttamento, specialmente con la riflessione in .NET . Ma, come tutti gli altri hanno detto, nessun sistema è completamente sicuro.

    A mio parere, se non si utilizza la licenza basata sul Web, non esiste alcun vero punto di protezione del software. Con il mal di testa che DRM può causare, non è giusto per gli utenti che hanno effettivamente pagato per soffrire.

    Credo fermamente che solo il sistema di licenze basato su crittografia a chiave pubblica sia l’approccio giusto qui, perché non è necessario includere le informazioni essenziali richieste per la generazione di licenze nel codice sorgente.

    In passato, ho usato Treek’s Licensing Library molte volte, perché soddisfa tutti questi requisiti e offre un prezzo davvero buono. Utilizza la stessa protezione della licenza per gli utenti finali e per se stessa e nessuno ha mai rotto fino ad ora. È inoltre ansible trovare buoni consigli sul sito Web per evitare la pirateria e cracking.

    Non è ansible impedire completamente la pirateria del software. È ansible prevenire la pirateria casuale e questo è ciò che fanno tutte le soluzioni di licenza.

    La licenza del nodo (macchina) bloccata è la migliore se si desidera impedire il riutilizzo delle chiavi di licenza. Sto usando Cryptlex da circa un anno per il mio software. Ha anche un piano gratuito , quindi se non ti aspetti troppi clienti puoi usarlo gratuitamente.

    Come pochi altri citati, sono un enorme avversario di essere ostile ai clienti per impostazione predefinita, qualcosa che è noto per il settore delle licenze. Quindi mi dilungherò su una buona soluzione per il tuo problema che offre anche un buon cliente UX .

    Per iniziare, hai detto di avere una versione “limitata” del tuo software che stai utilizzando per provare e convertire i clienti in “upgrade” per funzionalità aggiuntive. Quindi, quello che stai cercando sono le licenze per il tuo prodotto, ad esempio un cliente può acquistare una licenza per feature-X o feature-Y .

    Ho creato Keygen con questo tipo di licenza in mente. Keygen è un’API REST di licenza che consente di gestire account utente, licenze e anche tracciare l’utilizzo / le associazioni della macchina.

    Quello che vorrei fare è impostare 2 tipi di licenza (un criterio all’interno di Keygen) dove uno è un criterio di base per la versione limitata gratuita e l’altro è un criterio per la versione a pagamento.

    Non sono sicuro di cosa stai utilizzando per i pagamenti, ma supponiamo che tu stia usando qualcosa come Stripe (piuttosto standard al giorno d’oggi) che offre webhooks . Keygen ha anche dei webhook (che tu lo usi o meno, tutto questo è ancora applicabile). Puoi integrare Keygen per parlare con il tuo fornitore di servizi di pagamento utilizzando webhooks da entrambi i lati (pensa: customer.created -> crea una licenza di base per il cliente, license.created -> carica il cliente per la nuova licenza).

    Quindi, utilizzando i webhook, possiamo automatizzare la creazione di licenze per i nuovi clienti. Quindi che ne è della convalida della licenza all’interno dell’applicazione stessa? Ciò può essere fatto in vari modi, ma il modo più diffuso è quello di richiedere al cliente di immettere una chiave di licenza lunga in un campo di input che è ansible convalidare; Penso che questo sia un modo terribile per gestire la convalida della licenza nella tua applicazione.

    Perché lo penso? Prima di tutto, stai richiedendo al tuo cliente di inserire una chiave di licenza noiosamente lunga che è pensata per il consumo della macchina, e in secondo luogo chiedi a te e ai tuoi clienti di tenere traccia di quella tediosa chiave di licenza .

    Ok, allora qual è un’alternativa? Penso che l’alternativa migliore sia fare qualcosa a cui tutti i tuoi clienti sono abituati: permettere loro di creare un account per il tuo prodotto usando una email / password . È quindi ansible associare tutte le loro licenze e le loro macchine con tale account. Così ora invece di inserire una chiave di licenza, possono semplicemente accedere utilizzando le loro credenziali.

    Che vantaggio ti dà? In primo luogo, elimina la necessità per te e i tuoi clienti di tenere traccia delle chiavi di licenza, poiché è tutto gestito dietro le quinte all’interno del loro account utente e soprattutto: ora puoi offrire ai tuoi clienti licenza e macchina self-service Attivazione! cioè poiché tutte le loro licenze e macchine sono associate al loro account utente, puoi chiedere loro di acquistare una licenza quando accendono la tua applicazione su una macchina non riconosciuta.

    Ora sulla convalida della licenza : ogni volta che i clienti accedono alla tua applicazione con la loro email / password, puoi richiedere al loro account utente le licenze che possiedono per determinare se possono usare feature-X o feature-Y . E poiché la tua applicazione ora è self-service , puoi consentire ai tuoi clienti di acquistare funzionalità aggiuntive direttamente dalla tua applicazione!

    Quindi abbiamo introdotto un sacco di automazione per il nostro sistema di licenze, possiamo concedere in licenza le singole funzionalità (ad esempio una versione limitata rispetto a quella completa), abbiamo offerto una UX straordinaria per i nostri clienti e abbiamo anche alleviato uno dei principali motivi per richieste di supporto: ripristino della chiave di licenza.

    Ad ogni modo, questo è durato, ma si spera che aiuti qualcuno!

    È ansible utilizzare una soluzione di terze parti gratuita per gestire questo per voi come Quantum-Key.Net È gratuito e gestisce i pagamenti tramite paypal attraverso una pagina di vendita Web che crea per te, la chiave di emissione via e-mail e serrature chiave utilizzare su un computer specifico per prevenire la pirateria.

    Si dovrebbe anche fare attenzione a offuscare / crittografare il proprio codice o può essere facilmente decodificato utilizzando software come De4dot e .NetReflector. Un buon offuscatore di codice libero è ConfuserEx, che è veloce e semplice da usare e più efficace di costose alternative.

    Dovresti eseguire il tuo software finito tramite De4Dot e .NetReflector per decodificarlo e vedere cosa vedrebbe un cracker se facesse la stessa cosa e per assicurarti di non aver lasciato alcun codice importante esposto o nascosto.

    Il tuo software sarà ancora fendibile ma per il casual cracker potrebbe essere sufficiente rimuoverli e questi semplici passaggi impediranno anche l’estrazione e il riutilizzo del codice.

    https://quantum-key.net

    Come usare ConfuserEx?

    https://github.com/0xd4d/de4dot

    https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download

    Sono uno degli sviluppatori dietro la piattaforma di licenze software di Cryptolens e ho lavorato su sistemi di licenze dall’età di 14 anni. In questa risposta, ho incluso alcuni suggerimenti basati sull’esperienza acquisita nel corso degli anni.

    Il modo migliore per risolverlo è impostare un server delle chiavi di licenza che ogni istanza dell’applicazione chiamerà per verificare una chiave di licenza.

    Vantaggi di un server con chiavi di licenza

    I vantaggi con un server di chiavi di licenza sono:

    1. puoi sempre aggiornare o bloccare un codice di licenza con effetto immediato.
    2. ogni chiave di licenza può essere bloccata su un determinato numero di macchine (ciò aiuta a impedire agli utenti di pubblicare la chiave di licenza online affinché altre persone possano usarla).

    considerazioni

    Sebbene la verifica delle licenze online offra un maggiore controllo su ciascuna istanza dell’applicazione, la connessione Internet non è sempre presente (specialmente se si targetizza le grandi imprese), quindi abbiamo bisogno di un altro modo per eseguire la verifica della chiave di licenza.

    La soluzione è firmare sempre la risposta della chiave di licenza dal server utilizzando un crittosistema a chiave pubblica come RSA o ECC (possibilmente meglio se si intende eseguire su sistemi embedded). L’applicazione deve avere solo la chiave pubblica per verificare la risposta della chiave di licenza.

    Quindi, nel caso in cui non ci sia una connessione internet, è ansible utilizzare la risposta della chiave di licenza precedente. Assicurati di memorizzare sia la data che l’ identificativo della macchina nella risposta e controlla che non sia troppo vecchio (ad esempio, consenti agli utenti di essere offline al massimo 30 giorni, ecc.) E che la risposta alla chiave di licenza appartenga al dispositivo corretto.

    Nota che dovresti sempre controllare il certificato di risposta alla chiave di licenza, anche se sei connesso a internet, per assicurarti che non sia stato cambiato da quando ha lasciato il server (questo deve ancora essere fatto anche se la tua API per il il server delle chiavi di licenza utilizza https)

    Protezione degli algoritmi segreti

    La maggior parte delle applicazioni .NET può essere decodificata abbastanza facilmente (c’è un diassembler fornito da Microsoft per ottenere il codice IL e alcuni prodotti commerciali possono persino recuperare il codice sorgente, ad esempio C #). Certo, puoi sempre offuscare il codice, ma non è mai sicuro al 100%.

    Nella maggior parte dei casi, lo scopo di qualsiasi soluzione di licenza software è quello di aiutare le persone oneste ad essere oneste (cioè che gli utenti onesti che sono disposti a pagare non dimenticano di pagare dopo la scadenza di una prova, ecc.).

    Tuttavia, potresti avere ancora del codice che non vuoi assolutamente divulgare al pubblico (ad esempio un algoritmo per prevedere i prezzi delle azioni, ecc.). In questo caso, l’unico modo per andare è creare un endpoint API che l’applicazione chiamerà ogni volta che il metodo deve essere eseguito. Richiede una connessione Internet ma garantisce che il codice segreto non venga mai eseguito dal computer client.

    Implementazione

    Se non vuoi implementare tutto da solo, ti consiglio di dare un’occhiata a questo tutorial (parte di Cryptolens )