Work Ideas and Projects

This page is a place for me to post my notes, ideas and any informations about projects that I'm working on. Most of the things here will never be developed or go anywhere, but it's a chance for me to write some of them down and potentially get feedback. Unfortunately thanks to my hosting, I don't have access to anything more exciting than standard HTML, so comments please go to my email address:

Note that I get ludicrous amounts of spam, so it's possible I'll end up filtering you out. Sorry!

• TPM Endorsement Keys. Should they be available to the end user?
• What Makes A Good Research Paper?
• The Slow Demise Of Email
• Personal Information Management On the Web

TPM Endorsement Keys. Should they be available to the end user?

Trusted Computing gets a lot of bad press. Both Bruce Schneier and Ross Anderson have declared their suspicions as to the true motives of the industrial consortium behind it: the Trusted Computing Group. Many people cite potential privacy conerns as a good reason to steer clear. And would you blame them? After all, a Trusted Platform Module is effectively a little black box inside *your* computer which you don't fully control. It could be working against you, the horror! This post is not really debating the rights or wrong of it, but it does seem slightly paranoid. After all, the vast majority of people run Windows, which is a much larger black box which you also have little control over. You can turn off a TPM and you can run Linux. Or you can turn it on, use the features, and have to live with not controlling the inner workings. The TPM is just a more rigorous bit of protection, but I don't agree that it really gives you any less control over your computer. Now lets get back on topic.

I would argue that many of the privacy fears would be done away with should the TPM's Endorsement Key be made available to the user. This would have a number of effects, assuming we don't trust the user:

• Remote attestation becomes useless and untrustworthy. AIKs are meaningless.
• The TPM's key hierarchy is compromised, which could well result in encryption keys for data storage and signing becoming available to the user. I don't have my TC books handy right now, but this could potentially destroy any sealing or binding of files based on Platform Configuration Registers (PCR). This means that locking files to certain software identities would not work.
• Assuming the key is available to the user, it is also available to the user's software. All software now gets to pretend to be a TPM.

This effectively makes a TPM worthless, right? Well, perhaps not. Let's take apart a few fundamental assumptions here. Firstly, is the user untrustworthy? Much of the TCG's press implies it is actually aiming at protecting the user against malicious software. If the user has a copy of the key, but never gives it to software, surely the same benefits can be reaped? Secondly, is the owner of the machine also the user? In a business context (again, the main aim of the TCG) the owner is the company. They might want to own the keys, and might not trust their employees. After all, insider threats are a significant risk to a business.

My somewhat naive suggestion, therefore, is that when registering a TPM for the first time, perhaps with the manufacturer, you get two options. Blissful ignorance, where keys are kept secret, or mutual trust, where you get a paper copy of your private EK. Written on this piece of paper (in warm, friendly letters) are the words 'CONFIDENTIAL! Do not share or enter in to computer under any circumstances'. The manufacturer's certificate (used to show a TPM is valid) will have a corresponding entry stating whether the user has their key or not.

What does this achieve? A malicious user can now impersonate their TPM. A nice, friendly user can be sure that should they find out the TPM is being used for nefarious reasons, they always have the upper hand. Other people who want to rely on your TPM to fulfil some security function can make their own decision whether or not to trust you, based on your manufacturer-issued certificate. If the relying party is primarily concerned about human factors, they can ban TPMs with a revealed EK certificate.

The key point here, though, is that the TPM can be used to protect the owner of the machine in both scenarios. Assuming the EK is never entered into the software, no malicious piece of code can impersonate the TPM and bypass any security measures that it implements. Neat.

Obviously, this relys on users being sensible, a secure way of issuing paper EKs, and other things. This is probably non-trivial. But isn't it a nice idea anyway?

What Makes A Good Research Paper?

I've written a total of one paper in my research career, and that was rejected. However, I've been reading on and off for the last 7 months, and I'm trying to build up a coherent picture of what makes a 'good' paper. This is an important thing to understand, for the sake of my own work and for critically analysing other peoples'. I am quite dissapointed as to the quality of some papers that I read. They seem to lack proper results, are too speculative, or fail to provide meaningful analysis. I have been guilty of this too, which is why my own rejection was not that surprising.

On a related note, I'm also frustrated by the lack of 'failure reports' in the literature. Surely for every bit of successful research there are several bits that went horribly wrong? Why are these not published, or at least made available? There would be a great benefit to sharing this information and it would lend credibility to research that actually works. Another Oxford D.Phil student, Joe Loughry, is currently putting together a report on a company's failed attempt to get security certification. This is an excellent idea, and will no doubt have many useful lessons for companies, certification agencies and the field of security accreditation itself. I really hope other people will follow this example. I have also heard from a number of young researchers (names and institutions omited!) that quite a lot of published results in biology (and related fields) are extremely dodgy. Experiments that are fudged, or not repeatable. This is a serious problem, and scientists as a whole should be encouraging papers which expose bad research.

Anyway, back on topic. Here are my personal guidelines, which aim to be neither complete or accurate, but are my principles at the moment. I should add that these only really apply to Computer Science, and are not particularly in order. There is a great deal of redundancy and duplication.

