At the moment, at A&A, we provide Firebricks to customers in various circumstances, including as part of our high availability multiple line Office::1 product.
Usually, and with the customer's knowledge and consent, we will include a login (suitably locked down and secure) for us to access the FireBrick. This means that we can address tech support issues, and make config changes if requested and so on.
This works because our customers can, and do, trust us.
Of course, even where such access is via IPSec tunnels, it still involves trusting us!
The problem is not that we are untrustworthy, but the law, if the Draft Investigatory Powers Bill passes as it is now, would legally compel us to be untrustworthy as it forces us to co-operate with "equipment interference" and "removal of protection on communication" in some circumstances.
If it passes it is simply the case that our customers cannot trust us any more, as that trust will have been officially removed by the law of the land.
So, we are considering what we should do, before any such law comes in to force.
One obvious measure is to not have a login in to the FireBrick. However, the FireBrick does have a trick up its sleeve here - in that we can put our login on a profile and have that controlled by another login that the customer knows. That way they can decide to turn on or off our access as and when they need.
But we may have to go further and ensure that the signing of FireBrick code for automatic updates is managed outside A&A. The issue is that whilst A&A do most of the FireBrick R&D, A&A is also a communications provider. FireBrick is not, and hopefully is outside the scope of this legislation. So A&A might be compelled to add a back door to FireBrick code. If we make the signing authority for code updates exist outside A&A, in FireBrick Ltd only, then we cannot be compelled to issue code with holes in it just to allow equipment interference or removal of protection. What I don't know yet is whether that can be done simply by use of separate hats - i.e. can I be director of A&A and director of FireBrick, but only have authority to sign code in that second role and not the first. May have to take legal advice on that. If not, we will have to have a FireBrick member of staff and one that is not part of any telco that signs the code after reviewing changes - which is a nuisance.
Why do we care - surely this is all about targeted surveillance? Well maybe it is, but the wording of the bill allows bulk equipment interference, and a general intercept capability, neither of which is targeted.
But there is also the principle here - can our customers trust us? I would like them to be able to trust us. Should trusting your ISP be like trusting your lawyer or your MP? I really hate the idea that any law can officially undermine trust customers have in us - so yes, of course - we'll take steps to ensure that trust is valid and continues.
This is massively about perception. Even if we have no such orders - which we really doubt we would ever have - if people believe we may have, and lose trust, they may disable code updates. That would be bad for the product and ultimately their security as we would not be able to fix any weaknesses in their FireBrick that we discover. Ultimately, this really is all about trust!
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
I think there's such a thing as n-of-m multiple party digital signature schemes. Maybe that could help - having people who shouldn't necessarily be trusted to sign code on their own, but who add redundancy to the system. The open source community seems to be taking a lot of interest in reproducible builds, too, so you can compare hashes with other people. Done right, that could ensure that malware can be detected even if signed.
ReplyDelete