Newsgroup: it.comp.sicurezza.varie
Titolo: Key Generator

Devo distribuire una mia applicazione attraverso un rivenditore,
e vorrei tutelarmi da eventuali violazioni sul diritto di copia.
Anche se di solito questi meccanismi lasciano un po' il tempo che
trovano, vorrei implementare un meccanismo semplice ma
secondo me utile per limitare eventuali danni derivanti da
copie non autorizzate della mia applicazione.
Pensavo ad una funzione
    function KeyGenerator(const Username: string): string;
    var
        ActivationKey: string;
    begin
        ...
        Result := ActivationKey;
    end;
che prendendo in input una stringa alfanumerica "Username"
(il nome utilizzato per registrare il programma), restituisca in
output un codice di attivazione "ActivationKey" del programma stesso.
A questo punto abiliterei il funzionamento del mio programma soltanto
quando il codice di attivazione inserito dall'utente in fase di
registrazione
coincida in modo esatto con il codice (ActivationKey) restituito
dalla mia funzione KeyGenerator.
Ho letto un pochino di Crittografia, chiavi pubbliche e chiavi private, ma
non essendo un esperto cercavo dei saggi consigli, e magari qualche
aiuto concreto su come operare o dove trovare informazioni utili in
termini pratici e non prettamente teorici.
Grazie a tutti.
Riccardo
P.S.
Scusate, forse questo post è un tantino OFF TOPICS ma dovrei
implementare il tutto in Delphi, e non saprei dove chiedere aiuto.

 
Lascio da parte considerazioni filosofiche sulla protezione del 
software, annessi e connessi che sarebbe OT.
Il messaggio è, credo, in-topic anche se potrai trovare più 
suggerimenti pratici in qualche ng di programmazione, magari 
orientato a dephi.
Se usi un sistema a chiave pubblica/privata puoi crittografare il 
codice utente con la chiave privata (che non viene distribuita) e 
decrittografarlo con la corrispondente chiave pubblica inclusa nel 
programma. In questo modo dovrebbe essere impossibile generare codici 
validi senza essere in possesso della chiave privata (se qualcuno ha 
scoperto un modo di farlo, la sicurezza del tuo programma è una delle 
ultime preoccupazioni :)).
A questo punto chi vuole distribuire il tuo programma a sbafo ha due 
alternative:
- distribuisce anche un codice utente valido
- rimuove il tuo meccanismo di protezione
Nel primo caso dovrà rischiare e distribuire il suo codice oppure 
trovare il modo di copiare il codice valido di un altro utente.
Nel secondo caso si dovrà armare di un debugger e/o disassemblatore, 
trovare il punto in cui il tuo programma controlla il codice di 
abilitazione ed eliminare il controllo (o anche solo "girarlo" in 
modo che tutti i codici non validi ti consentano di continuare). 
Puoi proteggere il tuo programma con altri controlli (ex: con un 
checksum che garantisca l'integrità dell'eseguibile, magari protetto 
dalla chiave privata), ma saranno tutti bypassabili con la stessa 
logica con cui è stato forzato il controllo sul codice.
La sicurezza è data dal rapporto tra quanto si spende (non solo in 
termini economici) per appropriarsi di qualcosa senza pagarlo 
direttamente e il suo valore (cito spannometricamente la descrizione 
di qualcuno più competente di me).
Nel tuo caso la "spesa" è rappresentata dagli sforzi necessari per 
rimuovere le protezioni o dal rischio che si corre nel distribuire il 
proprio codice o nell'appropriarsi di un codice valido. 
Il valore non è rappresentato solo dal prezzo del software, ma anche 
dai possibili ricavi derivanti da una sua vendita illegale (anche se 
il venditore rischia poi di essere fregato senza troppa fatica dai 
suoi clienti, indipendentemente dal modo in cui ha deciso di forzare 
la tua protezione).
Devi poi valutare molto attentamente quanto le eventuali misure di 
protezione possano complicare il software, il suo utilizzo o la sua 
distribuzione. 
Complicare la struttura di un programma porta, normalmente, ad 
aggiungerci qualche bug e a renderlo più complesso da 
modificare/mantenere. 
Aggiungere meccanismi macchinosi di registrazione e/o distribuzione o 
richiedere all'utente operazioni aggiuntive per garantire di essere 
in possesso del software* possono renderlo meno user friendly e meno 
competitivo rischiando di farti perdere più utenti legali di quanti 
te ne avrebbe fatti perdere la pirateria.
* Ricordo che ai tempi della scuola (fine anni 80-inizio anni 90) 
c'erano diversi videogame che chiedevano di inserire una parola presa 
a caso dal manuale (ai tempi andavano di moda i manualoni cartacei) 
oppure da una lista stampata in modo che fosse difficilmente 
fotocopiabile (in rosso su fondo grigio, ad esempio). Anche chi aveva 
il giochino regolare finiva per utilizzare le versioni sprotette per 
evitarsi la "tortura" pre-partita :)
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 "Username" restituisca in output un codice di attivazione
sistema diffusissimo
due falle:
tramite reverse engineering puo' essere possibile risalire all'algoritmo e
creare quindi un key-generator per generare tutte le coppie "user-key" che
si vuole
tramite debugger puo' essere possibile crackare la protezione ad esempio
aggirando il test di verifica dell'avvenuta registrazione o "ritoccando"
il check di esattezza della pass
-- 
--spammer denunciati e sanzionati:--------come denunciare:------------
http://punto-informatico.it/p.asp?i=39788
 
