È possibile utilizzare in modo sicuro ECC (Crittografia a curva ellittica) senza violare i brevetti di Certicom?
Vorrei utilizzare ECC in un sistema embedded per stabilire un canale sicuro. Ma sono preoccupato per la violazione dei brevetti.
Esistono implementazioni ECC open source prive di brevetti?
L'implementazione ECC in OpenSSL è stata fornita da Sun (ora Oracle) ed è stata, apparentemente, scritta in questo modo con precisione per evitare qualsiasi metodo brevettato. Altrimenti, come suggerisce AviD, usare un'implementazione che è già fornita dalla piattaforma che usi (Java, .NET ...) è un modo pulito per evitare qualsiasi problema di brevetto: se ci fosse un tale problema, colpirebbe prima il fornitore della piattaforma (es. Oracle, Microsoft), non tu.
A mia conoscenza (ma non ho il diritto, in alcun modo, di fornire consigli relativi alla legge), parti della crittografia ECC che possono ancora essere brevettate sono:
Se non sai cosa significa sopra, non preoccuparti, sei nel regno non brevettato e le cose vanno bene.
Secondo Wikipedia , non dovrebbe essere un problema (se stai attento):
At least one ECC scheme (ECMQV) and some implementation techniques are covered by patents.
(Il che ovviamente implica che altri schemi siano privi di brevetti.)
Per quanto riguarda le implementazioni opensource, lo stesso articolo del WP ha un buon elenco .
Anche se non hai specificato in quale lingua / piattaforma ti trovi, ti consiglio di andare con OpenSSL , il più conosciuto e il più pacchetto rivisto nel gruppo.
Sebbene abbia anche ascoltato un buon feedback su alcuni altri, come BouncyCastle, OpenSSH, ...
A seconda della piattaforma, Java e .NET hanno entrambi il supporto integrato, così come le ultime versioni di Windows, quindi non dovrai preoccuparti dei brevetti. (Vale a dire, è un presupposto sicuro che questi siano privi di brevetti o legalmente autorizzati.)
Questo è più un commento che una risposta, ma il fatto che la compressione del punto sia brevettata è assolutamente ridicolo. In sostanza, sta brevettando il processo di memorizzazione del punto (x, y) memorizzando x, e usando y = f (x).
In ogni modo:
Un'altra cosa che è interessante, per quanto riguarda l'argomento 'se si utilizza un'implementazione fornita da qualcun altro, stai bene': Almeno un fornitore di moduli di sicurezza hardware, che include un'implementazione ECC, non garantisce alle persone che usano i loro moduli contro le richieste di brevetto. Questo è uno spunto di riflessione.
Naturalmente, è anche importante notare che in alcuni paesi (come il Giappone, iirc) ECC è completamente privo di vincoli e che molti altri brevetti si applicano solo negli Stati Uniti.
Alcune risorse:
Brevetti irrilevanti sulla crittografia a curva ellittica - djb e Ed25519#Patents - djb
Sostiene che nessun brevetto valido copre Curve25519 e Ed25519. Ci sono brevetti con argomenti simili, ma il djb sostiene che esiste per loro la tecnica antecedente.
Algoritmi di crittografia a curva ellittica fondamentale - RFC6090
Un RFC che raccoglie algoritmi ECC ritenuti privi di brevetti. (essendo più vecchio di quei brevetti)
Sia RHEL che Fedora si sono a lungo trattenuti dalla distribuzione di OpenSSL con il suo supporto ECC attivato, fuori dalla preoccupazione di violare i brevetti.
A partire da RHEL 6.5 Beta e l'aggiornamento del 14 ottobre 2013 a Fedora Core 18, 19 e 20, questo non è più il caso, e ECC è attivato di default su questi due sistemi operativi, il bug associato è stato risolto .
EDIT IMPORTANTE : Infine Fedora solo include il supporto per un sottoinsieme specifico di curve ECC NIST Suite B , il che significa che probabilmente si basano sui vari accordi con cui Certicom rilascia IPR su ECC in alcuni casi specifici e non su un'analisi del codice OpenSSL che conclude che non viola il brevetto ECC.
Leggi altre domande sui tag cryptography legal ecc