Bouncy Castle es una colección de API que se utilizan para implementar criptografía en programas informáticos. 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.
Bouncy Castle es de origen australiano y, por lo tanto, las restricciones estadounidenses a la exportación de criptografía desde los Estados Unidos no se aplican a él.
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 trabajando en Java SE del lado del servidor . Uno de los desarrolladores estaba activo en el desarrollo de Java ME (J2ME en ese momento) como pasatiempo y una consideración de diseño fue incluir la mayor variedad de máquinas virtuales Java para la biblioteca, incluidas las de J2ME. Esta consideración de diseño condujo a la arquitectura que existe en Bouncy Castle. [7]
El proyecto, fundado en mayo de 2000, fue escrito originalmente solo en Java, pero agregó una API de C# en 2004. La API original de Java constaba de aproximadamente 27.000 líneas de código, incluido el código de prueba y brindaba soporte para J2ME, un proveedor JCE / JCA y la 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, además de PKCS #10, PKCS#12, CMS, S/MIME , OpenPGP , DTLS , TLS , OCSP , TSP , CMP , CRMF, DVCS, DANE , EST y certificados de atributo. La API de C# tiene alrededor de 145.000 líneas de código y admite la mayor parte de lo que hace la API de Java.
Algunas propiedades clave del proyecto son:
El 18 de octubre de 2013, los desarrolladores principales y otras personas crearon una asociación sin fines de lucro, Legion of the Bouncy Castle Inc., en el estado de Victoria (Australia), para hacerse cargo del proyecto y apoyar el desarrollo continuo de las API. El 7 de noviembre de 2013, la Comisión Australiana de Organizaciones Benéficas y Sin Fines de Lucro reconoció a la asociación como una organización benéfica australiana con el propósito de promover la educación y un propósito que es beneficioso para la comunidad. [8] La asociación recibió autorización para recaudar fondos para apoyar sus propósitos el 29 de noviembre de 2013 por Consumer Affairs Victoria .
La arquitectura de Bouncy Castle consta de dos componentes principales que respaldan las capacidades criptográficas básicas. Estos se conocen como la API "liviana" y el proveedor de extensión criptográfica Java (JCE). Otros componentes basados en el proveedor 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 que fueran lo suficientemente simples como para usarlas si fuera necesario, pero proporcionaron los componentes básicos para el proveedor de JCE. La intención es utilizar la API de bajo nivel en dispositivos con restricciones de memoria (JavaME) o cuando no es posible acceder fácilmente a las bibliotecas de 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 fuerte que no se viera perjudicada por los archivos de Política de Jurisdicción que impedían que los proveedores de JCE realizaran un cifrado "fuerte".
El proveedor compatible con JCE se basa en las API de bajo nivel. Como tal, el código fuente del proveedor 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 JCE, incluida una autoridad de certificación de código abierto EJBCA .
Las versiones de C# y Java también cuentan con flujos certificados FIPS 140-2 Nivel 1. Estos se diferencian de las versiones regulares en que, si bien los módulos están diseñados de manera similar a las versiones regulares, las API de bajo nivel son bastante diferentes, en gran medida para respaldar la aplicación de los controles que FIPS requiere cuando se utiliza 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 FIPS se pusieron a disposición en noviembre de 2016; a la última versión de Java se le asignó el número de certificación 4616 y a la última versión de C# se le asignó el número de certificación 4416.
El sistema operativo Android , a principios de 2014, incluye una versión personalizada de Bouncy Castle. [9] Debido a conflictos de nombres de clase, esto impide que las aplicaciones de Android incluyan y utilicen la versión oficial de Bouncy Castle tal como está. Un proyecto de terceros llamado Spongy Castle distribuye una versión renombrada de la biblioteca para solucionar este problema. [10]
Originalmente, se suponía 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 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 bajo org.stripycastle . Esto era necesario para evitar conflictos con la versión de Android de Bouncy Castle, así como conflictos con aplicaciones que podrían usar Spongy Castle y no requerir servicios certificados FIPS 140-2.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}