Solutions for Portable Security

The biggest security news this past week has to be the massive data breach of 77 million PlayStation user accounts on Sony’s network. Of course this is not the only incident of its type and unfortunately won’t be the last. My comments here are not trying to criticize Sony but rather to use this incident to illustrate some general issues that we should be concerned about as consumers, who have personally identifying information at stake, and as corporations, who take on the responsibility of maintain such information.

I’ve listed here the type of personal information cited by Sony as disclosed (or potentially disclosed) by the breach.

• Name, address
• Email address
• Birth date
• PSN/Qriocity Password and Login
• PSN online ID
• Purchase history
• Password security answers
• Credit card number and expiration date (for some users)
• Billing address

My first comment is why some of this information needs to be kept at all by Sony. Take birth date for example. I’m speculating that it may be necessary for Sony to be able to control restricted content based on a person’s age, however rather than storing your actual birth date, a simple flag would suffice to indicate whether you are over eighteen.

Storing plain text passwords and password security answers is completely unacceptable in my opinion. There are well known cryptographic methods (hashes, key derivation functions, etc.) for turning such information into something that can be stored securely which is very hard to for attackers to reverse, but easy for Sony validate.

When comes to credit card information, there are a couple of angles to consider. At first glance it would seem that this information should not be stored. After all, it is only needed for a transaction. Once the transaction is complete, why should this information linger (in fact for some companies it is mandatory to delete any card information immediately after its use). The general answer I believe is because we want convenience. I can’t think of any other “good” reason.

As consumers we don’t like typing a credit card number in every time we want to make a micro-purchase. I’m not a Sony PSN subscriber so I don’t really know if they use credit card information in this manner but imagine the effect on the sales on the Apple iTunes store if users had to pull out their card every time they had the impulse to buy a song? I admit that I like the convenience of iTunes but I would feel a lot better about it if I knew that my card information was not only encrypted, but encrypted by my iTunes password so that only I could enable its use, and any data breach that might occur renders it inaccessible without my password.

Sony is an innovative company that produces amazing consumer electronics products. They are not an information security company and I wouldn’t expect them to be experts in that field. This breach is a really tough lesson for Sony but they should now realize that they had way too much sensitive data stored insecurely. While not being experts in security they should still have known better and I think this illustrates a serious gap in awareness and transparency when it comes to companies managing our personal information.

The problem with information is that it isn’t tangible. You trust a bank to store your money but you wouldn’t trust a grocery store. Conversely, I’m sure a grocery store would get very nervous if they had to keep huge piles of money in the stockroom and would even realise that they’re not properly equipped to protect it. It’s unfortunate that sensitive information doesn’t have that same intrinsic ability as money to alert companies and consumers when things are getting risky.

For some related thoughts see these other posts: http://www.mxisecurity.com/blog/cto/2009/10/21/how-about-opt-in-certificate-web-logins/
http://www.mxisecurity.com/blog/cto/2010/12/14/why-you-shouldn%e2%80%99t-have-a-database-of-passwords/

Unless you are a mathematician or a cryptologist, a technical description of how an encryption algorithm works can make your eyes glaze over.  So I thought I would do something that is both mildly educational and a little bit entertaining (see the challenge at the end of this blog entry).

I wrote a little crypto application that encrypts and decrypts graphical images.  The encryption algorithm (call it algorithm X) is “home-grown” and was designed to be visually appealing rather than secure.  I will use it to illustrate some weaknesses in its encryption and to highlight a couple of essential properties of a good crypto algorithm.

Algorithm X is a simple permutation of pixels in the image.  Each iteration or frame will permute the pixels a bit more.  The permutation rule is designed so that the pixels appear to move and collide with each other like billiard balls, which is what makes it visually appealing.  After many rounds the image becomes more scrambled and at some point you could say it is “encrypted”.  Simply running the rule in reverse decrypts the image.  The following shows the input and resulting images produced by running algorithm X and AES.

Figure 1: Input Image

Figure 2: Encrypted with Algorithm X

Figure 3: Encrypted with AES

With algorithm X you can still see some of the original information.  For example, you may notice that the color information has not changed and that the pixels are merely scrambled.  You can also still see some clustering of pixels around where the flag and FIPS logo were originally.  This is because the permutations are very local and it takes many “rounds” (frames) for the pixels to become dissipated.  AES does a much better job at diffusing the information very quickly and using the entire range of colors uniformly so there is no discernable pattern relating to the input.  In fact randomness of the output of an algorithm was one of the criteria used by NIST when selecting the AES algorithm.

That being said I could conceivably modify algorithm X to produce similar looking images to the AES version but that is no indication of security.  Looks are only skin deep and the real security of an algorithm is also determined by other factors such as the soundness of the mathematical implementation, and its resistance to cryptanalysis.  Even so, public algorithms also spend years of being in the public domain where they should survive the test of time.

But once again, Algorithm X was designed to be entertaining not secure, which brings us to the fun part of the discussion.  If you download the application (download link) you can try the encryption and decryption of the sample above.

Challenge:
In the Visual Crypto application there is a secret image that has been password protected.  To decrypt the message you will need the correct password.  Using the clues below you can construct the password (Tip: search our recent press releases and device literature on our web site for answers).

Clues:
1. The password is thirteen characters (all upper case)
2. The name of the security evaluation for the UK Government that the Stealth M550 is undergoing: (4)
3. Acronyms of the U.S. Government smart cards that can be used as authentication factors for MXI Security devices: (3 + 3)
4. Family of devices that combine secure storage, strong authentication, digital identity services, and management functions?  (3)