• A good introduction, setting the scene. What seems like a ridiculous amount of background, although that's mainly because it's all obvious to the writer.
• A good problem definition. Why is it difficult, why is it interesting and what are the potential benefits to solving it?
• A description of the novel approach you will be taking. The key theory. An explanation of why you are taking this direction. What you hope to demonstrate in this paper.
• A comprehensive summary of existing work. Identifying in each case why this work is different, in terms of the solution presented or the approach taken. Light criticism, benchmarks or flaws work well here to justify your research.
• Depending on the type of paper:
  • A case study or field research, which demonstrates some new interesting fact. This should include observations, deep analysis and tables of data.
  • An implemented system or proof-of-concept application to try and demonstrate the new approach you are pioneering. Lots of details and any interesting issues that became apparent during the design or creation.
  • Proofs and theorems
• More experiments, counter-examples or tests to prove your assertion. For example, if you are demonstrating a new security system, you could show how an existing ttack would have been mitigated. If you tried alternative methods of solving the problem, and failed, it's worth mentioning them and why.
• A summary of the results, as well as any limitations to your methodology/proofs/studies. Any assumptions you have made or exceptions you have noticed.
• Potential improvements, problems with the current work and future developments. A guestimate as where the research might lead us in the future, or what the potential impact is. Any advice that might come out from your work. E.g. 'developers should test more'.
• Conclusion summing up the problem, your new approach, the result of your work, and what the potential is.

The best bit of advice I've seen, although I haven't look very far, came from here:

An ideal submission should have a reviewer intrigued within the first 5 minutes of reading, excited within 15 minutes and satisfied within 45 minutes.

Comments and criticism welcome.

The Slow Demise Of Email

I know I'm not the first person to contemplate the potential demise of email as the dominant communication medium. After all, there are lots of equally nerdy people out there, many with more insight and offering genuine enlightenment. However, I'm going to jot down a few of my thoughts on the matter, just so that one day in the future I can say 'I told you so' or possibly 'look how stupid I was'.

So, email's already dead for keeping in touch with people. We've got social networks for that: Facebook, MySpace, Bebo and the others. Professionally, the mighty business card still holds its own, although more often with a URL to a LinkedIn profile page. Why has this happened? It's due to the lack of authentication at email endpoints, coupled with the attraction of social networks and their subsequent global uptake. Everyone's on a social network now, so that's the easiest way to contact someone. People change email address all the time, and it's difficult to know which one to use. So we look on the profile page, and it's got this super-convenient 'send message' button, and the original intention of sending an email is long forgotten. Profile pages add a level of authentication that people have been attempting to introduce in email for a long time. Social networks are a useful level of indirection, like almost all good ideas in software engineering.

There are associated costs. We need web browsers rather than email clients, which implies a constant network connection. But we're easily at the point where this doesn't matter, even for most small and mobile of devices. There's also the privacy trade-off. Web-based messaging tends to be more public, you can see when someone was last online, and often read other people's messages. The network's administrator can spy one anyone they like, and a security breach affects all users. It's also not a trivial task creating a new social network profile. OK it is, but informing friends is a laborious process, and the easiest way is to use the old social networking profile, and this somewhat defeats the point. Removing yourself from a network is also tricky, although some sites have now grudgingly let you do it. Indeed, the UK government's recent spectacularly incompetent idea (register the email addresses of sex offenders to stop them registering with social networks) is mind-numbingly stupid. We can't stop new email addresses being registered. However, if they *did* sign up to networks, we could do a much better job of monitoring them. It would be much easier to spot if they created new internet personas, thanks to friend lists and photos. It's far from infallable, but is leagues ahead of tracking email addresses. However, these privacy concerns seem to be less important now. Our own sense of online privacy has been dulled sufficiently (Bruce Schneier's post about the Declaration of Independence of Cyberspace is relevant here) over the years, and we appreciate the benefits of authenticated communication over the risks.

We definitely appreciate the reduction in spam. As someone who gets several hundred junk messages to certain accounts every day, it is a wonderful experience using facebook's inbox. Don't expect this to continue forever, but it definitely seems to be working at the moment. After all, spammers can't send messages to so many people at once, and can be spotted and eliminated far more effectively (if not entirely). Email's main weakness can again be traced to it's simple original purpose. Nobody anticipated the amount of abuse that email system would be put through, it was designed to make it really easy to communicate with anyone with a valid address. Spam has also destroyed the reliability of email. Poorly configured filters (or even good ones) will incorrectly label messages as spam and discard them. And if I can't rely on the message getting through, I'll resort to another medium.

In fact, the only other place I use email is for notifications about facebook messages. And surely that's better solved by RSS or Atom feeds? These can also be thought of as equivalent to imap-based email systems, except that they are white-listed. You have to select which feeds you're going to read, and don't accept anyone publishing to them. Again, it's the implicit authorization that makes RSS more useful than email in these situations.

