Commenting Policy for This Blog

Over the past few months, I have been watching my blog comments decline in civility. I blame it in part on the contentious US election and its aftermath. It's also a consequence of not requiring visitors to register in order to post comments, and of our tolerance for impassioned conversation. Whatever the causes, I'm tired of it. Partisan nastiness is driving away visitors who might otherwise have valuable insights to offer.

I have been engaging in more active comment moderation. What that means is that I have been quicker to delete posts that are rude, insulting, or off-topic. This is my blog. I consider the comments section as analogous to a gathering at my home. It's not a town square. Everyone is expected to be polite and respectful, and if you're an unpleasant guest, I'm going to ask you to leave. Your freedom of speech does not compel me to publish your words.

I like people who disagree with me. I like debate. I even like arguments. But I expect everyone to behave as if they've been invited into my home.

I realize that I sometimes express opinions on political matters; I find they are relevant to security at all levels. On those posts, I welcome on-topic comments regarding those opinions. I don't welcome people pissing and moaning about the fact that I've expressed my opinion on something other than security technology. As I said, it's my blog.

So, please... Assume good faith. Be polite. Minimize profanity. Argue facts, not personalities. Stay on topic. If you want a model to emulate, look at Clive Robinson's posts.

Schneier on Security is not a professional operation. There's no advertising, so no revenue to hire staff. My part-time moderator -- paid out of my own pocket -- and I do what we can when we can. If you see a comment that's spam, or off-topic, or an ad hominem attack, flag it and be patient. Don't reply or engage; we'll get to it. And we won't always post an explanation when we delete something.

My own stance on privacy and anonymity means that I'm not going to require commenters to register a name or e-mail address, so that isn't an option. And I really don't want to disable comments.

I dislike having to deal with this problem. I've been proud and happy to see how interesting and useful the comments section has been all these years. I've watched many blogs and discussion groups descend into toxicity as a result of trolls and drive-by ideologues derailing the conversations of regular posters. I'm not going to let that happen here.

New Paper on Encryption Workarounds

I have written a paper with Orin Kerr on encryption workarounds. Our goal wasn't to make any policy recommendations. (That was a good thing, since we probably don't agree on any.) Our goal was to present a taxonomy of different workarounds, and discuss their technical and legal characteristics and complications.

Abstract: The widespread use of encryption has triggered a new step in many criminal investigations: the encryption workaround. We define an encryption workaround as any lawful government effort to reveal an unencrypted version of a target's data that has been concealed by encryption. This essay provides an overview of encryption workarounds. It begins with a taxonomy of the different ways investigators might try to bypass encryption schemes. We classify six kinds of workarounds: find the key, guess the key, compel the key, exploit a flaw in the encryption software, access plaintext while the device is in use, and locate another plaintext copy. For each approach, we consider the practical, technological, and legal hurdles raised by its use.

The remainder of the essay develops lessons about encryption workarounds and the broader public debate about encryption in criminal investigations. First, encryption workarounds are inherently probabilistic. None work every time, and none can be categorically ruled out every time. Second, the different resources required for different workarounds will have significant distributional effects on law enforcement. Some techniques are inexpensive and can be used often by many law enforcement agencies; some are sophisticated or expensive and likely to be used rarely and only by a few. Third, the scope of legal authority to compel third-party assistance will be a continuing challenge. And fourth, the law governing encryption workarounds remains uncertain and underdeveloped. Whether encryption will be a game-changer or a speed bump depends on both technological change and the resolution of important legal questions that currently remain unanswered.

The paper is finished, but we'll be revising it once more before final publication. Comments are appreciated.

WikiLeaks Not Disclosing CIA-Hoarded Vulnerabilities to Companies

WikiLeaks has started publishing a large collection of classified CIA documents, including information on several -- possibly many -- unpublished (i.e., zero-day) vulnerabilities in computing equipment used by Americans. Despite assurances that the US government prioritizes defense over offense, it seems that the CIA was hoarding vulnerabilities. (It's not just the CIA; last year we learned that the NSA is, too.)

Publishing those vulnerabilities into the public means that they'll get fixed, but it also means that they'll be used by criminals and other governments in the time period between when they're published and when they're patched. WikiLeaks has said that it's going to do the right thing and privately disclose those vulnerabilities to the companies first.

This process seems to be hitting some snags:

This week, Assange sent an email to Apple, Google, Microsoft and all the companies mentioned in the documents. But instead of reporting the bugs or exploits found in the leaked CIA documents it has in its possession, WikiLeaks made demands, according to multiple sources familiar with the matter who spoke on condition of anonymity.

WikiLeaks included a document in the email, requesting the companies to sign off on a series of conditions before being able to receive the actual technical details to deploy patches, according to sources. It's unclear what the conditions are, but a source mentioned a 90-day disclosure deadline, which would compel companies to commit to issuing a patch within three months.

I'm okay with a 90-day window; that seems reasonable. But I have no idea what the other conditions are, and how onerous they are.

Honestly, at this point the CIA should do the right thing and disclose all the vulnerabilities to the companies. They're burned as CIA attack tools. I have every confidence that Russia, China, and several other countries can hack WikiLeaks and get their hands on a copy. By now, their primary value is for defense. The CIA should bypass WikiLeaks and get the vulnerabilities fixed as soon as possible.

Security Vulnerabilities in Mobile MAC Randomization

Interesting research: "A Study of MAC Address Randomization in Mobile Devices When it Fails":

Abstract: Media Access Control (MAC) address randomization is a privacy technique whereby mobile devices rotate through random hardware addresses in order to prevent observers from singling out their traffic or physical location from other nearby devices. Adoption of this technology, however, has been sporadic and varied across device manufacturers. In this paper, we present the first wide-scale study of MAC address randomization in the wild, including a detailed breakdown of different randomization techniques by operating system, manufacturer, and model of device. We then identify multiple flaws in these implementations which can be exploited to defeat randomization as performed by existing devices. First, we show that devices commonly make improper use of randomization by sending wireless frames with the true, global address when they should be using a randomized address. We move on to extend the passive identification techniques of Vanhoef et al. to effectively defeat randomization in 96% of Android phones. Finally, we show a method that can be used to track 100% of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames.

Basically, iOS and Android phones are not very good at randomizing their MAC addresses. And tricks with level-2 control frames can exploit weaknesses in their chipsets.

Slashdot post.