Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
For years, cryptography experts have been working on providing software developers with novel cryptographic algorithms that are more long-term secure  and/or provide additional functionality such as schemes that allow certain planned alterations to encrypted data . Unfortunately, despite those efforts, recent studies have shown that even applications that use rather basic cryptography are still by and large inherently insecure . This is not because the vulnerabilities in those applications are rooted in the cryptographic algorithms they use but instead in how those applications use those algorithms . Most algorithms are hard to configure correctly, and the appropriate application interfaces (APIs) allow for many insecure usages, while only few are secure. It should not be a huge surprise then that cumulative NVD statistics for years 2013-2015 ranks Cryptographic Issues as the fourth largest category of problems, only slightly behind Access Control issues .
The problem is caused by a mismatch in expertise: crypto libraries are written by crypto experts, and use a terminology mostly accessible to such experts but not to general code developers. The goal of this project is to help bridge this gap through dedicated tooling.
In 2014 the German Research Foundation (DFG) has established at Technische Universität Darmstadt the Collaborative Research Center CROSSING (Cryptography-Based Security Solutions: Enabling Trust in New and Next Generation Computing Environments). Within this center, which will be publicly funded for up to 12 years, researchers of around the research groups of Prof. Mira Mezini and Prof. Eric Bodden (now at Paderborn University) have taken on the problem of Secure Integration of Cryptographic Software. Within the past years, those researchers have sought to develop a tool-based approach that will support developers in integrating off-the-shelf cryptographic components in the form of cryptographic APIs securely into application code, using features spelled out below. To make this functionality widely available to (Java) developers the team now seeks to offer it through the Eclipse platform.
 An Unconditionally Hiding and Long-Term Binding Post-Quantum Commitment Scheme, Cabarcas et al., Technical Report, June 2015.
 Homomorphic Signature Schemes - A survey, Traverso et al, SpringerBriefs in Computer Science, June 2015.
 An empirical study of cryptographic misuse in Android application. Egele et al. CCS 2013, November 2013; Why eve and Mallory love Android: an analysis of Android SSL (in)security, Fahl et al., CCS 2012
 Jumping Through Hoops: Why do Java Developers Struggle With Cryptography APIs? (Sarah Nadi, Stefan Krüger, Mira Mezini, Eric Bodden), In International Conference for Software Engineering (ICSE), pages 935–946, 2016.
 Why does cryptographic software fail?, Lazar et al., APSys 2014, June 2014.  https://nvd.nist.gov/cwe.cfm