www.maxkava.com/spam/
http://punto-informatico.it/p.asp?i=42528
 
www.collinelli.net/antispam/

 
La sicurezza in questo caso non dipende dall'algoritmo, ma dalla 
chiave. 
Se usi uno degli algoritmi di firma digitale per "firmare" l'id 
dell'utente, generando così il suo codice di attivazione un potenziale 
"attaccante" non dovrà limitarsi a "banale" reverse engineering (come 
nella soluzione precedente), ma dovrà affrontare un algoritmo di 
crittografia che, nel caso degli algoritmi più diffusi, è già stato 
testato da parecchi esperti del settore, a partire dagli stessi 
"inventori" (anche se non è detto che chi ha trovato una potenziale 
"falla" si sia premurato di comunicarlo al resto del mondo per poter 
sfruttare in modo illecito la sua scoperta o perchè il suo datore di 
lavoro non lo permette...).
Se qualcuno riesce a trovare un modo per ricavare la chiave privata 
utilizzata per il software in questione e a renderlo computabile con 
costi e tempi accettabili potrà poi applicare il suo metodo in 
parecchie altre situazioni molto più redditizie che il cracking del 
software prodotto dal nostro amico...
Per l'RSA sono gli stessi inventori dell'algoritmo a spiegare come è 
possibile ricavare la chiave privata partendo da quella pubblica e da 
messaggi crittografati (
http://www.rsasecurity.com/rsalabs/faq/3-1-
3.html). Però una "sfida" lanciata nel 1977 dagli inventori di RSA è 
stata completata solo nel 1994, utilizzando una capacità di calcolo 
notevoli (e quasi impensabili nel 1977): 
http://primes.utm.edu/glossary/page.php?sort=RSA
Senza contare che il tempo necessario aumenta semplicemente aumentando 
la lunghezza della chiave.
Nel concetto di "sicurezza della chiave" (che sicuramente può essere 
espresso con termini più corretti da qualcuno più preparato del 
sottoscritto) rientra anche la sicurezza "fisica" della chiave 
(sequenza di bit) stessa.
Usare una chiave lunghissima per generare i codici e poi memorizzarla 
sul disco C condiviso senza password di un PC con windows 98, netbios, 
kazaa, winmx e via filesharando... collegato 24 ore su 24 a una linea 
ADSL potrebbe offrire a un potenziale malfattore una scorciatoia 
invitante.


 la lunghezza della chiave.
"Semplicemente" e' un termine semplificativo :)
HappyCactus O(log^6 n)
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM1050 <<<
              YAGF Member Group >>> 
www.google.com
 <<<
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

 
Volevo dire che l'algoritmo non č vincolato a una determinata lunghezza 
della chiave e quindi non sono necessarie modifiche "strutturali" per 
rendere piů sicuro il sistema.


Preso da una crisi mistica, Valter Minute scrisse:
 > [..]
 > * Ricordo che ai tempi della scuola (fine anni 80-inizio anni 90)
 > c'erano diversi videogame che chiedevano di inserire una parola presa
 > a caso dal manuale.
Questa cosa mi ricorda "vagamente" l'ambiente Amighista del tempo..
..Del quale facevo orgogliosamente parte assieme ad una nutrita schera 
di amici.. :)
Eeeh.. beata gioventů.. ;)
Saluti by MCM.

 La sicurezza in questo caso non dipende dall'algoritmo, ma dalla chiave.
(cut)
taglio corto dicendo che se e' troppo complicato si pialla direttamente
senza sottilizzare e che quindi non rappresenta una difesa che giustifica
elevati costi di sviluppo
secondo me sinteticamente non ha senso perdere il sonno su queste cose
perche' puoi solo sperare che non finisca mai nelle mani di un utente
smaliziato


 un utente smaliziato
Su questo punto (come detto all'inizio del mio primo post) non mi 
pronuncio in termini così categorici. 
Dico solo che è sempre necessario considerare i pro e i contro di un 
sistema di protezione in termini di:
- resistenza a sprotezione
- possibili perdite economiche derivanti dalla commercializzazione 
illegale del prodotto o dalla sua diffusione gratuita (tenendo 
presente che non tutti quelli che usano il prodotto gratis o a prezzo 
ridotto lo avrebbero comprato a prezzo pieno).
- complessità di implementazione
- ripercussioni sulla struttura del software e quindi sulla sua 
affidabilità e manutenibilità
- ripercussioni sull'operatività del programma e sulla soddisfazione 
degli utenti finali che hanno acquistato onestamente il prodotto
Spesso non considerare tutti questi fattori (soprattutto gli ultimi 
due) porta a realizzare sistemi di protezione che fanno più danni (e 
li fanno a chi non dovrebbe essere danneggiato) rispetto alla 
mancanza totale di protezioni.


 
 
  e ti ricordi verso il 2006, no, forse era il 2002 quando passavamo il
  tempo a spippolare su linux ... bei tempi eh?
  poi e' arrivato 'bigbrother' e ha imposto il 'suo' sistema con il 'suo'
  hardware ...
  comunque ho ancora qualche cd (te li ricordi i cd ?) e ogni tanto tiro
  fuori dalla polvere il mio bolso pc a 2 ghz e ci faccio girare
  la debian 6.0 (l'ultima che usci) sniff sniff
  bei tempi ...  ;-)
 
-- 
Note: Microsoft Internet Explorer is notorious for corrupting binary 
download files when it does not understand the file extension. Please
do not download software from this page using Microsoft Internet Explorer

 >[snip snip]
...?!?... Era umorismo questo?
MCM.