fixed a few links and added DNS and Firewall projects

This commit is contained in:
Sol 2019-10-31 13:06:40 +01:00
parent 199f161cd1
commit fd231c9044
2 changed files with 51 additions and 8 deletions

View file

@ -6,11 +6,11 @@ title: Projects
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. 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). 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. 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 [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.
#### More technical information: #### More technical information:
@ -38,13 +38,13 @@ Further links about the Bitcoin Piñata:
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 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. 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. 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 codebase 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. Our CalDAV server has a very small codebase 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. 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 CalDavZAP](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)! 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)!
@ -61,6 +61,49 @@ The CalDAV server is open source, with the code available on GitHub for the [ser
# DNS
The Domain Name System is used like a phone book for the internet - it translates human-memoizable domain names (e.g. robur.io) to machine-routable IP addresses (e.g. 198.167.222.215) and other records such as where eMail should be sent to. DNS is a fault-tolerant hierarchical decentralized key-value store with caching. DNS has been deployed on the Internet since 1987.
On the one side, the authoritative server, which has delegated responsibility for a domain, provides that mapping information (i.e. that a certain IP is the right one for a certain domain), and on the other side a resolver provides the functionality to figure out which server to request for each query a client has.
Since 2017 we have developed DNS, server, resolver, and client as a spare-time project. They serve different purposes in our ecosystem: the server is used by domains such as nqsb.io and robur.coop as an authoritative server; we use a caching resolver for our bi-annual hack retreats in Marrakesh; and the client is used by any MirageOS unikernel that needs to resolve domain names.
When developing this project we carefully considered which elements were strictly required and have ensured a minimal codebase, providing for better security and ease of use.
Since mid-August 2019 our DNS implementation replaced the existing, but incomplete and barely maintained [OCaml](/Our%20Work/Technology-Employed#OCaml) implementation. It is released to the opam repository.
A specific use case for this project is to combine a DNS resolver with a local zone (where it acts as server), and a DHCP server - a protocol used for dynamic IP address configuration - into a single service. We recently received confirmation of a grant from Nlnet via the next generation internet initiative from the EU to develop such a service based on our DNS library.
If you are interested in supporting this work, or knowing more about it please [get in touch with us](/Contact).
#### More technical information:
Our DNS implementation handles extensions such as dynamic updates, notifications on changes, authentication of update requests, zone transfers (all useful for provisioning X509 certificates via letsencrypt.org).
Using expressive types in OCaml we can ensure that for a given query type the reply record has a specific shape: querying an address record (A) results in a set of IPv4 addresses. Encoding such invariants in the type system reduces the boilerplate (or unsafety) which is there in other implementations.
The DNS code is available on GitHub for the [library](https://github.com/mirage/ocaml-dns) and [unikernels](https://github.com/roburio/unikernels).
# Firewall
Online security is vital and an important way to improve a network's or computer's security is a firewall that can block unwanted traffic going in and out. We are developing a lightweight firewall in the secure programming language [OCaml](/Our%20Work/Technology-Employed#OCaml) that is specifically designed to be implemented in [QubesOS](https://www.qubes-os.org/), a security-orientated operating system.
The Qubes-Mirage-Firewall is based on a project by Thomas Leonard. It is implemented as a [MirageOS unikernel](/Our%20Work/Technology-Employed#MirageOS), it is more lightweight and with a smaller codebase compared to the original Linux based firewall in QubesOS which has security and useability benefits.
In 2019, we received a grant from [The Prototype Fund](https://prototypefund.de) for 6 months work on this project. We would like to continue developing it further and if you wish to support this project with a [donation](/Donate), grant, or just want to hear more about the project please [get in touch with us](/Contact).
#### More technical information:
Thus far we have refactored the NAT library, made the firewall react to rule changes from the Qubes interface, and added a DNS client to the firewall. We added the ability to read rule changes from QubesDB. We added the ability to resolve domain names via a DNS client so that the rules can be written in a human-friendly way, and not just as computer-friendly IP addresses.
The smaller unikernel uses less memory, which is a rare resource in QubesOS, since Qubes runs many virtual machines. As opposed to the first prototype, it can react to rule changes without the need to rebuild and reboot the firewall VM.
The code for the firewall is on [GitHub](https://github.com/yomimono/qubes-mirage-firewall/), but still on several branches since we recently reworked the DNS parts.
# OpenPGP # OpenPGP
OpenPGP is a much-used standard of encryption and is widely used to encrypt text, files and emails, amongst other things. OpenPGP is a much-used standard of encryption and is widely used to encrypt text, files and emails, amongst other things.

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. 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](/Our%20Work/Projects/Bitcoin%20Pinata), 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> <table>
<tr><th></th><th>Linux</th><th>MirageOS</th></tr> <tr><th></th><th>Linux</th><th>MirageOS</th></tr>