by SCoP team
People love to receive mail, especially from loved ones. They trust postal workers won’t read private correspondence, but they risk their privacy when sending emails and messages. People send around 300 billion emails, often containing private or sensitive data, through portals with questionable security every single day. Most online communication services are composed of multiple components with complex interactions. If anything goes wrong, it results in critical security incidents. This leaves an unlocked door for malicious hackers to breach private information for profit or just for fun. Since it takes considerable technical skills and reliable infrastructure to operate a secure email service, only a few large companies can handle communications with the proper security levels. Unfortunately for regular people, these companies profit from mining their personal data. Due to this global challenge, Tarides focused their efforts to address these issues and find solutions to protect both personal and professional data.
Our efforts resulted in the project “Secure-by-Design Communications Protocols” (SCoP), a secure, easily deployable solution to preserve users’ privacy. In essence, SCoP puts your messages in a secure, virtual ‘bottle’ to protect it from invasive actions. This bottle represents a secure architecture using type-safe languages and unikernels for both email and instant messaging. We mould unikernels (specialised applications that run on a VM) into refined meshes linked by TLS-firm communication pipes, as depicted in the image below.
The SCoP virtual bottle creates a trustworthy information flow where dedicated unikernels ensure security for communication from origin to destination. Every component of SCoP is carefully designed as independent libraries, using modern development techniques to avoid the common reported threats and flaws. The OCaml-based development enables this safe online environment, which eliminates many exploited security pitfalls. Moreover, our SCoP project comes with energy-efficient consumption provided by the lightweight and low-latency design components.
The DAPSI project gave Tarides the incentive to further explore an open and secure infrastructure for communication protocols, especially emails. First, DAPSI supported our team by providing necessary financing, but their contribution to our project’s prosperity runs much deeper than funding. DAPSI facilitated multiple coaching sessions that helped broaden our horizons and established reachable goals. Notably, their business coaching enabled us to identify solutions for our market strategy. Their technical coaching and training offered access to data portability experts and GDPR regulations, which opened our perspective to novel trends and procedures.
Additionally, DAPSI helped raise our visibility by organising public communications. The two presentation sessions gave us the opportunity to observe peer strategies that provided inspiration and direction. Furthermore, DAPSI’s feedback revealed insights on how to better exploit our project’s potential and what corners of the cyber-ecosystem to prioritise. We are deeply grateful to DAPSI for their support and backing.
DAPSI journey – Achievements from first phase of the DAPSI programme
Although our SCoP bottle-making process started before DAPSI, where we used OCaml’s type-safe functionality to create unikernels, our journey with DAPSI enabled us to use our unikernel technology to protect messages. By placing them in our SCoP unikernel ‘bottles’, we ensured the message’s security from origin to destination.
Through Phase I, we focused on the sender’s side, securing the message inside the SCoP bottle. For instant messages, we created a capsule with a Matrix client library, and for emails, we based our bottle on the SMTP protocol and Mr. MIME. For further protection, we developed the bottle’s ‘cork’ with the Hamlet email corpus.
Our process and each element are described more fully below:
First, we generated Hamlet, a collection of emails to test our parser implementation against existing projects, to ensure that they kept equivalence between the encoder and decoder. In Phase 1, we successfully parsed and encoded one million emails! In Phase 2, we used Hamlet to stress-test our SMTP stack.
Secondly, we created an SMTP extension mechanism and support for SPF, including an implementation for DMARC, a security framework in addition to DKIM and SPF. We completed four components in Phase1: SPF, DKIM, SMTP, and Mr. MIME, which can generate a correctly-signed email, signatures, and the DKIM field containing the signatures.
In essence, we designed the SMTP sender bottle with a mesh of unikernels connected via secured communication pipes. The SMTP Submission Server unikernel receives the sender’s authentication credentials against the secured database maintained by Irmin. After it confirms the credentials, it sends the email for sealing (via a TLS) pipe to the DKIM signer. Then the DKIM signer unikernel, responsible for handling IP addresses, communicates via the nsupdate protocol with the Primary DNS Server. The DKIM signer places the sender’s and receiver’s addresses on the email, seals it with the DKIM signature, and sends it to the SMTP relay for distribution. The SMTP relay unikernel communicates with the DNS resolver unikernel to locate the receiver by the DNS name, then it coordinates this location with the Irmin database to verify the authorization according to the SPF protocol. After all these checks have passed, the signed and sealed email is secured in the SCoP bottle and launched through Cyberspace.
Next, we developed 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 designed an initial PoC for a Matrix’s server-side daemon.
Finally, we made significant progress in deploying DNSSEC, a set of security extensions over DNS. While we completed our first investigation into the DNSSEC prototype, we also discovered several issues, so we addressed those as lessons learned.
DAPSI journey – Achievements from 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.
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.
Although we encountered several issues in our work, they served to help us learn a few things. First, we realised the importance of allowing ample time to integrate our work with the greater ecosystem. Through the course of the project, it became clear that our time estimates were quite optimistic, especially in the context of security protocols where one must get everything right.
Secondly, it would’ve been beneficial to develop a continuous-testing infrastructure to check unikernel-compatibility earlier in the project, then account for the corresponding time in our project estimates.
Lastly, we should’ve developed a continuous-deployment infrastructure to test that the documentation for deploying unikernels (for IoT and Cloud) remained consistent over time. This would have helped us in later project stages, since testing the deployment of multiple interconnected unikernels turned out to be a complex and time-consuming task.
In conclusion, even though we had ambitious goals, they allowed us to identify exciting potential for future work. Overall, we consider the SCoP Framework a great opportunity and a strong foundation for future development, since we succeeded in developing a working secure SMTP service as well as secure-by-design OCaml Matrix client and server.
We currently use a bare-metal server to deploy unikernels, but it would be interesting to deploy them on a smaller chipset, such as IoT, for example. In this context, we might need to adapt and extend the unikernels ecosystem to offer other communication protocols. We’d also like to look at contexts requiring secure data porting in other domains such as journalism, law, or banking.
Moreover, we plan to conduct maintenance work for each of the SCoP components in order to follow the latest available standards and state-of-the-art technology. This includes periodical security analyses of our code-base and mitigation for newly discovered vulnerabilities. Finally, we plan using the learned lessons to define standalone, additional work items that would greatly benefit both our project and the entire community.
Please find more information on our work at tarides.com, especially our posts on the DAPSI Initiative and DAPSI Phase 2.