Caramel

Caramel is a CA authority software package that provides certificates to all deployed servers and devices. It provides strong, unique identity management based on short-lived x509 certificates. Caramel is free and open source software and can be found on the Caramel project page as well as on GitHub.

What is Caramel?

Caramel is a certificate management system that makes it easy to use client certificates in web applications, mobile applications, embedded use and other places. It solves the certificate signing and certificate management headache, while attempting to be easy to deploy, maintain and use in a secure manner.

Caramel makes it easier (it's never completely easy) to run your own Certificate Authority and manage and maintain keys and signing periods.

Caramel focuses on reliably and continuously updating short-lived certificates where clients (and embedded devices) continue to "phone home" and fetch updated certificates. This means that we do not have to provide OCSP and CRL endpoints to handle compromised certificates, but only have to stop updating the certificate.

What it does now

Example implementations are currently deployed on server and embedded side. It is in production and scales up to signing 200+ certificates per second while still using an SQLite backend. For higher concurrency and networked safety, we recommend a PostgreSQL server environment.

Frontends exist for sh (busybox compat), Python and JavaScript. There are also various tools for server-side automatic refresh (using cron).

Future Implementations

An example frontend in JavaScript for authenticating against web applications has been built, but the usefulness is limited until there is a proper way of integrating with the local certificate store from JavaScript APIs. The current proof of concept still requires manual intervention (clicking on a dialogue) when a certificate has to be updated.

Android and Java versions are planned, as well as an embeddable C version. However, until then the example code should be simple to build upon.

How does Caramel work?

Caramel is a REST-ful web application that accepts Certificate Signing Requests (PKCS#10, hereafter CSR) from anyone, stores them, and possibly returns a signed certificate.

A client pushes its CSR to the public web application. The web application validates the CSR, in a way that is stricter than the normal standard, and stores it in a database.

A backend (administration) web application or command line tool talks to the same database (preferably from inside an intranet or other secure place), and lets you view, reject, refresh or sign requests.

The certificates are signed with a short lifetime (hours or days), and the client side is supposed to regularly contact the public web service and download a freshly signed certificate. Root (Certificate Authority) keys only live on the "administration" part, and should preferably be kept on a non-public machine.

Validated mode

In this mode of operation, an administrator validates each request & each identity either manually, or physically by means of isolated networks. Clients are continuously refreshing their certificate as needed, and a strong proof of identity as well as authenticity is guaranteed.

Leap of Faith mode

In this mode, you only care that no one can impersonate a client. Anyone can, anonymously, get a certificate signed, and the only thing it proves is that it is the same client (Authentication) every time. This can then replace stored passwords, one time cookies, tokens or other proofs of authentication.

This mode works well in Mobile Apps, instead of various tokens and hard coded proofs. After initial authentication, a secondary step of identification can be made, in order to (strongly) map a user account to one or more certificates. The secure implementation of this is left as an exercise to the reader.

Development

Development is done in the open, releases happen based on activity and implemented features. It's important to not reimplement cryptographic routines in Caramel, only use well audited and established codebases for crypto parts.

For user-facing code we require testcases and all data has to be validated both semantically and syntactically. We have placed various limits on top of the already existing ones in the X509 standards, in order to reduce variability in requests and certificates. We do not allow text encodings other than UTF-8, we require Subjects to keep strict ordering as well as format, in order to avoid multiple representations of the same content.

Validation also happens on multiple levels. Just because a CSR can be accepted doesn’t mean it won't get (automatically) rejected at a later point. A typical example of this is the autosign daemon which requires all Subjects to match a UUID, and which will reject everything else.

Philosophy

  • Do not reinvent the wheel
  • Use libraries
  • Use frameworks
  • File bugs
  • Use standard Unix tools
  • Keep protocols strict
  • Software should have opinions
  • This is an Engineering project

Ideas and food for thought

It would be fun to explore using OpenSSH Certificates.

  • http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-keygen.1?query=ssh-keygen&sec=1
  • https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

It would be interesting to support NaCL (LibSodium) Certificates

  • http://doc.libsodium.org/public-key_cryptography/public-key_signatures.html

Licensing

The server side of the code is released under the GNU Affero General Public License v3. Client side code is licensed either under the Apache 2.0 License or the Lesser GPL License. For custom implementations or licenses, feel free to contact Modio