Password are just good for humans, not for robots. Using certificate for authentication is the way to go. Certificates use password larger than any brain can remember, and can be used for signing and identifying. If you still like passwords, you can use a PIN code with your certificates.
SSL provides a standard and widely used solution for handling security with certificates. SSL use public/private keys pairs, just like SSH and GPG, but focus on a mighty authority. Here are Alice and Bob, every cryptographer know them. Alice and Bob need to talk. Alice and Bob have key pairs, a private and a public one. The public key is packaged in a certificate. To communicate, Alice and Bob need to trust each other's certificate. SSL says : certificate can be signed by an other certifcate and build a chain of certificates. If Alice and Bob certificates are signed by the same authority certificate (even through a chain of trust), and if Alice and Bob trust this authority, they can trust each other. This is called trust delegation. Today, operating system and web browsers provide certificates from worlwide authority, like Verisign and its friends. You can buy certificate signature from them, or, if you can deploy certificates securely, you can manage your own certificate authority.
OpenSSL is the flagship of free SSL implementations. There are alternatives like GNU-TLS , cyaSSL and many others. SSL is just a bunch of specifications, so implementations should be interoperable, and negociations are parts of the protocol.
Using SSL for authentication is exotic for some clients (mail reader, web browser ...), mandatory for others (openvpn, mosquitto ...) or agnostic wrapper for authentication less protocol (carbon ...). Be careful, these examples concern connected protocols, based on TCP. For UDP, it's a new sport : DTLS. Just for the point, SSL is now TLS, they still cohabitate, but SSL (in its third version) will be replaced by TLS in the future.
Kluczy , wich means key in Polish, is an attempt to provide a simple and explicit tool to handle certificates. It is built on Python wrapping Openssl. You don't have to care about Python, it's just a commande line tool using packaged libraries in Debian.
Kluczy uses scaffolding, just init a new project (one project per private service).
mkdir toto cd toto kluczy init A dummy config.ini file is created, just edit it. Bake it, and it's done.
kluczy run CA.key and CA.crt is your Certificate Authority key pairs, don't mess with them. This CA is self signed, it's a root certificate, it will be only used to sign certificates, CA.crt will be spread on every clients. CA.key should be stored safely. Example keys pairs, Alice, Bob and Cecilia can be used both client or server side. Everything are standard SSL files. Just check them :
openssl rsa -in alice.key -check openssl x509 -in alice.crt -text You can use them for identifying a server (with CA.crt client side), securing communication, and even authentication.
Alice launch a server :
openssl s_server -cert alice.crt -key alice.key Anonymous connect it :
openssl s_client -connect localhost:4433 -CAfile CA.crt Alice launch another server, and require authentication (anybody signed by the CA cannnect):
openssl s_server -cert alice.crt -key alice.key -CAfile CA.crt -Verify 1 Bob connect it:
openssl s_client -connect localhost:4433 -CAfile CA.crt -cert bob.crt -key bob.key You can version this folder (be careful where you push it, publishing private keys without password on github is always a bad idea), edit config.ini and re-bake, everything missing should be now built. If you add users, keys pairs will be created, if you change keys, new certificates will be generated.
For now, Kluczy just does that. Enough for using Openvpn, Carbon, Mosquitto ... this kind of private secured services.
In a paranoid world, Certificate Authority should never see privates keys, only exchanging certificate request is needed (csr file). But for now, Kluczy just handles private authentications, a bit like Easy RSA. Later, it will mail certificates (gpg signed) for a batch of users, signing certificates as a service (each side keeps its private key hidden), and handle more SSL features (revocation list, version, etc ...).
