CISC Cothority Identity Skipchain SSH Interface

SEMESTER PROJECT CISC Cothority Identity Skipchain SSH Interface January 17, 2017 Responsible: Prof. Bryan Ford Author: Andrea Caforio Supervisor: Linus Gasser Decentralized and Distributed Systems Laboratory Ecole´ Polytechnique Fed´ erale´ de Lausanne DEDIS 1 I. INTRODUCTION Identification has become a crucial part of the digital world especially in the Internet where authenticity is one of the most important safety measures. Nowadays it is hard to keep track of all different passwords and public keys that we use to authenticate ourselves to different services. In the worst case the same key is used for several services. Figure 1: Abstract depiction of the Cothority interacting with In order to solve this issue, keys must be regularly updated devices and clients. and rotated, which is cumbersome when multiple devices come into play and basically unattainable without the help of specialized software. In the subsequent section this report will describe how the The Cothority project at DEDIS fills this gap using an analysis of the problem was conducted and what tools for the approach that resembles the Blockchain mechanism that lies later implementation of such key-storing application on both at the heart of the Bitcoin project. In the case of the Cothority client side (Android, Java) and server side (Cothority, Golang) the Blockchain is a double-linked list, called Skipchain, that were chosen. Further sections are covering the challenges and is able to store arbitrary data. The backward links between problems that arose during the implementation, the strategies the blocks preserve the order of the list and consist of chosen to circumvent said issues, a detailed description of cryptographic hashes of the preceding block. A forward link the final product as well as its limitations and possible future is only added when a newly proposed block is accepted by enhancements. a majority of participants. Those entities are called managers and are usually user devices like Laptops or Smart-phones The details on voting on a change in the Skipchain and verifying II. ANALYSIS the integrity of the entire data structure are describe later in the text. The Cothority comprises a large and sophisticated code base almost entirely written in Google’s Go programming lan- For a user this means that he should be able to rotate a guage. A fully functional network communicates with the help key for security reasons, introduce new data to the Skipchain of a protocol that in the early days relied on Protobuf but is as well as delete obsolete data. The data we are working wired in the meantime over web sockets. [4, 5] The first step with in this project are public/private key pairs in particular on the road to this semester project was therefore acquiring secure shell (SSH) keys that are widely-used for remote some picture of the internal workings of the Cothority project logins and authentication on websites like Github, however with a shy goal of establishing a network connection to a this is a merely self-imposed restriction. As mentioned before running node. At this early stage of the project it wasn’t the Skipchain is able to store basically any type of the really clear which framework would be the most suitable. data which leads to possible use-cases involving PGP keys The suggestions went from some multi-platform technolo- instead of SSH-keys or even ordinary passwords or software gies like Meteor, which would have facilitated the creation updates. of single application that could run on both Android and iPhone as well as in any browser using JavaScript, to a plain Whenever a user requests a change, due to key rotation Java approach targeted to Android handhelds.[18] However it or lost/new devices, he initiates an update to the Cothority rapidly became clear that nothing other than the latter was notifying the other devices in the Skipchain, which in turn then worth further considerations. This was mainly due to the have to agree on the proposed change by transmitting their complex way messages are exchanged between a potential digital signatures (voting) of the updated block. If a certain device and a node of the Cothority, which involves non-trivial threshold of votes is reached the change is accepted into the cryptographic measures (i.e. signatures) that turned out to be Skipchain. This is synonymous to appending a new block to too cumbersome in order to be handled by languages that the chain. Like that a potential attacker who gets hold of a don’t offer stable support for network communication and low device is not able to interfere with the Skipchain in a harmful level bit manipulations. way without also controlling at least the threshold amount of devices. Clients, sometimes also called followers, like Github The next hurdle came in the form of the Protobuf serial- can then easily track the Skipchain and are notified upon ization protocol used to push messages into the network. every change. Furthermore, because the Cothority service is Since it is already integrated as a crucial part of inter-node distributed, clients can poll several servers in case one or communication it seemed natural to use this interface also more go offline or the connection drops, basically making for exchanging messages with an Android client. It actually the service very resilient. turned out to be a harder problem than choosing a fitting platform. The way the Cothority implements the protocol By using the Cothority and its Skipchain a user should be able buffers does not allow for communication with anything other to comfortably manage a unique SSH key for every device he than a node in the network. This meant that a substantial owns, which in return yields a great enhancement in security amount of the code base needed to be rewritten to make and corresponds well to the recommended practice on how to such a thing possible. Clearly, this was a dead end an other handle public/private key pairs in the wild. solutions had to be found. In the end, we settled for a 2 more crafty but still simpler way by using the ever more JSON implementation is not able to serialized complex data popular JSON objects instead of Protobuf. By gluing a little structure like hashes or public keys. In order to navigate proxy message receiver onto the existing network stack of around this issue all message fields which are not primitive the Cothority enabled for the first time to send and receive types like strings or integers are encoded into base64 messages emitted from an Android device. On the handheld before being passed over the network. Now when the server side things looked far more comfortable. Google’s Android receives such a message it reassembles its original content developer suite has reached such a maturity that a application and converts the intermediate structures into their proper almost programs itself, coupled with the unbeatable richness equivalent that can be understood by the interface associated of the Java environment fast progress could be made.[10] Still to the Cothority. For example, performing a vote on an some aspects of the application needed some special attention. updated block consists of sending a serialized JSON object For example handling network connections required a robust containing the user’s signature of the block to the Cothority, and error-free handling of threads and processes inside the which then would look similar to the following code extract. Java run-time such that a user is completely oblivious to anything that could block the graphical user interface. Fur- ProposeVote { ther, because every communication is strictly initiated by the ID: "YXNkZmdoa2xtbG..." Android device and then acknowledged by a Cothority node, Signer: "user1" the HTTP-protocol had to be sketched out very precisely. Signature: "MzJycWtlZmFqbz..." Luckily, there were already some stubs for a potential future } API inside the Cothority code base, which made the design of said protocol a breeze. This all made the creation of some simple proof-of-concept application possible within some few Here the ID is a 32 byte base64 representation that identifies weeks. Nevertheless, the application as well as the Cothority a specific Skipchain handled by the Cothority. More precisely hadn’t been doing anything productive up until this point. The it’s the hash of the very first block, also known as genesis simple exchange of serialized JSON messages was still a far block, of the chain. The signer field marks the name of the cry from an application that could verify a Skipchain issued by user device that emitted the message along with his signature the Cothority and manage SSH-keys with the help of it. of the block in question. also in base64 representation. We will see shorty how exactly a user needs to perform a signature The next section is therefore dedicated to the implementation in order to cast a vote. In case the received message is details of the various parts of the system that went on not corrupt and contains correct data the server will answer the be a working application fulfilling the duties mentioned with a generic 200 OK response code back to the Android before. device. Errors are treated similarly by sending standard 5** error codes which then trigger appropriate measure within the III. IMPLEMENTATION Android application. [23] Special care must be taken when handling the public key strings in a message. Here a standard The implementation details for both server side and Android base64 decoder is not sufficient enough anymore to recreate client are discussed in separate subsections followed by a little a key. Fortunately, DEDIS has an own cryptographic library detour about the involved cryptography parts in particular the entirely written in Go that is able to tackle such tasks.[3] signature of block and the important verification of a complete As soon as a successfully converted message is passed to the Skipchain.

Load more