Private Practice: Encryption Exposed
Private Practice: Encryption Exposed
In February 2016, a Los Angeles judge issued an order to Apple to help break into the encrypted iPhone belonging to a terrorist involved in a mass shooting. While there were many sides to this issue, it surfaced many important debates on security, privacy, and civil rights.
Join the DZone community and get the full member experience.Join For Free
Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner.
In September 2014, Apple made encryption default with the introduction of the iPhone 6. Then, in February 2016, a Los Angeles judge issued an order to Apple to help break into the encrypted iPhone belonging to a terrorist involved in a mass shooting.
Apple had used some of the strongest encryption technologies and practices to protect its users and their data. The encryption technology did not discriminate between lawful and unlawful users. While there were many sides to this issue, it surfaced many important debates on security, privacy, and civil rights.
For developers wanting to add cryptographic libraries to their applications, a number of open source components are available to them. Of course, anyone seeking to add encryption to an application has an important requirement for the privacy and security it provides.
One of the more popular choices for encryption is known as the Legion of Bouncy Castle Java Cryptography library. According to the 2016 State of the Software Supply Chain report, records reveal that 17.4 million Bouncy Castle components across all versions were downloaded last year. Of these, 5.8 million (33%) were known vulnerable versions of Bouncy Castle.
It’s a sobering fact, but it’s true. Last year alone, organizations downloaded vulnerable versions of the Bouncy Castle cryptography library 5.8 million times. The defective components downloads occurred across 93,253 unique IP addresses from 13,824 organizations in 197 countries.
Think about it. The Bouncy Castle project is developed by experts in cryptography. Occasionally, their crypto library is discovered to have a flaw and the project owners rapidly fix and release a new version. If you use the latest versions without known vulnerabilities, your application, your users, and your data are protected. If you use the versions that include known vulnerabilities, you have electively declined those protections.
Two of the critical principles of using open source components are to use the highest quality components and to select them from the best suppliers. In this case, the Bouncy Castle project does an excellent job of releasing new and improved versions. While flawed versions are still available, those seeking to protect applications, users, and data need to use the highest quality versions.
Which Version Are You Using?
Determining which versions of Bouncy Castle or any other open source component you are using is simple. A number of free and paid services are available to help you analyze your application and report a full list of the components, including dependencies, that are used.
Some of the free services require you to upload your application for analysis while other services are performed on-premises. One example of a free on-premises tool used to create a software Bill of Materials is the Application Health Check app from Sonatype. Another example is the OWASP Dependency Check app. Precision of these tools may vary, but regardless of the tool you use, you should use one.
More insights on the quality, security, and integrity of open source components used to build modern applications can be found in the 2016 State of the Software Supply Chain report.
Opinions expressed by DZone contributors are their own.