Even 'random junk' may need encryption

There appear to be some interesting legal cases springing up around the fact that software developers have been taking "raw" Unique Device IDs and using them to store data against a given user 'in the cloud'. UDIDs essentially resemble a long 'random number' rather than directly encoding any user-identifiable information, so you may be forgiven for wondering what the issue is. The problem comes when applications have then stored user-identifiable information (such as social network data) alongside the UDID and make this information available to other applications, thus leading to a 'leaking' of user-identifiable information on the basis of this shared UDID.

The solution is in principle simple: append the UDID to an application-specific code or 'salt' and then encode this combination using a secure hash scheme such as SHA-256. The application-specific salt doesn't need to be a secret. But doing this means that I cannot compare a hash for user X from one application with a hash for user X from another application and deduce that they are for the same user. Again, in principle.

However, this scheme does rely on UDIDs containing sufficient entropy. Since the number of devices of a particular model sold is maybe in the tens or at most hundreds of millions (iOS devices appear to have sold something in the order of 200 million so far), if it is possible to make a good prediction of which range of the theoretically possible UDIDs has actually been allocated, then I can simply pre-compute all the potential combinations of (allocated hashes, application ID) for two given applications and find all the matches.

I haven't yet looked into all the details, but it appears that iOS 5 will remove the ability to read device-wide UDIDs in favour of application-specific UDIDs, presumably generated using a scheme such as the above. Although this is arguably the scheme that should have been adopted from the outset, if true, it will interesting to see what incompatibilities this throws up.

So why didn't people think of this in the first place? I wonder if one of the issues is that to a human, UDIDs do just look like 'random junk': it's just a string of random numbers, right, so why would you bother encrypting it? It's a good example of how when deciding when and how to employ encryption, we have to think not only about the data itself but also about protocols and practices governing how that data is used and stored.

Google's malware warning

Google have given more details of the malware warning that they will be issuing at the top of their search engine. They have been able to identify around 2,000,000 infected machines on the basis of traffic sent to their servers.

A couple of things strike me about this:

• I wonder how applicable this technique could be to other servers in general? Could we see other sites performing a similar civic duty of warning users about potential malware.
• Given that one route of infection (which Google blames specifically as the culprit in this case) are those fake "Your computer has been infected" popups already littering the Internet, how do we give out a message to users that these popups should generally be ignored because they're likely to be fake, whilst at the same time issuing genuine warnings in an ostensibly similar manner?

I'm interested to hear your thoughts either here, or by tweeting to BitterCoffey.

Have CAPTCHAs gone slightly too far...?

I like a bit of security just like the next man. But I wonder if this piece of "security" is going slightly too far. It appears that in order to make a posting on Facebook, we are now required to fill in a CAPTCHA consisting of words in two different alphabets...?

Now, I was trying to decide if this was some kind of perverse general knowledge test, or the latest CIA "initiative" to track down terrorists. Mention the wrong keyword and show an ability to type Arabic, and you're suddenly on the list of America's most wanted...?

(Oh, and even if I could have read Arabic, I would have still got stuck with the mysterious blob on the left. Answers to that one a postcard...)

Security and public wireless networks

The other day I wrote of the problem with Social Security Numbers being used as the basis of authentication. I mentioned that the underlying problem was an assumption that security lay somewhere that it didn't.

A recent Fox News article about rogue wireless networks set up by criminals in airports and other public places demonstrates a similar failure to understand where security lies. As pointed out in the article, criminals can easily set up "trojan" networks in places where we would expect a legitimate one to exist.

But from a security point of view, worrying exclusively about these fake networks kind of misses the point. In attempting to make your computer and computer use secure, you should always assume that any network is inherently insecure. It should not matter whether you're connecting via the "official" JFK Airport network or its fake counterpart. The problem isn't that you need to avoid sending confidential details encrypted over the hacker's network, or update your antivirus specifically for connecting to that network. You should always be taking such measures for any network. If you've got your security policy right, then connecting via the hacker's network should be completely safe! You're security should not be relying on a particular network being "safe"; no network carries such a guarantee-- and especially no publicly accessible network (note that even if you had to type in a password to access the airport's network, it's still a public network!).

As well as having a paid-for firewall and antivirus that you keep up to date, you should be taking measures such as always accessing e-mail via an encrypted service, ensuring any financial transactions are made via an encrypted service, heeding warnings from your browser about problems with certifiates, not installing software from untrusted web sites, making sure you e-mail service has built in antivirus, and in any case not opening e-mails from suspicious recipients.

Social Security Numbers and "security": a case of misguided assumption

The research on predicting social security numbers published today by Alessandro Acquisti and Ralph Gross from Carnegie Mellon University unfortunately highlights a fairly classic case of something we do all too often: basing security on something that was never secure-- and never really intended to be secure-- in the first place.

Much of the information that we readily pretend is a valid authentication key (such as Mother's Maiden Name, Date of Birth and Post Code-- and indeed Social Security Number) has really always been publicly available information. The parameter that has changed is how financially viable it is for a criminal to access the public records necessary to deduce this "secret" information. The SSN allocation scheme is perfectly well documented, public information, and the scheme clearly has no element of security built into it whatsoever. The historical origins of the scheme are also documented: the scheme has no security now, never did and was never intended to.

So what do we need to do about this? We need to understand where security actually lies, and not pretend that it exists in places where it doesn't. In most cases, the "security" does not currently lie in whether somebody can guess your PIN number, forge your signature, find out your mother's maiden name or guess the last couple of digits of your SSN. Our measures for preventing discovery of these largely unsecret "secrets" are predictably diabolical, and they are thus extremely weak forms of authentication. A transaction that is "authenticated" by an SSN or signature is essentially unauthenticated and the security of that transaction relies on it being quickly reversed in the event of fraud. So long as users, banks and lawmakers all understand this, the situation isn't so dire. The big danger comes when we pretend that there is security and authentication where there really isn't.

New section: Java cryptography

Several pages of the new section on Java Cryptography are now available for review and general criticism. Topics currently covered include:

• how to encrypt data in Java, looking at encryption with symmetric block ciphers as well as the RSA encryption scheme commonly used for passing session keys;
• different block modes, and how to use block modes in Java (including how to set an initialisation vector necessary in many cases via the IvParameterSpec class);
• how to choose and set the key size to use with encryption, and how to remove the key length restriction which is imposed by current versions of Sun's JDK by default.

Topics not currently covered, but planned for the near future include:

• comparison of block cipher algorithms: performance and security considerations;
• secure hash functions and authentication;
• cryptographic protocols;
• secure random number generation (note that the Java SecureRandom class is currently discussed in the site's section on random numbers in Java);
  
• digital signatures.

As usual, comments about the currently published sections are always welcome, as are suggestions for future additions to the cryptography section or to any other section of the web site. Please leave comments either on this blog or in the Java cryptography section of the Javamex discussion forum.

Update 12/04/09: The section now contains some information on secure hash functions in Java, plus a comparison of encryption algorithms.
19/04/09 As discussed in a separate blog entry, some information on password-based encryption is now included.

Enjoy...!