added CalDAV, VPN and Pinata

This commit is contained in:
Sol 2019-10-29 15:05:40 +01:00
parent 45c94d360e
commit 199f161cd1
2 changed files with 85 additions and 4 deletions

View file

@ -2,6 +2,65 @@
title: Projects
---
# Bitcoin Piñata
The [Bitcoin Piñata](http://ownme.ipredator.se) is a transparent [bug bounty](https://en.wikipedia.org/wiki/Bug_bounty_program): it holds the private key for a bitcoin wallet. It is a [MirageOS unikernel](/Our%20Work/Technology-Employed#MirageOS) designed to test our TLS and all underlying transport implementations.
Its open communication channels are HTTP and HTTPS, and a TLS client and TLS server endpoint, all written in OCaml(/Our%20Work/Technology-Employed#OCaml). The cryptographic material for TLS is generated on startup in the Piñata and is supposed to never leave it. However, if an attacker manages to establish a mutually authenticated (using certificates) TLS channel, the private key to the bitcoin wallet is transmitted over this channel, and the attacker gains access to the bait (the bitcoins).
The project was [launched](https://mirage.io/announcing-bitcoin-pinata) on February 10th 2015. At this time friends from the IPredator project lent us 10 bitcoins (back then worth ~2000 EUR) for the bait. By 2018 no one had successfully cracked the Piñata and the bitcoins, by this point worth ~200 000 EUR, were repurposed for other projects, however the project remains live, with a small amount of bitcoins in it, for anyone wishing to try to crack it.
[Hannes Mehnert](/About%20Us/Team) and David Kaloper-Meršinjak designed the Bitcoin Piñata to attract security professionals to look into our [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) stack, developed purely in OCaml since early 2014. The
#### More technical information:
On startup, the Piñata generates its certificate authority on the fly, including certificates and private keys, this means that only the Piñata itself contains private keys which can authenticate successfully.
The code base is [thousands of lines of code smaller](/Our%20Work/Technology-Employed#MirageOS) than equivalent implementations and we did not use many external libraries, and those we had to use we read carefully to avoid security issues.
The attack surface is any part of the unikernel (or deployment) - anything allowing you to get a valid certificate (signed by the cryptographic material which shouldn't leave the Piñata), or reading the memory location where the private key to the bitcoin wallet is stored, an exploitable flaw in any software layer (OCaml runtime, virtual network device, TCP/IP stack, TLS library, X.509 validation, or elsewhere), or anything else.
By using a Bitcoin wallet, the Piñata is a transparent bug bounty. Everybody can observe (by looking into the blockchain) whether it has been compromised and the money has been transferred to another wallet. It is also self-serving: when an attacker discovers a flaw, they don't need to fill out any forms to retrieve the bounty, instead they can take the wallet, without any questions asked.
The source code of the Piñata is [open source](https://github.com/mirleft/btc-pinata) and even the running binary (without the private bitcoin wallet key) is published in the git repository.
Further links about the Bitcoin Piñata:
- [Statistics after 5 months](https://mirage.io/blog/bitcoin-pinata-results)
- [Post about whacking the pinata](https://somerandomidiot.com/blog/2018/04/17/whacking-the-bitcoin-pinata/)
- [Evaluation 3 years later](https://hannes.nqsb.io/Posts/Pinata)
- [Usenix security research paper on TLS stack](https://usenix15.nqsb.io)
#CalDAV Server
The CalDAV server is a protocol for synchronizing calendars. Our goal was to develop a calendar server that is robust and less complex to configure and maintain than other services, allowing more people to run their own digital infrastructure.
The CalDAV server project began in 2017 when [Stefanie Schirmer and Hannes Mehnert](/About%20US/Team) got a grant from [The Prototype Fund](https://prototypefund.de) for developing a CalDAV server (RFC 4791) over a period of 6 months. After that funding period, [Tarides](https://tarides.com) sponsored us further, allowing us to achieve the current status of the CalDAV server.
Currently all basic features of a calendar are implemented, for example "please add this event to the calendar", and "modify the weekly meeting from now on to start half an hour later", and it is tested with a variety of CalDAV clients.
Our CalDAV server has a very small code base which provides a number of security benefits and it stores all the data in git so there is a history of changes, it can easily be exported and converted to and from other formats, and if a client behaves badly (by removing entries they cannot deal with), this can be tracked and reverted.
We would like to develop the CalDAV server further, adding notifications about updates and invitations sent via Mail (as described in [RFC 6638](https://tools.ietf.org/html/rfc6638)). In addition, currently it is a server only, and we would like to integrate a pure JavaScript client as a user interface in the same unikernel (such as https://www.inf-it.com/open-source/clients/caldavzap/). We also aim to integrate the related protocol CardDAV (address book), which could be integrated into the same unikernel.
If you are interested in supporting further work on the CalDAV server through a [donation](/Donate), with a grant, or require additional features to be implemented to accommodate your projects needs please [get in touch with us](/Contact)!
#### More technical information:
Based on existing HTTP and REST libraries, we developed a WebDAV library adequate for CalDAV (e.g. no locks, but ACLs, reports). The REST library needed some extensions to support more HTTP verbs that are used in WebDAV. We also developed an iCalendar (.ics, RFC 5545) decoder and encoder.
The CalDAV unikernel uses the developed libraries to serve requests from clients, which may be "what is the last update to the calendar?", or adding events or changing times of events. Access control is done by the attached metadata to the resource (i.e. only user Tim may access Tim's calendar, groups are possible). User and group (in WebDAV lingo principals) data are stored in the same storage as the calendars. For enrolling new users and groups, we provide HTTP endpoints. The administrator password is provided as boot argument.
The storage of our CalDAV unikernel can use any [mirage-kv](https://github.com/mirage/mirage-kv) implementation, being it a non-persistent only in-memory (not too useful for a real calendar since it is not persistent), a UNIX file system (if the unikernel runs as a UNIX process), or a remote git repository (which we recommend).
The CalDAV server is open source, with the code available on GitHub for the [server](https://github.com/roburio/caldav) and [calendar](https://github.com/roburio/icalendar).
# OpenPGP
OpenPGP is a much-used standard of encryption and is widely used to encrypt text, files and emails, amongst other things.
@ -13,7 +72,6 @@ This work is funded through donations and is still an ongoing project, which mea
You can assist us in implementing more of the OpenPGP protocol through a [donation](/Donate). If you are interested hearing more about the project, require additional features to be implemented to accommodate your projects needs, or are able to assist with a grant please [get in touch with us](/Contact)!
#### More technical information:
Robur maintains a partial, opinionated implementation of OpenPGP version 4 (RFC 4880) and the related standards, written in OCaml and compatible with MirageOS.
@ -22,7 +80,29 @@ The software consists of a library, and various UNIX tools that make use of the
Currently we have implemented signing/verification and encryption/decryption, but there is no support for elliptic curve cryptography. Decompression of ZLIB streams is supported through the use of a pure OCaml library called decompress. While some things are implemented with a streaming API, many operations make use of an in-memory buffer, which introduces memory constraints on the file handled (this is an area where there is definitely room for improvement).
The software is available [on Github](https://github.com/cfcs/ocaml-openpgp).
The software is available [on Github](https://github.com/roburio/ocaml-openpgp).
# OpenVPN
OpenVPN is a virtual private network protocol that started from a single implementation developed in C, without any specification document. Over time flaws were found in the implementation which lead to further revisions. Also several extensions were developed for coping with other needs.
This history meant that overall OpenVPN has a number of flaws and is overly complex due to revisions on revisions. We implemented only the most recent protocol version and require the current key derivation and authentication method.
We started from scratch developing it in [OCaml](/Our%20Work/Technology-Employed#OCaml) using existing cryptographic libraries and parsers. This approach allowed us to take some design decisions that have security benefits and our code base is minimal. We strive for compatibility of the configuration file, so our OCaml OpenVPN can be a drop-in replacement.
We began this work in 2018 with a grant from [The Prototype Fund](https://prototypefund.de). Whilst the code is available on [Github](https://github.com/roburio/openvpn) we have not released it yet as it needs further work (in terms of testing, performance evaluation).
If you are interested in supporting further work on our OpenVPN implementation through a [donation](/Donate), with a grant, or just want to hear more about the project please [get in touch with us](/Contact)!
#### More technical information:
Our main goal is a client implementation as a MirageOS unikernel (either forwarding all traffic to a single IP address or NAT of a local network via the OpenVPN tunnel), but we also developed a UNIX client which configures a tap device on the host and adjusts the hosts routing table accordingly. We extended our protocol implementation with a server as well. Testing is done against existing OpenVPN servers.
Our implementation has stronger security promises since we do not implement old protocol versions that are brittle. In addition it is fail-hard when using the NAT unikernel: if the tunnel is down, all packets are dropped (instead of sent unencrypted). We do not support questionable configuration options and we have safe defaults for the configuration.
@ -35,7 +115,6 @@ Solo5's interfaces are designed in a way that allows us to easily port them to r
Currently Solo5 is ready for use by early adopters and we plan to continue developing it further, if you are interested in supporting this development with a [donation](/Donate) or want to hear more about the project please [get in touch with us](/Contact).
#### More technical information:
@ -53,6 +132,8 @@ Compared to existing technologies, such as traditional virtualization using KVM/
Our goal for Solo5 is to enable the use of unikernel technology to build hybrid, disaggregated systems where the designer/developer can choose which components are untrusted or security-sensitive and "split them out" from the monolithic host system. At the same time the developer can continue to use existing, familiar, technology as the base or "control plane" for the overall system design/deployment, or mix and match traditional applications and unikernels as appropriate.
The software is available [on Github](https://github.com/solo5).

View file

@ -8,7 +8,7 @@ MirageOS is a software suite to build custom-tailored operating systems from (mo
It compiles the necessary OCaml libraries into a unikernel - a small operating system, each built for a certain purpose. For each unikernel we can pick from hundreds of permissively licensed open source libraries which implement network protocols, storage on block devices, or interfaces to network devices via the hypervisor or host operating system. As we only put into each one exactly what is needed, each unikernel is fast; instantly booting and, as there is less code base, it is easier to maintain and keep secure.
As an example to see how lines of code compare, here are the number of lines of code needed for different elements of our Bitcoin Pinata, measured in thousands of lines of code:
As an example to see how lines of code compare, here are the number of lines of code needed for different elements of our [Bitcoin Pinata](/Our%20Work/Projects/Bitcoin%20Pinata), measured in thousands of lines of code:
<table>
<tr><th></th><th>Linux</th><th>MirageOS</th></tr>