Riding in the Car with Boy: Why Relying on Old Technology Can Be Deadly
My father never purchased a new car while I was growing up. He plotted depreciation over time and explained it was financially optimal to buy a four year old car with low mileage. And we would drive them “into the ground,” keeping cars for a decade or more.
The first car I remember was our ‘57 Chrysler Windsor, which Dad kept until well after we moved in 1968. This was three years after Ralph Nader published Unsafe at Any Speed, which documented the automobile industry’s reluctance to adopt safety standards.
Sometime around 1973 I read a Reader’s Digest article about automotive safety improvements made in response to Nader’s seminal work. This article said the chance of surviving a crash in a new car was several hundreds of percentage points higher than in a ten year old car. I remember talking with Dad about the article, somewhat concerned that we were driving in a ’67 Olds 98 at the time.
Little did I understand this conversation we had over fifty years ago perfectly modeled the conversation many Chief Information Security Officers are having today with their Chief Financial Officers. Back then my Dad would argue that our old cars were good enough. Just as CFOs today would say the organization’s old data security is good enough.
Just as automobiles needed up-to-date safety items to prevent injuries in case of an accident, computers need up-to-date security algorithms to prevent data loss in case of a security breach. We would flinch at driving our children around the Interstate without air bags, infant seats, neck restraints, or shoulder belts. So why do we expect older security algorithms to protect us against today’s risks?
The original standard for the DES encryption algorithm (FIPS 74, from 1981) described a method for performing Format Preserving Encryption (FPE) using XOR operations. But that algorithm has well-known security limitations. As Phillip Rogaway documents in his Synopsis of FPE, FIPS 74 style FPE has a safety problem: it’s not secure. Quoting Rogaway:
The PRP notions we have described allow one to discount many potential FPE schemes as “wrong” (that is, completely insecure). Suppose, for example, we try to make an FPE scheme E for 30-bit strings by saying that EK(X) is X xored it with the first 30-bits of AESK(C) for some 128-bit constant C. The method is wrong in that, for example, EK(A) ⊕ EK(B) = A ⊕ B, while π(A)⊕π(B) is only rarely A⊕B. So a[n] adversary will be able to easily win the game we have laid out: ask the oracle distinct strings A, B and see if the xor of the ciphertexts is the xor of the plaintexts. As trivial as this attack may be, it is quite enough to break the suggestion in FIPS 74. Having strong definitions of security goes a long way in helping to keep us out of trouble.
Another way of putting this is as follows: suppose you wish to perform first six, last four FPE on PAN data. Using FIPS 74, an attacker could take any two credit card numbers and compute the remaining six digits just by knowing the XOR of the protected numbers is the same as the XOR of the assumed plain text numbers. So FIPS 74 FPE is completely unsafe.
A lot has changed over the years. The model year 2017 NIST FPE standard (AES with FFX extensions) used by HPE Security specifies the use of Feistel networks, not XOR operations, to protect data. With NIST FPE, the XOR of the protected and clear text are never the same (except by pure chance). It’s much safer.
We know mechanical objects, like automobiles, wear out with use. And we replace those objects with better, faster, safer models. Software does not wear out, but rather becomes obsolete, especially due to security risks: we’ve seen this time and time again with breaches related to an operating system vulnerability.
Data security software especially needs regular attention and updates. If we don’t keep up with attackers, we remain vulnerable. And the illusion we are protected via an obsolete algorithm results in more breaches than no algorithm at all.
Photo caption: Mom brings the author’s older brother, Joel, home from the hospital in her ’50 Plymouth Special Deluxe. Seat belts not included.
Jason Paul Kazarian is a Senior Architect for Hewlett Packard Enterprise and specializes in integrating data security products with third-party subsystems. He has thirty years of industry experience in the aerospace, database, security, and telecommunications domains. He has an MS in Computer Science from the University of Texas at Dallas and a BS in Computer Science from California State University, Dominguez Hills. He may be reached at firstname.lastname@example.org.