About the project
Project Name: SCoP – Secure-by-design Communication Protocols
Create an open, secure and resource efficient infrastructure to engineer a modern basis for open messaging (for existing and emerging protocols) using type-safe languages and unikernels.
Over the past few decades, the usage of emails has been massively widespread by both individuals and companies. Billions of emails are sent every day and this number is expected to increase to reach 333 billion of emails exchanged daily in 2022. Moreover, end-users tend to delegate this task to third-party companies like Google and Microsoft, as managing internet communication software stacks became increasingly complex. Moreover, existing implementations of these communication services rely on ad-hoc methodologies and memory-unsafe languages, where minor developer errors could easily escalate into major security flaws. The centralization of communication services means that a successful attack is leading to major personal data breaches.
To fix this issue, this project aims to engineer a modern basis for open messaging that supports existing protocols such as emails but is also extensible and customizable for emerging protocols such as matrix. We will be building trustable implementations of these open protocols using type-safe languages and we will deploy these implementations as specialized, secure and resource efficient unikernels. They will become the basis of the communication system of OSMOSE, Tarides’ commercial solution for secure-by-design IoT infrastructure.
Every component of that system will be carefully designed as independent libraries, using modern development techniques to avoid the common reported threats and flaws. For instance, the implementation of protocol parsers and serializers will be written in a type-safe language and will be using fuzzing, e.g state-of-the-art coverage-driven test. The combination of these techniques will increase users’ trust to migrate their personal data to these new secure services.
Moreover, these techniques are also useful to produce a large and reusable corpus of test materials, and we also plan to release this corpus of tests separately for other implementations to use. It will give the tools to other developers to write the next-generation messaging applications by extending the existing protocols with more confidence.
Achievements from the first phase of the DAPSI programme
We generated a collection of emails to test our parser implementation against existing projects, and they keep equivalence between the encoder and decoder. We have successfully parsed and encoded 1 million emails!
Secondly, we implemented an SMTP extension mechanism and support for SPF, including an implementation for DMARC, a security framework in addition to DKIM and SPF. We’ve completed four components: SPF, DKIM, SMTP, and MrMIME, which can generate a correctly-signed email, signatures, and the DKIM field containing the signatures.
Next, we completed the Matrix protocol’s client library and we used it to enable notifications from the CI system testing all the new OCaml packages. We also developed an initial PoC for a Matrix’s server-side daemon.
Finally, we also made significant headway to implementing DNSSEC, which is a set of security extensions over DNS. While we completed our first investigation into the DNSSEC prototype, we also discovered several issues, so we’re currently working to address those as we head into Phase 2.
Achievements from the second phase of the DAPSI programme
In Phase 2, we completed the SCoP bottle with the email receiver, which Spamtacus (the Bayesian spam filter) guards against spam intruders. Furthermore, the OCaml-Matrix server represents our solution to take care of the instant communication in the Matrix federation.
A Secure-by-Design SMTP Stack
We researched state-of-the-art email spam filtering methods and identified machine learning as the main trend. We followed this path and equipped our email architecture with a spam-filter unikernel, which uses a Bayesian method for supervised learning of spam and acts as a proxy for internet communication in the SMTP receiver. This spam filter works in two states: preparation, where the unikernel detects spam, and operation, where the unikernel integrated into the SMTP receiver unikernel architecture to filter spam emails. Our spam-filter unikernel can also be used independently as an individual anti-spam tool to help enforce GDPR rules and protect the user’s privacy by preventing spam-induced attacks, such as phishing.
We integrated our spam filter into a unikernel positioned at the beginning of the SMTP receiver stack. This acts as a first line of defence in an eventual attack targeting the receiver in order to maintain functionality. The spam-filter unikernel can be extended to act as an antivirus by analysing the email attachment for certain features known to characterise malware. We’ve already set the premises for the antivirus by using a prototype analysis of the email attachments. Moreover, the spam-filter unikernel can contribute with a list of frequent spammers to the firewall, which we plan to add into the SMTP receiver as the next step in our development of SCoP.
Our secure-by-design SMTP stack contains the DKIM/SPF/DMARC verifier unikernel on the receiver side. This unikernel verifies the email sender’s DNS characteristics, and in case the DNS verification passes, the spam-labelled email goes to the SMTP relay to be dispatched to the email client. However, in case the DNS verification doesn’t pass, we can use the result to construct a DNS reputation list to improve the SMTP security via a blacklisting firewall.
Matrix Server
The Matrix server in our OCaml Matrix implementation manages clients who are registered to rooms that contain events. These represent client actions, such as sending a message. Our implementation follows the Matrix specification standard. From here, we extracted the parts describing the subset of the Matrix components we chose to implement for our OCaml Matrix server MVP. The OCaml implementation environment provides secure-by-design properties and avoids various vulnerabilities, like the buffer overflow recently discovered that produces considerable information disclosure in other Matrix implementations, e.g., Element.
The Matrix clients are user applications that connect to a Matrix server via the client-server API. In Phase 1, we implemented an OCaml-CI client, which communicates with the Matrix servers via the client-server API. We polished it during Phase 2 and tested the integration of the OCaml-CI communication with both Synapse and our OCaml Matrix server. Please note that our OCaml Matrix server supports a client authentication mechanism based on user name identification and password, according to the Matrix specification for authentication mechanisms.
Pitch
Testimonial
Since privacy and security concerns across the internet have increased over the past few years, the Tarides team has focused their efforts to address these issues and find solutions to protect both personal and professional data. The DAPSI project gave Tarides the incentive and inspiration to further explore an open and secure infrastructure for communication protocols, especially for emails. We truly enjoyed participating in the DAPSI project! We’re proud to have passed Phase 1, and we’re looking forward to Phase 2.
The Tarides team
Entities