Eclipse CogniCrypt will be restricted to supporting developers in using existing cryptographic APIs. The development of novel cryptographic APIs (or novel versions of existing crypto APIs) will be out of scope for this project.
The project will be specific to cryptographic libraries for popular programming languages, initially for Java, later maybe also for C/C++. The secure integration of security APIs that are not related to crypto is out of scope for this project.
The secure integration will be supported by development-time tooling including code generation and static analysis. The tooling is meant to work on incomplete programs. Hence, dynamic techniques such as dynamic analysis or dynamic security testing are out of scope for this project, as they would require a runnable program.
Eclipse CogniCrypt is planned as a set of Eclipse plugins, which to developers ultimately are meant to provide the following features:
- Generation of secure crypto-integration code
- Static analysis of existing crypto-integration code (to automatically and instantly highlight insecure integrations)
- Suggest better/more secure integrations via quick fixes
- Alert developers of security breaches of cryptographic algorithms
The project will initially support Java and Android projects only, through an integration with the JDT/ADT projects. In the future we might add support for C/C++ through an integration with CDT.
CogniCrypt's code-generation and static-analysis features are configured through crypto-library specifications, which are written in a domain-specific language called CrySL (Crypto Specification Language). CrySL specifications are written once, and then regularly maintained over time, by cryptography experts. This is supported by additional Eclipse plugins who support an XText-based editor for CrySL.
Initially, the project will provide built-in CrySL specifications for the Java Cryptographic Architecture (JCA), the default crypto API that ships with the Java Development Kit. At a later point in time, we plan to also provide CrySL specifications for other widely used crypto libraries such as BouncyCastle. The way CogniCrypt's tool support is designed, this will then automatically allow CogniCrypt to also support developers using those crypto libraries with targeted code generation and static analysis. CogniCrypt will be designed as an open framework, providing extension points allowing others to plug in CrySL specifications for other libraries as well. In particular, other researchers of CROSSING (see above) have signalled an interest in providing specifications for crypto libraries they themselves are developing as part of the CROSSING project.
Lastly, we might want to extend CogniCrypt with functionality to discover, download and install cryptographic libraries into Java/Android/C/C++ projects, jointly with their respective CrySL specifications, and to update them in cases where CogniCrypt has learned that a paritcular version of their implementation has been broken. This would require the CogniCrypt plugins to communicate with a web service giving information about those cryptographic libraries (and potentially even hosting copies of them).
Eclipse CogniCrypt, albeit in a rather mature state already, is currently an academic project, and its development is currently dependent on funding by the German Research Foundation (DFG). For 2017-2018, the project receives additional funding through an Oracle Collaborative Research Award. As we see the functionality provided by CogniCrypt as an essential one, we hope to sustain it for a long period of time. Sustainable development, however, could best be achieved by having others join into CogniCrypt's collaborative development.
We particularly hope that in the future external contributors will help provide CrySL specifications for cryptographic libraries that CogniCrypt does not currently cover, but, of course, we invite others to contribute to the further development of CogniCrypt itself as well.
By transitioning this project into the Eclipse ecosystem, we hope to create a win-win situation in which the project itself will gain visibility and attract external contributors, and where the project itself can yield a useful addition to the Eclipse IDE, protecting potentially millions of Java developers from security-critical programming mistakes.
The initial contribution will include first implementations of the following components:
- A static analyzer able to detect misuses of Java crypto APIs in Java (and Android) projects. The analyzer will be able to detect misuses of any crypto library for which a CrySL specification exists.
- An Eclipse plugin, based on XText, which allows one to create and edit CrySL specifications.
- An initial, comprehensive CrySL specification for the Java Cryptographic Architecture (JCA), the default crypto API that ships with the Java Development Kit.
- An Eclipse plugin, integrating with the JDT, that will invoke the static analyzer whenever saving a source-code file within a Java project that makes use of the JCA. The plugin will show erros/warnings as gutter annotations and in the appropriate problems view.
- A documented extension point that lets others add support for additional crypto libraries (besides the JCA). Our own JCA support will plug into this extension point, thus providing an example for others who seek to implement such an extension.
Eclipse CogniCrypt's static analyzer is implemented as an extension to the Soot program-analysis framework, which is under LGPL 2.1. As by now hundreds of people have contributed to Soot, its license cannot realistically be changed. Soot itself is based on a number of other libraries, which probably would have to be checked for licensing compatibility. Should issues arise with those libraries then we would look into replacing them for the initial contribution.
All other program code was written in-house so that we are reasonably sure that no IP should arise with the code contained in the initial contribution.
The name CogniCrypt is currently trademark-protected by Technische Universität Darmstadt. We will transfer the trademark to Eclipse via the Trademark Transfer Agreement.
The initial contribution is planned for December 2017. We hope to have a first stable version ready for release by February 2018.
- Add support for the generation of secure crypto-integration code
- Add support for suggesting better/more secure integrations via quick fixes
- Add support for alerting developers of security breaches of cryptographic algorithms
- Enhance the XText-based CrySL editor, for instance with more comprehensive type checks
- Add support for C/C++ projects. This will require the integration of another static analyzer (different from Soot).
- Add support for other cryptographic libraries (in the form of appropriate CrySL specifications), besides the JCA. We hope that others will provide such support as well.
- Add support for discovering, downloading and installing cryptographic libraries into Java/Android/C/C++ projects, jointly with their respective CrySL specifications, and to update them in cases where CogniCrypt has learned that a paritcular version of their implementation has been broken.