October 20, 2017

Archives for February 2017

How the Politics of Encryption Affects Government Adoption

I wrote yesterday about reports that people in the White House are using encrypted communication apps more often, and why that might be. Today I want to follow up by talking about how the politics of encryption might affect government agencies’ choices about how to secure their information.  I’ll do this by telling the stories of the CIOs of three hypothetical Federal agencies.

Alice is CIO of Agency A. Her agency’s leader has said in speeches that encryption is a tool of criminals and terrorists, and that encryption is used mostly to hide bad or embarrassing acts. Alice knows that if she adopts encryption for the agency, her boss could face criticism for hypocrisy, for using the very technology that he criticizes. Even if there is evidence that encryption will make Agency A more secure, there is a natural tendency for Alice to look for other places to try to improve security instead.

Bob is CIO of Agency B. His agency’s leader has taken a more balanced view, painting encryption as a tool with broad value for honest people, and which happens to be used by bad people as well. Bob will be in a better position than Alice to adopt encryption if he thinks it will improve his agency’s security. But he might hesitate a bit to do so if Agencies A and B need to work together on other issues, or if the two agency heads are friends–especially if encryption seems more important to the head of Agency A than it does to the head of Bob’s own agency.

Charlie is CIO of Agency C. His agency’s leader hasn’t taken a public position on encryption, but the leader is known to be impulsive, thin-skinned, and resistant to advice from domain experts. Charlie worries that if he starts deploying encryption in his agency, and then the leader impulsively takes a strong position against encryption without consulting his team, the resulting accusations of hypocrisy could anger the leader. That might cost Charlie his job, or seriously undermine the authority he needs to properly manage agency IT. The safe thing for Charlie to do is to avoid deploying encryption–not only to preserve his job but also to protect the rest of the agency’s IT agenda. If Charlie doesn’t change the agency’s practice, then criticism of the practice can be deflected onto the previous leader–and of course we’ll be upgrading to the better practice soon. Here the uncertainty created by the leader’s management style deters Charlie from changing encryption practice.

Let’s recap. Alice, Bob, and Charlie are operating in different environments, but in all three cases, the politics of encryption are deterring them, at least a little, from deploying encryption. Their decision to deploy it or not will depend not only on their best judgment as to whether it will improve the agency’s security, but also on political factors that raise the cost of adopting encryption. And so their agencies may not make enough use of encryption.

This is yet another reason we need a serious and specific discussion about encryption policy.

 

On Encryption Apps in the White House

Politico ran a long story today pointing to an increase in the use of encrypted communication apps by people in DC, government, and the White House specifically.

Poisonous political divisions have spawned an encryption arms race across the Trump administration, as both the president’s advisers and career civil servants scramble to cover their digital tracks in a capital nervous about leaks.

The surge in the use of scrambled-communication technology — enabled by free smartphone apps such as WhatsApp and Signal — could skirt or violate laws that require government records to be preserved and the public’s business to be conducted in official channels, several ethics experts say. It may even cloud future generations’ knowledge of the full history of Donald Trump’s presidency.

The article seems to be well reported, and it raises some of the important issues around the trend toward encryption in DC. But I think it misses a few points, which I’d like to open up in this post.

The first point is that there is nothing wrong with government employees using encrypted apps for their personal communication. Indeed, doing so should be considered a best practice for people who might be targets for foreign intelligence services–such as people who work at the White House. Insecure practices in the personal lives of government officials create risk–and it seems ill-advised for White House officials to try to stop their employees from following security best practices on their personal phones.

The second issue is the relationship between encryption and record-keeping. Government employees are required to retain records of much of their official communication–which is one of the reasons why business and personal activities are conducted on separate systems, more so in the government than in other enterprises. (The other main reason is security. And of course classified information is handled on yet another separate array of systems.) Government systems are set up to collect the necessary records, whereas your personal systems probably don’t retain everything that you would need to keep if you were carrying out government business on them.

But notice that record-keeping does not depend on messages being encrypted or not encrypted as they traverse a network. It is perfectly feasible to transmit a message in encrypted form, while archiving that message at one or both endpoints. If you’re using an untrusted network–and most of the networks you’ll encounter as you move through your life should be treated as untrusted–then it’s prudent to use encryption for data traversing those networks, and to meet any record-keeping requirement by logging messages at the endpoints. Some government-issued systems already work that way.

But the reality for White House employees–based on my experience working there–is that they seem to have access to better encrypted communication tools on their private devices than they do on their government-issue devices. And that leads to a natural temptation to transact government business using secure apps on personal devices. One way to address that would be to improve the encrypted communication tools available on government-issued devices, while making sure to configure those tools to keep records and maintain accountability as legally required. That wouldn’t stop employees from using their personal devices because they want to avoid accountability–cheaters gonna cheat–but at least it would reduce the temptation to use personal devices to try to improve security.

Finally, one has to wonder how this discussion is affected by the politics of encryption. I’ll write about that in a future post.

 

RIP, SHA-1

Today’s cryptography news is that researchers have discovered a collision in the SHA-1 cryptographic hash function. Though long-expected, this is a notable milestone in the evolution of crypto standards.

Kudos to Marc Stevens, Elie Bursztein, Pierre Karpma, Ange Albertine, and Yarik Markov of CWI Amsterdam and Google Research for their result.

SHA-1 was standardized by NIST in 1995 for use as a cryptographic hash function (or simply “hash”).  Hashes have many uses, most notably as unique short “fingerprints” for data. A secure hash will be collision-resistant, which means it is infeasible to find two files that have the same hash.

One consequence of collision-resistance is that if you want to detect whether anyone has tampered with a file, you can just remember the hash of the file. This is nice because the hash will be small: a SHA-1 hash is only 20 bytes, and other popular hashes are typically 32 bytes. Later, if you want to verify that the file hasn’t changed, you can recompute the hash of the (possibly modified) file , and verify that the result is the same as the hash you remembered. If the hashes of two files are the same, then the files must be the same–otherwise the two files would constitute a collision.

By 2011 it had become clear that SHA-1 was not as strong as expected. Any hash can be defeated by a brute-force search, so hashes are designed so that the cost of brute-force search is too high to be feasible. But methods had been discovered that reduced the cost of finding a collision by a factor of about 100,000 below the cost of a brute-force search.  All was not lost, because even with that cost reduction, defeating SHA-1 was still massively costly by 2011 standards. But the writing was on the wall, and NIST deprecated SHA-1 in 2011, which is standards-speak for advising people to stop using it as soon as practical.

The new result demonstrates a collision in SHA-1. The researchers found two PDF files that have the same hash. This required a lot of computation: 6500 machine-years on standard computers (CPUs), plus 100 machine-years on slightly specialized computers (GPUs).

Today, some systems in the field still rely on SHA-1, despite stronger hashes like SHA-2 getting more use, and the presumably stronger SHA-3 standard was issued in 2015. It is well past time to stop using SHA-1, but the process of phasing it out has taken longer than expected.

There are two lessons here about crypto standards. First, it can take a long time to phase out a standard, even if it is deprecated and known to be vulnerable. Second, the work by NIST and the crypto community to plan ahead, deprecate SHA-1 early, and push forward successor standards, will pay many dividends.

[Post updated (24 Feb) to improve terminology (collision-resistant, rather than collision-free), and to reflect the correct status of the SHA-3 standard.]