KRAKEN incorporates cutting-edge cryptography to achieve its goal of a user-centered marketplace, where sellers still have sovereignty over their data.
Our team of experts built a cryptographic ecosystem utilizing a mix of well-established cryptosystems alongside modern cryptographic building blocks, which see their first real-world usage.
Naturally, our cryptographers can guarantee the mathematical robustness of the building blocks and the resulting cryptosystem, as we can see in Deliverable 4.1 of the KRAKEN project.
Nevertheless, all this is for naught if the ecosystem's software introduces problems or vulnerabilities.
This post discusses the secure implementation of cryptographic components in the KRAKEN project. Of course, we cannot exhaustively present all the work we did throughout the project with this format. Instead, we will focus on our testing environment and talk about the importance of continuous testing.
When we look at the picture below, we can see the different components of one of our use-cases, namely the "Data Analytics as a Service."
We can categorize the components into two distinct categories:
1) The first ones are the already established cryptographic building blocks that, e.g., enable integrity and confidentiality during transmission.
The golden rule fur such components is to always reuse existing, well-tested implementations.
We followed that rule, of course, also in the KRAKEN project, and we strongly recommend doing this for all software projects.
There is virtually no exception to this rule, except you may have guessed it if you are a research project that implements those components for the first time.
2) For the second category, our team of software engineers established a workflow to identify possible vulnerabilities as soon as possible. The most prominent one is our testing system. The easiest and most fundamental way to identify problems in software is by thoughtfully testing.
We utilize Github Actions for continuous testing. Github executes all registered tests (including unit tests, integration tests, functional tests, etc...) via Docker containers on every push to our repositories. As soon as the tests finish, we transmit the results to SonarQube, analyzing the results with additional metrics.
We can intercept many attack vectors with this workflow, including side-channel analysis on failure, implementation attacks, and many more.
Of course, this is only the very first step and more of a granular approach. To pinpoint more complex concerns, you need more fine-grained policies, e.g., dynamic and static code checking.