Bouncy Castle

Origem: Wikipédia, a enciclopédia livre.

Bouncy Castle é um coleção de APIs usadas em criptografia. Elas incluem APIs para as linguagens de programação Java e C#. Bouncy Castle é desenvolvida pela instituição sem fins lucrativo Australiana em origem "Legion of the Bouncy Castle", então as restrições Americanas de exportação de criptografia de software não se aplicam a ela. Foi fundado por dois desenvolvedores cansados e sempre re-implementar as mesmas funções de criptografia,[1] e é amplamente utilizada,[2][3] inclusive no sistema operacional Android, que usa uma versão modificada da Bouncy Castle.[4]

Ícone de esboço Este artigo sobre software é um esboço. Você pode ajudar a Wikipédia expandindo-o.

História[editar | editar código-fonte]

Bouncy Castle started when two colleagues were tired of having to re-invent a set of cryptography libraries each time they changed jobs working in server-side Java SE. One of the developers was active in Java ME (J2ME at that time) development as a hobby and a design consideration was to include the greatest range of Java VMs for the library, including those on J2ME. This design consideration led to the architecture that exists in Bouncy Castle.

The project, founded in May 2000, was originally written in Java only, but added a C# API in 2004. The original Java API consisted of approximately 27,000 lines of code, including test code and provided support for J2ME, a JCE/JCA provider, and basic X.509 certificate generation. In comparison, the 1.53 release consists of 390,640 lines of code, including test code. It supports the same functionality as the original release with a larger number of algorithms, plus PKCS#10, PKCS#12, CMS, S/MIME, OpenPGP, DTLS, TLS, OCSP, TSP, CMP, CRMF, DVCS, DANE, EST and Attribute Certificates. The C# API is around 145,000 lines of code and supports most of what the Java API does.

Algumas das principais propriedades do projeto são:

  • Forte ênfase no cumprimento de padrões e adaptabilidade.
  • As instalações de suporte público incluem um rastreador de problemas, uma lista de discussão de desenvolvedores e um wiki, todos disponíveis no site.
  • Suporte comercial fornecido em recursos para a API relevante listada no site Bouncy Castle

Em 18 de outubro de 2013, uma associação sem fins lucrativos, Legion of the Bouncy Castle Inc. foi estabelecida no estado de Victoria, Austrália, pelos principais desenvolvedores e outros para se apropriar do projeto e apoiar o desenvolvimento contínuo das APIs. A associação foi reconhecida como uma instituição de caridade australiana com o objetivo de promover a educação e beneficiar a comunidade pela Comissão Australiana de Instituições sem fins lucrativos e de caridade em 7 de novembro de 2013.[5] A associação foi autorizada a arrecadar fundos para apoiar seus propósitos em 29 de novembro de 2013 pela Consumer Affairs Victoria.

Arquitetura[editar | editar código-fonte]

A arquitetura Bouncy Castle consiste em dois componentes principais que suportam os recursos criptográficos básicos. Eles são conhecidos como a API 'leve' e o provedor Java Cryptography Extension (JCE). Outros componentes construídos sobre o provedor JCE oferecem suporte a funcionalidades adicionais, como suporte a PGP, S/MIME, etc.

A API de baixo nível, ou 'leve', é um conjunto de APIs que implementam todos os algoritmos criptográficos subjacentes. As APIs foram projetadas para serem simples de usar, se necessário, mas forneceram os blocos de construção básicos para o provedor JCE. A intenção é usar a API de baixo nível em dispositivos com restrição de memória (JavaME) ou quando o acesso fácil às bibliotecas JCE não for possível (como distribuição em um applet). Como a API leve é ​​apenas código Java, a Java virtual machine (JVM) não impõe nenhuma restrição à operação do código e, nos primeiros tempos da história do Bouncy Castle, era a única maneira de desenvolver uma criptografia forte que era não prejudicado pelos arquivos da Política de Jurisdição que impediam os provedores JCE de realizar criptografia "forte".

O provedor compatível com JCE é construído sobre as APIs de baixo nível. Dessa forma, o código-fonte do provedor JCE é um exemplo de como implementar muitos dos problemas criptográficos "comuns" usando a API de baixo nível. Muitos projetos foram construídos usando o provedor JCE, incluindo uma autoridade de certificação de código aberto EJBCA

Certificação[editar | editar código-fonte]

As versões C# e Java também possuem fluxos com certificação FIPS 140-2 Nível 1. Eles diferem dos lançamentos regulares porque, embora os módulos sejam projetados de maneira semelhante aos lançamentos regulares, as APIs de baixo nível são bem diferentes – principalmente para suportar a imposição de controles que o FIPS requer quando um algoritmo é usado. No caso do nível JCE da API Java, o provedor ainda é em grande parte um substituto para o lançamento regular. As primeiras versões com certificação FIPS foram disponibilizadas em novembro de 2016, com a versão mais recente do Java recebendo o número de certificação 3514 e a versão C# mais recente recebendo o número de certificação 4416.

Spongy Castle[editar | editar código-fonte]

O sistema operacional Android, desde o início de 2014, inclui uma versão personalizada do Bouncy Castle.[6] Devido a conflitos de nome de classe, isso impede que os aplicativos Android incluam e usem o lançamento oficial do Bouncy Castle como está. Um projeto de terceiros chamado Spongy Castle distribui uma versão renomeada da biblioteca para solucionar esse problema.[9]

Stripy Castle[editar | editar código-fonte]

Originalmente, assumiu-se que uma versão FIPS 140-2 do Spongy Castle também poderia ser feita. Descobriu-se devido ao processamento do arquivo DEX do Android que, para fins de FIPS, o provedor precisa ser instalado no dispositivo separado do aplicativo. A versão FIPS 140-2 para Android agora é chamada de Stripy Castle e está empacotada em org.stripycastle. Isso era necessário para evitar conflitos com a versão do Bouncy Castle do Android, bem como conflitos com aplicativos que poderiam estar usando o Spongy Castle e não requerer serviços certificados FIPS 140-2.

Referências

  1. ↑ «Open Source Development and Sustainability: A Look at the Bouncy Castle Project» (PDF). Linux Foundation Collaboration Summit, 2016. Cópia arquivada (PDF) em 29 de agosto de 2017 
  2. ↑ «Bouncy Castle and the Impact of Cryptographic Vulnerabilities». Ubiq. 19 de janeiro de 2021. Consultado em 14 de março de 2023 
  3. ↑ Focardi, Riccardo; et al. «Mind Your Keys? A Security Evaluation of Java Keystores.» (PDF). Consultado em 14 de março de 2023 
  4. ↑ Reimer, Helmut; Pohlmann, Norbert; Schneider, Wolfgang, eds. (2014). ISSE 2014 Securing Electronic Business Processes (PDF) (em inglês). Wiesbaden: Springer Fachmedien Wiesbaden. p. 205. ISBN 9783658067076. doi:10.1007/978-3-658-06708-3 
  5. ↑ "Australian Charities and Not-For-Profits Commission Register". Retrieved 6 July 2019.
  6. ↑ Reimer, Helmut; Pohlmann, Norbert; Schneider, Wolfgang, eds. (2014). ISSE 2014 Securing Electronic Business Processes (PDF). Wiesbaden: Springer Fachmedien Wiesbaden. p. 205. doi:10.1007/978-3-658-06708-3. ISBN 9783658067076. S2CID 32601495.

Ligações externas[editar | editar código-fonte]

Obtida de "https://pt.wikipedia.org/w/index.php?title=Bouncy_Castle&oldid=66151911"