OpenBSD which is arguably the most security anal OS out there have just release their latest monty python inspired version 3.5. Check the OpenBSD 3.5 Release Notes Here for all the cool new stuff.
Some of my favorite features for using it as a firewall or generall purpose corporate mail/web/whatever server are:
- CARP Support for sharing an IP dynamically between multiple servers
- Email Greylisting
- If you are using a VIA C3 processor (These are popular in home built firewall boxes), their OpenSSL is configured to use the chips hardware AES accellerator.
- As always PF the built in packet filter (read firewall) is always improving. (To me PF is the number one reason for using OpenBSD.
They also claim major improvements in PThreads. I’ve always heard that pthreads was one of the reasons that Java was never stable on OpenBSD. Java is generally run under the built in linux emulation layer. For more information see State of Java/Tomcat on OpenBSD
If it was more stable I would move everything there. For now its superb for handling apache, mail, firewall etc.
The real reason why anyone should use OpenBSD, is that it works really well out of the box and is super secure. If you have any experience with Linux or Unix you can pick it up real quick. There are virtually zero gui admin tools that I know off, so if you aren’t willing to invest a bit of time in getting to know it, I wouldnt recommend it.
Remember to check the traditional Release Song
We have launched a sneak preview of our neuclear demo site NeuClear Bux. This is an example of a simple electronic currency application using NeuClear.
The currency it self is backed by absolutely nothing. However please try it out and write your comments on the mailing list, in the comments here or on our Jira
To actually use the site, you need to run our “NeuClear Personal Signer”::http://neuclear.org/display/neu/Personal+Signer.
Instructions can be found at:
Running Personal Signer
For the daring who know they have Java Web Start installed just click below
When you log in feel free to request any amount of Beta Bux our play money. If you want someone to pay to type “http://talk.org/pelletest.html” in the payee field.
During the last week we’ve reached the end of our short 3 month summer time and the rains have returned.
In Panama people say Invierno (or Winter) for the rainy season and Verano (or Summer) for the Sunny season. Winter time pretty much stays with us until the end of December.
Panama’s rain is very intense and you really cant walk around in it when it starts, but the good thing is that the rain is normally only for a few hours every day. The rest of the time we have sunshine mixed with clouds. Right now it’s sunny actually. So you can still go to one of the many nice beaches on the Pacific or the Caribbean even now and with the bonus that there are very few people visiting now.
NeuClear ID aims to simplify the development of applications that require digital signatures. We have created a new PKI that is vastly simplified and based on common easy to understand standards such as http, xml and html. Very few people completely understand X509 and all its associated alphabet soup. In reality applications developers have prefered to stay away from that area and live without PKI because of the complexity. We have aimed to cut the complexity and use simple technology that developers already understand.
The basic rule of the PKI in NeuClear ID is that any Signed XML document counts as Signed Object as long as it is a “Enveloped Signature” and embeds it’s public key.
Key Management or not???
There are many complex key management protocols out there, but lets be honest. Who understands them all and how many have actually implemented them for more than just internal applications. NeuClear ID skips that whole process by requireing that the public key be shipped along with every message. In most cases this is not a lot of extract bulk. (My 1024bit RSA public key takes up exactly 323bytes in XML).
This basically means that any NeuClear Transaction can immediately verified, without any long boring key management code.
Object Identity
Every object within NeuClear ID is the Base32 encoded SHA1 digest of it’s Canonicalized form. Wow thats a big mouthfull, but what it means is that every object has a 32 character id, that is calculated by its content and not created by an external authority. NeuClear Messages do not have a ID field, they are themselves as a whole its ID.
Who’s who?
Every public key has a unique ID generated which is generated similarly to the object identity. It is the Base32 encoded SHA1 of the encoded public key. In a payment application you could say:
Pay “sfjaenowpzytkls4wtqdqhks7k55obbc” $100
However I could also create a Identity descriptor in html. See http://talk.org/pelletest.html for an example.
This descriptor is both human and machine readable. I can put little hints into it about various things, but the key is the signature. It includes my Public Key. I can actually tell a NeuClear Payment Server to do the following:
Pay “http://talk.org/pelletest.html” $100
Try it yourself at our new absolute beta NeuClear payment server NeuClear Bux
In the future these identity html files can include FOAF notation to build up your own web of trust managed PKI.
What about CA’s
I’m sorry, but in most cases it’s highly irrelevant what CA’s certify. We leave the CA’s out of the equation. A bank may need to know my address for legal reasons, but if I am buying an electronic download, do they really need to verify who I am or do they only need to verify that the person who paid is the person who gets the download?
Coding
Programming is very simple. See the Busy Developers Guide for a simple overview. To give a quick example of making a payment I’ve included the below snippet:
Asset asset=(Asset) Resolver.resolveIdentity("http://bux.neuclear.org/bux.html");
DefaultSigner signer=new DefaultSigner(new SwingAgent());
Builder builder=new TransferOrderBuilder(asset,"http://talk.org/pelletest.html",new Amount(amount),"transfer by code");
SignedNamedObject obj=builder.convert(signer);
TransferReceipt receipt=(TransferReceipt) asset.service(obj);What the above does is that it first resolves an Asset descriptor, which is basically a more advanced version of the Identity descriptor I talked about earlier. Creates a Signer (see This post for more). It then creates an unsigned business object (XML behind the scenes), Signs it and sends it to the Assets web service, which sends back a Receipt.
Digital signatures are mostly invisible to the users. Users of SSL and SMIME may know that there is a digital signature involved with their web browser or email application by seeing a little extra icon on their screen.
PGP has always thrown the signature right into your face, which I like. Obviously a user cant verify that the signature is there and not a fake, however he knows that he now has to do something with it.
With the new release 0.13 of NeuClear XMLSig we have introduced HTML signing. To help bring some of that same effect to HTML. These signed html pages will be used as official human readable Identity pages, Service Descriptors etc within the NeuClear framework for commerce.
For an example of a simple signed html page see: http://talk.org/pelletest.html or http://bux.neuclear.org/bux.html
These pages are fully compliant with the XML-Signature Syntax and Processing standard.
The main problems I’ve had with them so far is that the only browsers I’ve been able to get to accept style’s for the xml elements are mozilla and firefox. The actual Signature element in an Enveloped Signature has to be a direct child of the parent element, so it comes within the html tag but not within the body tag. It does work though at the moment.
To do it correctly within xhtml I would really want to place it within the body tag. This is doable in the standard, but only using an xpath transform. I’m not too crazy on those as I believe they could in the future be a source of a bunch of new security holes, so I prefer what I’ve got now.
Creating an Signature on an HTML file
If you would like to try it your self, run the NeuClear Personal Signer with Java Web Start and select “Sign File…” from the File menu. It will allow you to select html and xml files for signing.
Our implementation uses JTidy to convert plain html to xhtml before signing.
Signing in your own code
// First we will load the DefaultSigner
DefaultSigner signer=new DefaultSigner(new SwingAgent());
// Create an InputStream containing html file
InputStream is=new BufferedInputStream(new FileInputStream("MyContract.html"));
// Create the Signature with the given signer
HTMLSignature html=new HTMLSignature(signer,is);
// the PrimaryReferenceElement contains the signed html
System.out.println(sig.getPrimaryReferenceElement().asXML());For more information on DefaultSigners etc read my last blog entry: Released new Crypto Tools
For more information on using XML Signatures with the NeuClear XMLSig library see our Busy Developers Guide to the NeuClear XMLSig library
I have just released NeuClear-Commons version 0.7 which is turning into more of crypto library than a general purposes utilities library.
There are many parts of the library that make crypto a easier:
Signers and Agents
Signers are designed to shield the developer from the average complexities of writing code to handle digital signatures. It also can hide many average security user interface issues, allowing developers to focus on the actual functionality of their code.
Signers and Agents are pretty much required for everything to do with programming for NeuClear and help providing much of the core functionality.
What are Signers?
Signers are pretty much supposed to be black boxes. You ask them to sign something and they figure out how to get the passphrase, loading the keys etc.
We have several implementations of Signers:
- JCESigner (Uses a Sun JCE KeyStore class)
- SQLSigner (Uses a database via Hibernate to store the keys)
- DefaultSigner (Interactive Signer which wraps around JCESigner for end user applications)
Passphrase Agents
Most signers need to interact with the user or administrator via a passphrase agent. You instantiate one of these in your code and pass it to the constructor of the Signer:
Signer signer=new DefaultSigner(new SwingAgent());We have the following interactive agents available:
- ConsoleAgent
- SwingAgent
- GuiDialogAgent (Java awt)
- ServletPassPhraseAgent
Of which SwingAgent is the recommended and most advanced.
Non interactive passphrase agents
Anytime the signer needs a passphrase it asks the agent for it. Not all of them are designed for interactive usage. Imagine a server application. You dont want the administrator there typing the passphrase like crazy everytime there is a hit on the server.
- AlwaysTheSamePassphraseAgent
- AskAtStartupAgent
- StoredPassphraseAgent
All provide a passphrase transparently to a server based digital signature application. The administrator can configure and pick which type he chooses to use.
Signing Data with a Signer
So how do you do something simple like sign some data? Simply speaking you have a reference to a Signer and just tell it to sign something:
byte signature[]=signer.sign("operations",data);“operations” is the alias of the private key to use for the signature. This is useful for servers, where an administer sets up the KeyPairs and can specify which one to use.
If you are however writing an interactive gui application and you would like to give the user a choice of which key to use. You need to use a BrowsableSigner
byte signature[]=signer.sign(data);This would pop up the following dialog:
This allows the end user to pick his own keystore file, create new personalities etc.
Crypto Streams
While there is already a CipherStream in the JCE. You still need to setup the cipher etc. These were designed for absolute ease of use.
Encrypting an OutputStream with a Password
PassphraseAgent agent=new GuiDialogAgent();
FileOutputStream fos=new FileOutputStream("encrypted.data");
PasswordEncryptingOutputStream sos = new PasswordEncryptingOutputStream(bos, agent.getPassPhrase("encrypted.data"));
sos.write("hello world".getBytes());
sos.close();You can similarly decrypt with PasswordDecryptingInputStream. For serializing and deserializing password encrypted objects use SealedObjectInputStream and its Output equivalent. In addition there are streams that simplify Digests, Sigining and Verifying data.
Crypto Channels
If you are using NIO you may like to use these channels as they simplify performing crypto on channels:
Using DigestChannel to calculate the SHA1 Digest of a file
DigestChannel ch=new DigestChannel();
FileChannel fch=new FileInputStream(file).getChannel();
fch.transferTo(0,fch.size(),ch);
byte digest[]=ch.getDigest();Using SigningChannel to calculate a signature of a file
SigningChannel ch = new SigningChannel(kp.getPrivate());
FileChannel fch = new FileInputStream(file).getChannel();
fch.transferTo(0, fch.size(), ch);
byte sig[]= ch.getSignature();Using VerifyingChannel to verify the signature of a file
VerifyingChannel ch = new VerifyingChannel(kp.getPublic());
byte sig[]= .... // get the signature from somewhere
FileChannel fch = new FileInputStream(file).getChannel();
fch.transferTo(0, fch.size(), ch);
ch.verify(sig);
Geeze, for the past week or two SourceForge has been timing out on me on a regular basis.
I’m using the ssh cvs for updating and commiting changes to NeuClear and I often have to retry up to 20 times for it to actually do an update or commit.
It’s a real pain as I work at home in the morning and go in to the office in the afternoon. If I cant commit all the work I’ve done in the morning I cant continue working in the afternoon in the office.