The UK MoD Manual of Security has been leaked

The UK MoD Manual of Security has appeared on WikiLeaks.

I'm not certain this is a good thing, to be honest... the intelligence services are renowned for overstepping their mark, and I'm sure the sections on dealing with investigative journalists and the like will be useful to those who fight against that kind of thing, but I suspect the bits about dealing with foreign intelligence agencies would probably have best been kept secret. Still, the cat is out of the bag, so perhaps it's no bad thing if the MoD are forced to have a total security audit and overhaul their manual

I've not managed to download it - WikiLeaks servers seem to be rather busy - but the front page does have some interesting snippets from the sections about visitors to China and Russia, discussing the kinds of things the local intelligence agencies do to try and extract Western commercial and military secrets.

This has some interesting bearing on the growing tendency to outsource software development tasks to developing countries. I know a lot of this work does go to China, and so we can probably assume that any intellectual property made available to developers in China is probably scrutinised by their security services and passed on to Chinese companies that may be able to benefit from it.

In the depths of my career history, I once worked on a software system that was to be used in a Government project to protect the nation's "critical national infrastructure"; and I gather that another part of the system was outsourced to an Indian development team. I'm not sure if the client was actually made aware of this, but at the time, I felt concerned that national security might be threatened by this.

n2n revisited

I have spoken before about n2n, the peer-to-peer VPN tool that makes it easy to create efficient virtual networks.

Normal VPN products are really more of a "virtual private cable" than a "virtual private network" - they just establish a point-to-point link over the Internet, requiring a login to set it up and encrypting the traffic. This means you can have a virtual connection to a real private network somewhere; and if a few people connect into that network via VPN links, then there really is a virtual private network between you all, but all going through a central point where all your links meet.

While with n2n, everyone connects to a shared "supernode" that keeps a list of who is connected to the VPN, and from where; then when you want to connect to somebody else, you use the list from the supernode to establish a direct encrypted connection between yourself and them, rather than going through any central point. So it's an actual virtual network out of the box. You can even have more than one supernode running, so that any one can fail; all the supernode does is to provide the directory service.

Also, you don't need to maintain a database of user logins; a supernode can carry any number of virtual networks. When you connect to the supernode, you just tell it the name of the community you want to join, and it will share your connection details with anybody else in the same community - you can make communities up on the fly rather than needing to maintain a central list. Access control is handled by the simple fact that you need to know the correct encryption key for the community you want to join, or your messages will be received garbled by everyone else, and ignored.

Anyway, for a long time, I wanted to get into n2n, but I couldn't as it didn't compile out of the box on NetBSD; but a desire for a better VPN solution at work has led to me getting it working. It wasn't that much work, in the end, as the existing FreeBSD support already had a BSD approach to things.

n2n is distributed via Subversion, so they don't have version tarballs - this is a problem for my NetBSD port. So I decided to mirror it into git with git svn, then forked it as "Kitten n2n", made my NetBSD port, tagged a release, pushed it to github, uploaded a tarball from that tag, and then made a NetBSD package of net/kitten-n2n.

I'll tinker with it for a few more days, then I'll submit it to the NetBSD folks for consideration.

I'll keep pulling in from the official n2n Subversion repo, to pull down patches, and I'll see if they'd like my patches pushed up - as well as NetBSD support, there's a few things I'd like to fix as well (I've spotted passing an integer through a void* by casting, which is slightly dodgy practice and produces warnings on my 64-bit machine, but is easily fixed by passing a pointer to a heap-allocated copy of the integer!)

Ugarit: initial beta

I'm pleased to announce the release of the first beta release of Ugarit, a backup/archival system based around content-addressed storage, written in Chicken Scheme.

This initial release supports archives stored in the filesystem, including on remote servers via NFS and other such protocols. Future versions plan support for storage of archives in S3 or on remote hosts via SFTP/SSH, and a pluggable storage backend system allows for many other forms of archive to be created.

Ugarit provides efficient snapshots and restores, without requiring intelligence of its storage. Anything that works roughly like a filesystem can be used as a Ugarit backend, and it is designed to minimise the size of data sent to the archive, in order to reduce transfer and storage costs on services like S3, and snapshot time.

I've tested it on various test filesystems, ranging from a contrived example with all sorts of funny things like FIFOs and devices in, up to 500MB of /usr/pkgsrc and >2GB of /usr. I'm going to see if I can borrow some big hardware at work to test it on some many-hundreds-of-gigabytes filesystems as well, to see if I can find any scaling issues, and I'm currently putting it into place as my personal backup system. However, this is still beta software, so please be careful and test your backups!

For details and installation instructions, see the Ugarit project page.

Future developments planned include:

• File modification time caching, reducing the time taken to identify changed files to snapshot.
• Encrypted archives.
• Replicated archives, supporting both fault-tolerance over multiple archives and local caching, where extractions are serviced from a local archive, but if the local archive is lost (even just partially), a remote archive can provide the missing data.
• More storage backends
• FUSE support, so you can browse your archive as a read-only filesystem

Some brief proposals for how to make the OpenPGP encryption standard more widely used

The OpenPGP standard isn't perfect, but it's good enough - and it's sufficiently widespread (in geek circles) already that it might be possible to push it into widespread usage.

Here are some ideas on things we could do to push it beyond the realm of geeks emailling each other to become a more pervasive security infrastructure.

Read more »

Building a Web of Trust is fun

Well, I've now done two ORG keysignings: the original one at Imperial College Union and another one at OpenTech.

Both worked out quite well - they've both been informal ones, where pre-registration of your key on the Wiki page is optional; at an appointed time and place, a bunch of strangers meet up and look at each other's legal proofs of ID and details of their digital identity, then go home and issue cryptographically signed statements that they think the legal ID and the digital ID match. Which, as I have mentioned before, is just one way of building trust webs. Anonymous check-my-ID keysignings copy a real-world statement of identity into a digital identity framework, which is scaleable since total strangers can sign each other's keys. Verifying digital identities based on pseudonyms involves linking a reputation to a digital identity, which is a little slower to scale since it takes time to check a reputation (generally, you can only do it for people you have formed a relationship with, even if it's just reading their blog), but in many ways more valuable.

So, I'd like to keep organising key signings, until people stop turning up!

My hunch is that, after a few parties, everyone in the region who wants to attend one will have, and will then be thoroughly rooted in the local web of trust. So attendance will drop off, as the only people who keep coming will be people who want to come and meet up and chat anyway (even if they've already swapped signatures with everyone else present) - and new people who create an identity and want to link it into the Web (and perhaps meet other local cyphergeeks).

London's certainly big enough to provide a suitable population, I think, if I organise bi-weekly or monthly regular signings at a nominated public location; I'm in London at the beginning of every other week for the foreseeable future, so I'm going to propose that I establish a routine!

But I'm also keen to get more involved in the Bristol and Glocuester geek scenes, too, what with it actually being near where I live. Perhaps just monthly. I'll see what interest I can raise...