¿Se puede utilizar ECC (criptografía de curva elíptica) de forma segura sin infringir las patentes de Certicom?
Me gustaría hacer uso de ECC en un sistema integrado para establecer un canal seguro. Pero, estoy preocupado por la infracción de patentes.
¿Existen implementaciones de ECC de código abierto que están libres de patentes?
La implementación de ECC en OpenSSL ha sido contribuida por Sun (ahora Oracle) y, supuestamente, fue escrita de esa manera precisamente para evitar cualquier método patentado. De lo contrario, como sugiere AviD, usar una implementación que ya está provista por la plataforma que usa (Java, .NET ...) es una buena manera de evitar cualquier problema de patente: si hubiera tal problema, primero afectaría al proveedor de la plataforma. (es decir, Oracle, Microsoft), no tú.
Según mi conocimiento (pero no tengo derecho, en modo alguno, a brindar asesoramiento relacionado con la ley), las partes de la criptografía ECC que todavía pueden estar patentadas son:
Si no sabes lo que significa cualquiera de los anteriores, no te preocupes, estás en el reino no patentado y todo está bien.
Según Wikipedia , no debería ser un problema (si tiene cuidado):
Al menos un esquema ECC (ECMQV) y algunas técnicas de implementación están cubiertas por patentes.
(Lo que por supuesto implica que otros esquemas están libres de patentes).
En cuanto a las implementaciones de código abierto, ese mismo artículo de WP tiene una buena lista .
Aunque no especificó en qué idioma / plataforma está, le recomendaría ir con OpenSSL , la más conocida y la más popular. paquete revisado en el grupo.
Aunque también he escuchado buenos comentarios sobre algunos otros, como BouncyCastle, OpenSSH, ...
Dependiendo de la plataforma, tanto Java como .NET tienen soporte incorporado, al igual que las últimas versiones de Windows, por lo que no tendrá que preocuparse por las patentes allí. (Es decir, es una suposición segura de que se trata de una patente o una licencia legal).
Esto es más un comentario que una respuesta, pero el hecho de que la compresión de puntos esté patentada es absolutamente ridículo. En esencia, está patentando el proceso de almacenamiento del punto (x, y) almacenando x, y utilizando y = f (x).
De todos modos:
Otra cosa que es interesante, con respecto al argumento 'si usa una implementación proporcionada por otra persona, está bien': Al menos un proveedor de módulos de seguridad de hardware, que incluye una implementación de ECC, no garantizará a las personas que usan sus módulos contra reclamaciones de patentes. Eso es alimento para el pensamiento.
Por supuesto, también es importante tener en cuenta que en algunos países (como Japón, iirc), ECC está completamente libre de restricciones, y que muchas de las otras patentes solo se aplican en los EE. UU.
Algunos recursos:
Patentes irrelevantes sobre criptografía de curva elíptica - djb y Ed25519#Patents - djb
Argumenta que no hay patentes válidas que cubran Curve25519 y Ed25519. Hay patentes con temas similares, pero djb afirma que existe una técnica anterior para ellos.
Algoritmos de criptografía de curva elíptica fundamental - RFC6090
Un RFC que recopila algoritmos ECC que se cree que están libres de patentes. (por ser mayor que esas patentes)
Tanto RHEL como Fedora se han abstenido durante mucho tiempo del envío de OpenSSL con su soporte ECC activado, por preocupación sobre las patentes infractoras.
A partir de RHEL 6.5 Beta, y la actualización del 14 de octubre de 2013 a Fedora Core 18, 19 y 20, ya no es así, y ECC se activa de forma predeterminada en esos dos sistemas operativos, el error asociado se resuelve .
EDICIÓN IMPORTANTE : Finalmente, Fedora solo incluirá soporte para un subconjunto específico de curvas de ECC NIST Suite B , lo que significa que probablemente se basen en los diversos acuerdos mediante los cuales Certicom publica su IPR en ECC en algunos casos específicos, y no en un análisis del código OpenSSL que concluye que no infringe la patente ECC.
Lea otras preguntas en las etiquetas cryptography ecc legal