Bouncy Castle es una colección de API que se utilizan en criptografía . Incluye API para los lenguajes de programación Java y C # . Las API cuentan con el respaldo de una organización benéfica australiana registrada : Legion of the Bouncy Castle Inc.
Desarrollador (es) | Legión del castillo hinchable Inc. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Liberaciones estables [±] | |||||||||
| |||||||||
Repositorio | github | ||||||||
Escrito en | C # y Java | ||||||||
Plataforma | .NET Framework y Java SE | ||||||||
Tipo | API de criptografía | ||||||||
Licencia | Licencia MIT [5] | ||||||||
Sitio web | bouncycastle |
Bouncy Castle es de origen australiano y, por lo tanto, no se le aplican las restricciones estadounidenses sobre la exportación de criptografía desde Estados Unidos .
Historia
Bouncy Castle comenzó cuando dos colegas estaban cansados de tener que reinventar un conjunto de bibliotecas de criptografía cada vez que cambiaban de trabajo en Java SE del lado del servidor . Uno de los desarrolladores estaba activo en el desarrollo de Java ME (J2ME en ese momento) como un pasatiempo y una consideración de diseño era incluir la mayor variedad de máquinas virtuales Java para la biblioteca, incluidas las de J2ME. Esta consideración de diseño llevó a la arquitectura que existe en Bouncy Castle. [6]
El proyecto, fundado en mayo de 2000, se escribió originalmente solo en Java, pero luego se agregó una API de C # en 2004. La API de Java original consistía en aproximadamente 27,000 líneas de código, incluido el código de prueba y brindaba soporte para J2ME, un JCE / JCA proveedor y generación básica de certificados X.509 . En comparación, la versión 1.53 consta de 390.640 líneas de código, incluido el código de prueba. Admite la misma funcionalidad que la versión original con una mayor cantidad de algoritmos, más PKCS # 10, PKCS # 12, CMS, S / MIME , OpenPGP , DTLS , TLS , OCSP , TSP , CMP , CRMF, DVCS , DANE , EST y certificados de atributos. La API de C # tiene alrededor de 145.000 líneas de código y es compatible con la mayor parte de lo que hace la API de Java.
Algunas propiedades clave del proyecto son:
- Fuerte énfasis en el cumplimiento de las normas y la adaptabilidad.
- Las instalaciones de apoyo público incluyen un rastreador de problemas, una lista de correo de desarrolladores y una wiki, todos disponibles en el sitio web.
- Soporte comercial proporcionado en los recursos para la API relevante que se enumera en el sitio web de Bouncy Castle
El 18 de octubre de 2013, los desarrolladores principales y otros establecieron una asociación sin fines de lucro, Legion of the Bouncy Castle Inc. en el estado de Victoria, Australia, para tomar posesión del proyecto y apoyar el desarrollo continuo de la API. La asociación fue reconocida como una organización benéfica australiana con un propósito de avance en la educación y un propósito que es beneficioso para la comunidad por la Comisión Australiana de Organizaciones Benéficas y sin Fines de Lucro el 7 de noviembre de 2013. [7] La asociación fue autorizada a recaudar fondos para apoyar sus propósitos el 29 de noviembre de 2013 por Consumer Affairs Victoria .
Arquitectura
La arquitectura de Bouncy Castle consta de dos componentes principales que admiten las capacidades criptográficas básicas. Estos se conocen como la API 'liviana' y el proveedor de Java Cryptography Extension (JCE). Otros componentes basados en el proveedor de JCE admiten funciones adicionales, como compatibilidad con PGP , S / MIME , etc.
La API de bajo nivel o "liviana" es un conjunto de API que implementan todos los algoritmos criptográficos subyacentes. Las API se diseñaron para ser lo suficientemente simples de usar si fuera necesario, pero proporcionaron los bloques de construcción básicos para el proveedor de JCE. La intención es utilizar la API de bajo nivel en dispositivos con restricción de memoria (JavaME) o cuando no es posible acceder fácilmente a las bibliotecas JCE (como la distribución en un subprograma ). Como la API liviana es solo código Java, la máquina virtual Java (JVM) no impone ninguna restricción en el funcionamiento del código, y en los primeros tiempos de la historia de Bouncy Castle era la única forma de desarrollar una criptografía sólida que se no paralizado por los archivos de la Política de Jurisdicción que impedían a los proveedores de JCE realizar un cifrado "fuerte".
El proveedor compatible con JCE se basa en las API de bajo nivel. Como tal, el código fuente del proveedor de JCE es un ejemplo de cómo implementar muchos de los problemas criptográficos "comunes" utilizando la API de bajo nivel. Se han creado muchos proyectos utilizando el proveedor de JCE, incluida una autoridad de certificación de código abierto EJBCA .
Lanzamientos certificados
Las versiones de C # y Java ahora [ ¿cuándo? ] tienen también transmisiones certificadas FIPS 140-2 Nivel 1. Estos difieren de los lanzamientos regulares en que, si bien los módulos están diseñados de manera similar a los lanzamientos regulares, las API de bajo nivel son bastante diferentes, en gran parte para respaldar la aplicación de los controles que FIPS requiere cuando se usa un algoritmo. En el caso del nivel JCE de la API de Java, el proveedor sigue siendo en gran medida un reemplazo directo de la versión regular. Las primeras versiones certificadas por FIPS estuvieron disponibles en noviembre de 2016, y a la versión de Java se le asignó el número de certificación 2768 y a la versión C # se le asignó el número de certificación 2792 .
Castillo esponjoso
El sistema operativo Android , a principios de 2014, incluye una versión personalizada de Bouncy Castle. [8] Debido a conflictos de nombres de clases, esto impide que las aplicaciones de Android incluyan y usen la versión oficial de Bouncy Castle tal cual. Un proyecto de terceros llamado Spongy Castle distribuye una versión renombrada de la biblioteca para solucionar este problema. [9]
Castillo de rayas
Originalmente, se asumió que también se podría hacer una versión FIPS 140-2 de Spongy Castle . Resultó que debido al procesamiento de archivos DEX de Android, para fines de FIPS, el proveedor debe instalarse en el dispositivo por separado de la aplicación. La versión FIPS 140-2 para Android ahora se llama Stripy Castle y está empaquetada en org.stripycastle . Esto era necesario para evitar choques con la versión de Android de Bouncy Castle, así como choques con aplicaciones que podrían estar usando Spongy Castle y no requieren servicios certificados FIPS 140-2.
Ver también
- Comparación de bibliotecas de criptografía
Referencias
- ^ "Notas de la versión - bouncycastle.org" . 7 de junio de 2021 . Consultado el 8 de junio de 2021 .
- ^ "Recursos de Java FIPS - bouncycastle.org" . 21 de abril de 2021 . Consultado el 29 de agosto de 2019 .
- ^ "La Legión de las API de criptografía C # de Bouncy Castle" . 16 de febrero de 2021 . Consultado el 17 de febrero de 2021 .
- ^ "Recursos C # .NET FIPS - bouncycastle.org" . 21 de abril de 2021 . Consultado el 28 de agosto de 2017 .
- ^ "Castillo Hinchable - LICENCIA" . bouncycastle.org . Legión del Castillo Hinchable.
- ^ " Desarrollo de código abierto y sostenibilidad: una mirada al proyecto del castillo hinchable " (PDF) . Cumbre de colaboración de la Fundación Linux, 2016. Archivado desde el original (PDF) el 29 de agosto de 2017.
- ^ "Registro de la Comisión australiana de organizaciones benéficas y sin fines de lucro" . Consultado el 6 de julio de 2019 .
- ^ Reimer, Helmut; Pohlmann, Norbert; Schneider, Wolfgang, eds. (2014). ISSE 2014 Protección de los procesos comerciales electrónicos (PDF) . Wiesbaden: Springer Fachmedien Wiesbaden. pag. 205. doi : 10.1007 / 978-3-658-06708-3 . ISBN 9783658067076. S2CID 32601495 .
- ^ "Castillo esponjoso" . Consultado el 29 de abril de 2013 , a través de Github.
enlaces externos
- Página web oficial