The FBI is asking amateur code breakers to help with an unsolved murder case. In 1999, the body of 41-year-old Ricky McCormick was found in a field near St. Louis, Missouri. The only possible clues to his death are two hand-written notes that were found stuffed in his pocket. The notes appear to be encrypted with a deceptively simple-looking cipher, but have so far resisted all attempts at cryptanalysis. The FBI’s code-breaking unit is hoping more eyes on the problem will help crack this puzzle.
A word of warning to would-be decipherers: Several famous codes and ciphers have tantalized cryptanalysts for decades or even centuries, and have never been solved (a comprehensive list is maintained by Elonka Dunin).
About a year ago, I was working on the solutions to the cryptograms in the first chapter of the Mathematical Cryptography book, and the idea struck me that it would be nice to have a computer program that could automatically solve such puzzles. It turns out that this is easier said than done, especially if the spaces between words are not preserved in the ciphertext and the puzzle author took pains to manipulate the character frequencies of the underlying message.
Exercise 1.4 (c) from the book is a good example. I urge you to try to solve it by hand in order to get an appreciation for the nature of the problem. It is not easy! Then think about how you would teach a computer to perform this feat automatically.
GSZES GNUBE SZGUG SNKGX CSUUE QNZOQ EOVJN VXKNG XGAHS
AWSZZ BOVUE SIXCQ NQESX NGEUG AHZQA QHNSP CIPQA OIDLV
JXGAK CGJCG SASUB FVQAV CIAWN VWOVP SNSXV JGPCV NODIX
GJQAE VOOXC SXXCG OGOVA XGNVU BAVKX QZVQD LVJXQ EXCQO
VKCQG AMVAX VWXCG OOBOX VZCSO SPPSN VAXUB DVVAX QJQAJ
VSUXC SXXCV OVJCS NSJXV NOJQA MVBSZ VOOSH VSAWX QHGMV
GWVSX CSXXC VBSNV ZVNVN SAWQZ ORVXJ CVOQE JCGUW NVA
Over the past 25 years, many papers have been published on the subject in various journals, and many interesting approaches have been proposed. It may be a surprise for some to learn that even state-of-the-art algorithms are not capable of reliably solving very short cryptograms (under 200 characters in length), especially when word divisions are eliminated.
My own attempt, building on work done by Prof. Richard Spillman (who first proposed attacking the problem via genetic algorithms) and Sam Hasinoff (who first suggested using character n-gram models), is an open source program called Alkindus. It works quite well, and is easily capable of solving puzzles similar to the ones from Mathematical Cryptography in a fully automated manner.
The work-in-progress paper describing the theory and empirical results is in need of a large collection of cryptograms completely independent of the Project Gutenberg corpus of English-language text that I used to train the underlying n-gram model. To use cryptograms derived from the training data itself would be cheating! So, I am especially interested in obtaining large amounts of English text (varying from say, 50 to 2500 characters in length), which could be used to put the program through a proper, rigorous test. If you have any suggestions, please let me know.
UPDATE 5 (March 25): A surprisingly well-informed and technically accurate article from a mainstream site? Go figure.
UPDATE 3 (March 23): Some observers are putting two and two together regarding the nature of the breach and what was stolen.
- Wikipedia [NOTE: This article has since been cleaned. The IP address of the individual who made the change is owned by RSA's parent company EMC.]
UPDATE 2 (March 21): Reports of a new official email to customers regarding the breach are beginning to appear. RSA is still not willing to confirm the theft of the token seed record database. However, reading carefully between the lines leaves one with the unmistakable impression that the strength of the SecurID solution has been reduced to the single factor of “something you know”.
1. What happened?
Recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our RSA business unit. We took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our IT infrastructure and working closely with appropriate authorities.
2. What information was lost?
Our investigation to date has revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.
3. Why can’t you provide more details about the information that was extracted related to RSA SecurID technology?
Our customers’ security is our number one priority. We continue to provide our customers with all the information they need to assess their risk and ensure they are protected. Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.
4. Does this event weaken my RSA SecurID solution against attacks?
RSA SecurID technology continues to be an effective authentication solution. To the best of our knowledge, whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers. We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold. RSA SecurID technology is as effective as it was before against other attacks.
5. What constitutes a direct attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.
6. What constitutes a broader attack on an RSA SecurID customer?
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.
The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their PINs. Social engineering attacks typically target customers’ end users and help desks. Technical attacks typically target customers’ back end servers, networks and end user machines. Our prioritized remediation steps in the RSA SecurID Best Practices Guides are focused on strengthening your security against these potential broader attacks.
7. Have my SecurID token records been taken?
For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.
To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.
8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?
As part of our standard operating procedures, while we further harden our environment some operations are interrupted. We expect to resume distribution soon and will share information on this when available.
UPDATE 1 (March 20): Apparently, RSA executives have been telling customers to ensure that they don’t give out the serial numbers on their tokens. This is yet another clue that the breach may have involved the theft of the database mapping token seed records to token serial numbers.
In an open letter to its customers, RSA chief Art Coviello disclosed yesterday that an internal data breach had been discovered affecting the security of RSA’s SecurID product line. He states:
While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.
We are left to wonder and speculate on the exact meaning of this statement. Perhaps the worst-case scenario would be the theft of the token seed record database. A little background information will clarify why this would be of significant concern.
Each RSA token uses 3 input numbers which are mangled using the AES-128 block cipher to generate a new 6-digit token code every 30 or 60 seconds:
- A token-specific 128-bit random seed (used as the AES encryption key)
- The current date/time in YY/M/D/H/M/S format (64-bit)
- The token’s serial number (32-bit) + 32 bits of padding
The security of the token depends on the fact that the 6-digit code is unpredictable. If hackers stole RSA’s database containing a mapping of token serial numbers to corresponding random seeds, it would allow the hackers, in effect, to predict what 6-digit number is displayed on any token at any time.
In order to exploit this information, they would also need to know:
- the serial number of the token attached to the account they are targeting, and
- the PIN (password) of the owner of the account
This information would need to be gathered using the same methods used to attack standard password information, i.e. through phishing, social engineering, repeated guessing, etc. In effect, it would reduce the security of the RSA token from two-factor to single-factor: Once you have the victim’s PIN and token serial number (which is stamped on the back of the token itself), you have all the information necessary to authenticate as the victim.
Without further details from RSA about the extent of the data breach, it is impossible to say whether this is in fact what happened. However, one thing is clear: RSA’s customers need more reassurance than they are currently getting.