Andrews & Arnold and PGP
A&A have always supported use of PGP/GPG and customers can (and do) send encrypted emails. We sign emails we send from the accounts system. Staff have GPG installed and have keys signed by the company key which I control. Sadly few customers use this, and so staff are perhaps less on-the-ball than they could be, but we are working on improving that too.
I think we can do more though. What I am trying to work on now is a way for customers to tell us that they want encrypted emails from us. We would use the https access to the accounts system to manage this which has some degree of traceable trust but it would mean uploading a public key to us (or perhaps referencing a key server). We'd need to make this simple, and perhaps even have an API, as some people may wish to issue new keys every day and delete old ones in order to thwart the RIPA requirement to hand over keys if you have them.
The challenge I then face is how we manage that preference as we have various systems that send emails as well as staff that could send emails directly. We would need some way for every system to know to use encryption and which key to use. Now, for staff sending emails we can almost certainly integrate this in with the ticketing system as a "direct" email is relatively rare, but that is not ideal. I suspect that it will take some time to ensure every system and every script that sends emails understands this, unless we run an intermediate outgoing mail server for it.
I am interested in the best practice way of managing this though. I am sure this cannot be an uncommon problem. Should we run a key server? Should we put keys in shared SQL databases? We are only talking public keys so not a huge security issue. Maybe some combination of the two. Any advice welcome.
FireBrick and IPsec
The FireBrick products already support IPsec, and any day now we expect to have the EAP elements that will allow things like iPhones and Androids to remote connect to a FireBrick and allow VPN access to your office, etc. Once that is done we will progress on to TL, https and ssh, obviously.
One of the key features of the FireBrick, and one of the main reasons it has taken so long to get these features in place, is that this is written from scratch.*
What this means is that we know there are no back doors in the code. Almost any small router that does https or even IPsec has bought in the code or used open source. It is large and complex and may even be a "binary blob" so it is hard to be sure that it has no back doors. Open source is generally safer as it can be reviewed, and people do, but how do you know the code you downloaded is that reviewed and correct code exactly unless you check it yourself? Well, in our case, we know because it has been written in-house. There is not even a third party operating system below it, we wrote that too. We even use a processor with no hidden boot ROM code and no binary blob device drivers for peripherals (both of which are quite common these days in some types of processor). We even make the FireBricks in the UK and load the code in to them ourselves. All code is signed by us, and our boot loader checks the signature to ensure no rogue code can be issued with back doors added.**
I think it is incredibly rare for any manufacturer to be able to say that. And if some UK law is passed that could compel us to add back doors we would stop.***
Even so, suggestions welcome.
* Some of you may have heard the long standing truth that one should never try and design an encryption system yourself or behind closed doors. They have to be one subject to wide scrutiny to be any good. This is true, but is not the same an implementing these algorithms, which can be done behind closed doors, and the standards provide lots of good test data for doing just that.
** Technically, with physical access and a JTAG interface someone could load other code, but that is highly unlikely and would require that physical access to the FireBrick.
*** In practice we would probably set up in a saner country and make and ship from there, or possibly just emigrate there as the UK really would have lost the plot by then.
On the other hand, given the extreme difficulty in implementing a cryptographic algorithm correctly and securely, without revealing data about the plaintext or private key through side-channels like timing attacks, I am not filled with confidence by A&A (or anyone) rolling their own closed-source implementation.
ReplyDeleteThe code is very carefully written to follow the RFCs and recommendations, obviously.
DeleteOf course, but the problem is you can have an implementation that conforms precisely with the RFCs and passes every test suite imaginable, yet is as secure as a wet paper bag.
DeleteThe implementation of the mathematical algorithms is as critical and as complex as their design, if not more so.
For one example (of many): http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
Im glad to see AA considering automated PGP signing for system emails. I think this will be of particular use for SIP call recordings. If im getting call recordings emailed to a gmail inbox, id have to assume both GCHQ and NSA are storing them (along with pretty much everything else) as a matter of course. Rather than a court of law issuing a specific and individual warrant to a telco to tap a line or go and retrieve call records. I hope to see this implemented!
ReplyDeleteNow, what ive read here about crypto systems implementation goes against accepted InfoSec wisdom, i believe?
The main way applied crypto is broken in reality is via implementation error, side-channel attacks and such, as far as i know, not mathematical breaks. So to say "Its ok we didnt design the maths, we just put it to use" seems a small comfort. Its not that i think youre incompetent, its that making real actual secure applied cypto systems is HARD. As hell. Not really very many people in the world are qualified to do it, comparatively. Thats why OSS packages like NaCl exist, which provide a single highly audited ready made *implementation* of crypto which people can just plug into their projects.
It is commendable that AA is thinking about this stuff so much, for sure no other ISP would bother, but the real only golden rules of applied crypto afaik are "dont design your own crypto" and "open source or bust". The first is self-explanatory, the second is considered essential for any serious crypto application and would be highly desirable, if you were willing to commit to that?
If not, as a compromise, perhaps an external audit of said bespoke code by a real, proper serious InfoSec auditing firm, in the style of the truecrypt auditing project?
Finally do you have any comment on the recent Snowden dox which showed GCHQ can successfully break most of the popular VPN protocols to a large extent, such as IPSec and PPTP (I think the claimed figure was access to 80% of VPN sessions in the wild using these protocols)? OpenVPN seemed to be left out of these claims iirc.
If ive committed a huge logical fallacy with typing down these thoughts forgive me. Im not an expert on this stuff by any means. Cheers.
I'll discuss in more detail with Cliff to see what response we can say to that, but I would say that he is one of the few people that would be up to this sort of task, and not even something I have taken on myself for the reasons you say. This is also why we have been working on this for about two years now. This is serious development work.
DeleteHow much could you release the source code? I don't mean as Open Source, more just open source.
ReplyDeleteIf you're implementing RFCs etc then there is no danger of you providing the source something that would have given you a competitive advantage. You are just implementing the RFCs...
This is a serious possibility and something we will consider. In general the product as a whole does not have source code released, but the crypto stuff may be an option for comment/review.
DeleteLet me go one step further (playing devils advocate if you will)
DeleteYou say there are no back doors in the code, but how do we
check? How do you know one of your developers isn't secretly
working for GCHQ?
That's one of the advantages of open source and IIRC there are
projects around (or at least in the works) that allow you to verify the
source code against what your running.
There are two of us and we see each other's commits.
DeleteRevK, would you use this product if it were manufactured by someone else? That is, closed source with no visibility but repeated assurances from the authors that it's secure?
DeleteIt is all down to trust. If you have the means to audit code yourself, then using open source platforms are way better, once you have audited them. I hope I engender some trust, more so than David Cameron perhaps.
DeleteWhy not open source all of firebrick, then?
DeleteYou're asking Firebrick users to unconditionally trust you with no way to verify your assertions themselves. Is there any person or organisation you'd voluntarily trust to that same degree yourself?
Well, open source, as in published, not "take it and build yourself", is something that we are considering.
DeleteIf people can't build it themselves and push it to the device, though, you're still asking them to accept your assertion that the code on the device is the same as the code you published, with no way to prove that's the case.
DeleteQuite, but pushing it to a device would not work as we have signed code, for security reasons. If the source was open then there could be rogue versions of FB code floating around with back doors and so on.
DeleteFair enough, and that's a reasonable thing to want to defend against.
DeleteIf you publish your code and toolchain, however, and allow people to push signed binaries to the device, a determined user could review the code, compile it and verify it matches the signed binary, then push the signed one to the device to verify it's what's really running.
...as long as they trust your bootloader, but at least you're reducing the surface area of things people need to unconditionally trust.
We'll look in to it anyway, but is it tricky, as you can appreciate. At least I am stating the policy view we take on this, which is more than many vendors would. In practice you almost certainly need to use a completely open source solution rather than a FireBrick to be totally sure.
DeleteI do most of my email on an iPad. I'm sure I'm not the only person in the world doing email on a portable device. Is it possible to use email encryption with them?
ReplyDeleteYes. I use iPGmail on my iPhone, and I don't see why it wouldn't work on iPad too. However, it is a cludge: you need to copy text to/from your email client, to allow iPGmail to do the en/decryption
DeleteThe iPhone/iPad does use TLS to IMAP/SMTP so that can help. But it is not end to end. Would be nice for apply to embrace GPG properly in apple mail on all devices.
DeleteI already use TLS for IMAP/SMTP on my iPad, but that isn't end to end so really isn't what we're talking about here.
DeleteOwen Smith - no problem on Android devices using plugins for email clients. A quick glimpse round the iTunes store shows similar apps available.
ReplyDeleteWhether you trust the device enough to have private keys on there is another question....
Apple have already said they're sick of all the requests from governments to decrypt people's iPads and other data, so they're not going to hold the keys any more at Apple so they can't be forced to decrypt things (there's no law that can force Apple to keep keys at present).
DeleteYour system is surely only as good as the quality of the urandom function you use. Do we know how good it is, i.e. immune from interference from the men in black?
ReplyDeleteWell, I would use a TRNG but it seems ill at the moment, however, back to basics, use a pair of dice, and no computer is involved. I do say this in the blog!
DeleteHmm, RTFB indeed
ReplyDeleteAs one of your customers, I sent an e-mail to your support team with a GPG encrypted e-mail. I never received a response and after following up was told that it was received but still no response. Eventually, I ended up sending the same e-mail in plain text as it appears you do in fact have some issues with dealing with these when they come through.
ReplyDeleteThat should not happen - do you have the ticket number they got back - I'll work out what went wrong.
DeleteThanks. The original request was raised as 'Quota'. I then sent a follow-up questioning whether it was received, this was ticket 'H3143F' and another ticket 'DE14B7' was also opened regarding this. Please let me know if you need any more information!
DeleteI will look
DeleteI don't see a "Quota" email - did you not get a ticket number reply. If not, then we did not get the email somehow.
DeleteThanks for looking. Looking back at my e-mail, I don't see a reply to the initial e-mail, although in one of the tickets I quoted above your support representative did say that they have received it and another said, "sorry there is not an automated way at the moment to deal with encrypted email to us." So naturally assumed I wouldn't have received an automated response. He did seem to think he had seen the encrypted message though. /me confused!
Delete