There are situations where email is still the king. For people who's addresses I do know, mostly within the university, it's incredibly useful. Thunderbird lets me archive and search messages in a nicer way than facebook (for the time being). It also beats letters when sending casual messages, such as to family members. Thanks to higher limits on attachment sizes, it's still a good way of sending photos. But don't expect that to continue - social networks already have photo sharing sewn up. It has effectively eliminated sending paper memos and faxes (although fax refuses to die completed). Email is also often the lowest common denominator, letting people on different networks communicate. However, none of the points I've mentioned above are provided uniquely by email and are not immune to the advances of social networking and other tools. The situation will change, and I expect email to be used less and less.

So, what of the future? I've perhaps over-stated my point. I don't think email is dying, I think its just finding its niche. Within organisations, expect email to stick around for a long time. The technology is established, auditing is possible (an important factor for regulated industries) and it solves almost all the problems. Elsewhere, however, I think we're already seeing a lower signal to noise ratio. I receive fewer valid emails and more spam. This makes me (and everyone else) use alternative mediums, which means we in turn don't send emails, exacerbating the situation. I also think that we will lose a little more online privacy, and email will be slowly entangled with our profiles, to the extent that we must have one if we want to receive messages. Authenticated cross-network communication will become possible, and automated. Identity theft will become more important too, and there will be surprisingly significant consequences to losing access to your profile page. Email will keep trundling along for a long time now, but don't expect us all to use it.

Chuck me an email if you (dis)agree :)

Personal Information Management On the Web

UPDATE: It turns out that OpenID might do some of what I'm talking about here. I need to investigate it a bit more first, though

I am a registered user of more websites than I can count. I've given some personal information to all of them, at the very least a valid email address, but often my home address and bank account details. The same will be true of anyone who shops online or is part of a social network. I do have concerns, however, that this information doesn't get revealed to anyone else. I've been spammed by companies before: a florist called Seranata Flowers seems to have either sold my details or been hacked, as I now receive emails (to an account I only gave them) offering services (and medication) entirely unrelated to well-arranged shrubbery.

Furthermore, when I change my address, there's the really annoying job of updating these sites, each of which has a different interface. In fact, I tend not to bother, which leaves a lot of out-of-date information floating around. This is not a great situation for the company to be in, or for me, as the chances of being wrongly charged or missing out on exciting promitions (glee!) are quite high. More importantly to me, If I lose trust in a company, or wish to leave a social network, the process is neither easy nor guaranteed. I have no way to revoke their access to my details. I have essentially lost all rights and controls on my data.

So let's build some common interfaces. A website that really wants to offer some transparency to its users could offer a personal information management web service. This would consist of a set of methods which would let the user update details, remove their account and (importantly) get a history of how their details have been used recently. My vision of it all would be to have the following information log easily at hand:

19/10/07 : Account Creation. Fields altered: Name, Email, Postal Address, Bank Details 19/10/07 : Order Created. Order fields: Product ID, Shipping Date, Total Cost 21/10/07 : Account Accessed Through method: "create_invoice". Fields requested: Bank Details, Name, Postal Address. ... 19/11/07 : Account Accessed Through method: "send_newsletter". Fields requested: Name, Email 19/12/07 : Account Accessed Through method: "send_newsletter". Fields requested: Name, Email ... 07/02/08 : Account Accessed Through method: "anon_stats". Fields requested: Postal Address

Your favourite web browser would be able to provide a more intuitive display of such a log. RSS feeds could be offered, which would let you know on a daily basis who was viewing your information, or processing it. Wouldn't that be interesting? It would also let you 'collect' all the remote services which you had kept information at, so that when it came to update your details, the process could be fully automated.

So far I don't think this is anything revolutionary, and also nothing that's much more trustworthy than the current system. After all, couldn't the company just lie? Which is where Trusted Computing might come in handy. My research is in Trustwothy Web Services, which tries to use Trusted Computing to enhance our confidence that a remote service will do what we think it does. If the personal information management service were a standard piece of code, we could use the Remote Attestation functionality of TC to make sure that it was not being circumvented by the company or an attacker. We would also know the available methods the company had for accessing our data, and we could be sure that logging was happening correctly. It's not quite as simple as that, but there are definite possibilities. See the unpublished report here for some more information.

Of course, we still can't really expect 100 percent protection. There are plenty of low-tech ways to get around this. For example, every request for invoice information could be piped into another account. But it would improve our confidence, increase record accuracy and help with companies that mean well, but lack the technical know-how to provide reasonable data security. It would also help any business that is trying to stick to the Data Protection Act, although this idea goes well beyond any legal requirements. Having common interfaces would also open up collaboration possibilities, so that a company using Amazon market place could use the data server that Amazon uses. I suspect this already happens, but profess ignorance to exactly how. A few other disadvantages are:

• All existing e-commerce firms have their own databases and systems. This would require serious amounts of modification, with little financial benefit.
• Common interfaces might make for common attacks, which (if they found the right bugs) could lead to mass loss of data. I can't believe this would be any worse than our current situation, but I haven't thought about it for long enough to be sure.
• Companies may be reluctant to expose how they access our personal records. But then that's sort-of the point.
• Relies on a trustworthy web service. This isn't a trivial task, by any means
• Most people just don't care

Conclusion: Wouldn't it be nice if we could see how our data was being used?