One of the big problems with IoT devices is default passwords – here’s the list coded into the malware that attacked Brian Krebs. But without a default password, you have to make each device unique and then give the randomly-generated password to the user, perhaps by putting it on a sticky label. Again, my IoT vision post suggests a better solution. If the device’s public key and a password are in an RFID tag on it, and you just swipe that over your hub, the hub can find and connect securely to the device over SSL, and then authenticate itself to the device (using the password) as the user’s real hub, with zero configuration on the part of the user. And all of this works without the need for any UI or printed label which needs to be localized. Better usability, better security, better for the internet.
You know that problem where you want to label a coffee pot, but you just don’t have the right label? Technology to the rescue!
Of course, new technology does come with some disadvantages compared to the old, as well as its many advantages:
And pinch-to-zoom on the picture viewer (because that’s what it uses) does mean you can play some slightly mean tricks on people looking for their caffeine fix:
And how do you define what label the tablet displays? Easy:
Seriously, can any reader give me one single advantage this system has over a paper label?
As Brian Krebs is discovering, a large number of internet-connected devices with bad security can really ruin your day. Therefore, a lot of energy is being spent thinking about how to solve the security problems of the Internet of Things. Most of it is focussed on how we can make sure that these devices get regular security updates, and how to align the incentives to achieve that. And it’s difficult, because cheap IoT devices are cheap, and manufacturers make more money building the next thing than fixing the previous one.
Perhaps, instead, of trying to make water flow uphill, we should be taking a different approach. How can we design these devices such that they don’t need any security updates for their lifetime?
One option would be to make them perfect first time. Yeah, right.
Another option would be the one from my blog post, An IoT Vision. In that post, I outlined a world where IoT devices’ access to the Internet is always mediated through a hub. This has several advantages, including the ability to inspect all traffic and the ability to write open source drivers to control the hardware. But one additional outworking of this design decision is that the devices are not Internet-addressable, and cannot send packets directly to the Internet on their own account. If that’s so, it’s much harder to compromise them and much harder to do anything evil with them if you do. At least, evil things affecting the rest of the net. And if that’s not sufficient, the hub itself can be patched to forbid patterns of access necessary for attacks.
Can we fix IoT security not by making devices secure, but by hiding them from attacks?
One of my roles at Mozilla is that I’m part of the Root Program team, which manages the list of trusted Certificate Authorities (CAs) in Firefox and Thunderbird. And, because we run our program in an open and transparent manner, other entities often adopt our trusted list.
In that connection, I’ve recently been the lead investigator into the activities of a Certificate Authority (CA) called WoSign, and a connected CA called StartCom, who have been acting in ways contrary to those expected of a trusted CA. The whole experience has been really interesting, but I’ve not seen a good moment to blog about it. Now that a decision has been taken on how to move forward, it seems like a good time.
The story started in late August, when Google notified Mozilla about some issues with how WoSign was conducting its operations, including various forms of what seemed to be certificate misissuance. We wrote up the three most serious of those for public discussion. WoSign issued a response to that document.
Further issues were pointed out in discussion, and via the private investigations of various people. That led to a longer, curated issues list and much more public discussion. WoSign, in turn produced a more comprehensive response document, and a “final statement” later.
One or two of the issues on the list turned out to be not their fault, a few more were minor, but several were major – and their attempts to explain them often only led to more issues, or to a clearer understanding of quite how wrong things had gone. On at least one particular issue, the question of whether they were deliberately back-dating certificates using an obsolete cryptographic algorithm (called “SHA-1”) to get around browser blocks on it, we were pretty sure that WoSign was lying.
Around that time, we privately discovered a couple of certificates which had been mis-issued by the CA StartCom but with WoSign fingerprints all over the “style”. Up to this point, the focus has been on WoSign, and StartCom was only involved because WoSign bought them and didn’t disclose it as they should have done. I started putting together the narrative. The result of those further investigations was a 13-page report which conclusively proved that WoSign had been intentionally back-dating certificates to avoid browser-based restrictions on SHA-1 cert issuance.
If you can write an enthralling page-turner about f**king certificate authorities doing scuzzy nerd sh*t, damn, I couldn't pull that off.
— SwiftOnSecurity (@SwiftOnSecurity) September 28, 2016
The report proposed a course of action including a year’s dis-trust for both CAs. At that point, Qihoo 360 (the Chinese megacorporation which is the parent of WoSign and StartCom) requested a meeting with Mozilla, which was held in Mozilla’s London office, and attended by two representatives of Qihoo, and one each from StartCom and WoSign. At that meeting, WoSign’s CEO admitted to intentionally back-dating SHA-1 certificates, as our investigation had discovered. The representatives of Qihoo 360 wanted to know whether it would be possible to disentangle StartCom from WoSign and then treat it separately. Mozilla representatives gave advice on the route which might most likely achieve this, but said that any plan would be subject to public discussion.
WoSign then produced another updated report which included their admissions, and which outlined a plan to split StartCom out from under WoSign and change the management, which was then repeated by StartCom in their remediation plan. However, based on the public discussion, the Mozilla CA Certificates module owner Kathleen Wilson decided that it was appropriate to mostly treat StartCom and WoSign together, although StartCom has an opportunity for quicker restitution than WoSign.
And that’s where we are now :-) StartCom and WoSign will no longer be trusted in Mozilla’s root store for certs issued after 21st October (although it may take some time to implement that decision).
Six weeks ago, I posted “On Trial”, which explained that I was taking part in a medical trial in Manchester. In the trial, I was trying out some interesting new DNA repair pathway inhibitors which, it was hoped, might have a beneficial effect on my cancer. However, as of ten days ago, my participation has ended. The trial parameters say that participants can continue as long as their cancer shrinks or stays the same. Scans are done every six weeks to determine what change, if any, there has been. As mine had been stable for the five months before starting participation, I was surprised to discover that after six weeks of treatment my liver metastasis had grown by 7%. This level of growth was outside the trial parameters, so they concluded (probably correctly!) the treatment was not helping me and that was that.
The Lord has all of this in his hands, and I am confident of his good purposes for me :-)
CW: heavy open source license geekery ahead.
One unfortunate difficulty with open source licensing is that some lawyers, including the FSF, consider the Apache License 2.0 incompatible with the GPL 2.0, which is to say that you can’t combined Apache 2.0-licensed code with GPL 2.0-licensed code and distribute the result. This is annoying because when choosing a permissive licence, we want people to use the more modern Apache 2.0 over the older BSD or MIT licenses, because it provides some measure of patent protection. And this incompatibility discourages people from doing that.
This was a concern for Mozilla when determining the correct licensing for Rust, and this is why the standard Rust license is a dual license – the choice of Apache 2.0 or MIT. The idea was that Apache 2.0 would be the normal license, but people could choose MIT if they wanted to combine “Rust license” code with GPL 2.0 code.
However, the LLVM project has now had notable open source attorney Heather Meeker come up with an exception to be added to the Apache 2.0 license to enable GPL 2.0 compatibility. This exception meets a number of important criteria for a legal fix for this problem:
- It’s an additional permission, so is unlikely to affect the open source-ness of the license;
- It doesn’t require the organization using it to take a position on the question of whether the two licenses are actually compatible or not;
- It’s specific to the GPL 2.0, thereby constraining its effects to solving the problem.
Here it is:
—- Exceptions to the Apache 2.0 License: —-
In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.
—- end —-
It seems very well written to me; I wish it had been around when we were licensing Rust.
Google have just published the draft spec for a protocol called Roughtime, which allows clients to determine the time to within the nearest 10 seconds or so without the need for an authoritative trusted timeserver. One part of their ecosystem document caught my eye – it’s like a small “chaos monkey” for protocols, where their server intentionally sends out a small subset of responses with various forms of protocol error:
A healthy software ecosystem doesn‘t arise by specifying how software should behave and then assuming that implementations will do the right thing. Rather we plan on having Roughtime servers return invalid, bogus answers to a small fraction of requests. These bogus answers would contain the wrong time, but would also be invalid in another way. For example, one of the signatures might be incorrect, or the tags in the message might be in the wrong order. Client implementations that don’t implement all the necessary checks would find that they get nonsense answers and, hopefully, that will be sufficient to expose bugs before they turn into a Blackhat talk.
The fascinating thing about this is that it’s a complete reversal of the ancient Postel’s Law regarding internet protocols:
Be conservative in what you send, be liberal in what you accept.
This behaviour instead requires implementations to be conservative in what they accept, otherwise they will get garbage data. And it also involves being, if not liberal, then certainly occasionally non-conforming in what they send.
Postel’s law has long been criticised for leading to interoperability issues – see HTML for an example of how accepting anything can be a nightmare, with the WHAT-WG having to come along and spec things much more tightly later. However, but simply reversing the second half to be conservative in what you accept doesn’t work well either – see XHTML/XML and the yellow screen of death for an example of a failure to solve the HTML problem that way. This type of change wouldn’t work in many protocols, but the particular design of this one, where you have to ask a number of different servers for their opinion, makes it possible. It will be interesting to see whether reversing Postel will lead to more interoperable software. Let’s call it “Langley’s Law”:
Be occasionally evil in what you send, and conservative in what you accept.
The email said:
To better protect your United MileagePlus® account, later this week, we’ll no longer allow the use of PINs and implement two-factor authentication.
This is united.com’s idea of two-factor authentication:
It doesn’t count as proper “Something You Have”, if you can bootstrap any new device into “Something You Have” with some more “Something You Know”.
- Project Name: Donald J. Trump for President
- Project Website: https://www.donaldjtrump.com/
- Project Description: Make America great again
- What is the maintenance status of the project? Look at the polls, we are winning!
- Has the project ever been audited before? Its under audit all the time, every year I get audited. Isn’t that unfair? My business friends never get audited.
Ha, ha. But it turns out it might have been a good idea to take the submission more seriously…
As many readers of this blog will know, I have cancer. I’ve had many operations over the last fifteen years, but a few years ago we decided that the spread was now wide enough that further surgery was not very pointful; we should instead wait for particular lesions to start causing problems, and only then treat them. (I have metastases in my lungs, liver, remaining kidney, leg, pleura and other places.)
Historically, chemotherapy hasn’t been an option for me. Broad spectrum chemotherapies work by killing anything growing fast; but my rather unusual cancer doesn’t grow fast (which is why I’ve lived as long as I have so far) and so they would kill me as quickly as they would kill it. And there are no targetted drugs for Adenoid Cystic Carcinoma, the rare salivary gland cancer I have.
However, recently my oncologist referred me to The Christie hospital in Manchester, which is doing some interesting research on cancer genetics. With them, I’m trying a few things, but the most immediate is that yesterday I entered a Phase 1 trial called AToM, which is trialling a couple of drugs in combination which may be able to help me.
The two drugs are an existing drug called olaparib, and a new one known only as AZD0156. Each of these drugs inhibits a different one of the seven or so mechanisms cells use to repair DNA after it’s been damaged. (Olaparib inhibits the PARP pathway; AZD0156 the ATM pathway.) Cells which realise they can’t repair themselves commit “cell suicide” (apoptosis). The theory is that these repair mechanisms are shakier in cancer cells than normal cells, and so cancer cells should be disproportionately affected (and so commit suicide more) if the mechanisms are inhibited.
As this is a Phase 1 trial, the goal is more about making sure the drug doesn’t kill people than about whether it works well, although the doses now being used are in the clinical range, and another patient with my cancer has seen some improvement. The trial document listed all sorts of possible side-effects, but the doctors say other patients are tolerating the combination well. Only experience will tell how it affects me. I’ll be on the drugs as long as I am seeing benefit (defined as “my cancer is not growing”). And, of course, hopefully there will be benefit to people in the future when and if this drug is approved for use.
In practical terms, the first three weeks of the trial are quite intensive in terms of the amount of hospital visits required (and I live 2 hours drive from Manchester), and the following six weeks moderately intensive, so I may be less responsive to email than normal. I also won’t be doing any international travel.
[Update 2016-09-02: the poster of the original info has updated this post, and this post therefore turns out to be mostly untrue. Apologies to Samsung.]
A slow hand clap for Samsung, who have managed to create versions of the S4 Mini phone with model numbers (among others):
- GT-i9195L (big-ell)
- GT-i9195i (small-eye)
- GT-i9195l (small-ell)
And of course, the small-ell variant, as well as being case-confusable with the big-ell variant and visually confusable with the small-eye variant if it’s written with a capital I as, say, here, is in fact an entirely different phone with a different CPU and doesn’t support the same aftermarket firmware images that all of the other variants do.
See this post for the terrible details.
I’ve been campaigning a bit on the EU Referendum. (If you want to know why I think the UK should leave, here are my thoughts.) Here’s the leaflet my wife and I have been stuffing into letterboxes in our spare moments for the past two weeks:
And here’s the leaflet in our area being distributed today by one of the Labour local councillors and the Remain campaign:
Says it all.
Various bits of the TiSA (Trade in Services Agreement, yet another multilateral trade treaty) were leaked recently. On the very first page of General Provisions:
[CH propose; AU/CA/CL/TW/CO/EU/IL/JP/MX/NZ/PE oppose; MU/PK considering:
Without prejudice to the policy objectives and legislation of the Parties in areas such as the protection of intellectual property, the protection of privacy and of the confidentiality of personal and commercial data, the protection of consumers and the protection and promotion of the diversity of cultural expressions (including through public funding and assistance) and fiscal measures.]
So the Swiss said “Hey, wouldn’t it be good if we had a thing at the start that said that this treaty doesn’t stop governments protecting privacy, the confidentiality of data, consumer rights, cultural diversity or other important things like that? Wouldn’t that be neat?”
And Australia, Canada, Chile, Taiwan, Colombia, the EU, Israel, Japan, Mexico, New Zealand and Peru all said “Er, no. We want this agreement to be capable of preventing us from protecting those things, thanks. Where it speaks, it should be more important than the domestic law enacted by your elected representatives.”
Seems like that tells you a lot of what you need to know about the way such treaties are assembled. At least Mauritius and Pakistan are still thinking about it… Sheesh.
Some people say that all Eurovision songs are the same. (And some say all blog posts on this topic are the same…) That’s probably not quite true, but there is perhaps a hint of truth in the suggestion that some themes tend to recur from year to year. Hence, I thought, Eurovision Bingo.
I wrote some code to analyse a directory full of lyrics, normally those from the previous year of the competition, and work out the frequency of occurrence of each word. It will then generate Bingo cards, with sets of words of different levels of commonness. You can then use them to play Bingo while watching this year’s competition (which is on Saturday).
Here’s a sample card from the 2014 lyrics:
Have fun :-)
My ISP, the excellent Mythic Beasts, has started offering a managed DNSSEC service for domains they control – just click one button, and you’ve got DNSSEC on your domain. I’ve just enabled it on gerv.net (which, incidentally, as of a couple of weeks ago, is also available over a secure channel thanks to MB and Let’s Encrypt).
If you have any problems accessing any resources on gerv.net, please let me know by email – gerv at mozilla dot org should be unaffected by any problems.