Hackers Break Currency Validator To Pass Any Paper As Valid Euro 162
Trailrunner7 writes "If espionage is the world's second-oldest profession, counterfeiting may be in the running to be third on that list. People have been trying to forge currency for just about as long as currency has been circulating, and anti-counterfeiting methods have tried to keep pace with the state of the art. The anti-counterfeiting technology in use today of course relies on computers and software, and like all software, it has bugs, as researchers at IOActive discovered when they reverse-engineered the firmware in a popular Euro currency verifier and found that they could insert their own firmware and force the machine to verify any piece of paper as a valid Euro note. 'The impact is obvious. An attacker with temporary physical access to the device could install customized firmware and cause the device to accept counterfeit money. Taking into account the types of places where these devices are usually deployed (shops, mall, offices, etc.) this scenario is more than feasible.'"
Re:Firmware update? Unlikely. (Score:5, Interesting)
Almost to the car, he said.. "you remember those two guards?" "Yes.." I said "I didnt know them from Adam. You can get away with anything if you look like you know what you are doing."
A lesson I have remembered all my life and used on more than one occasion.
Re:Firmware update? Unlikely. (Score:4, Interesting)
There are some fairly sane security measures a maker of a security device can do for fairly cheap to ensure that a tampered device isn't going to work without a lot of money and time put in:
1: If it is something static like a bill checker, take the time to heavily QA the device, including throw prototypes in the field for a while. Then, just have the firmware burned into a ROM (a true ROM, not an EEPROM, EPROM, PROM, flash, or an OS on a HDD... it goes into silicon and is not modifiable, period.) Of course, a bill checker might need updates when the currency gets a facelift, so a bill checker likely would need some type of upgrade mechanism.
2: If an update mechanism is needed, TPM chips are not expensive. In fact, some ARM CPUs have them built in. That solves 95% of the problem right there, because if the OS isn't signed, the OS won't be able to decrypt the last stage and boot.
3: As a subset of #2, the code that allows flashing of ROM images should be in a non-alterable, signed image. This way, if the main OS image has to change, it has to go through the "gatekeeper" image to be written to the boot medium, or it doesn't get on there.
4: Multiple images. This way, if a flash image is verified and copied to a temporary space and is being copied to the main storage, a power failure doesn't brick the device. The TPM boots, finds the signature of the first image fails, tries the backup, boots from that. The flash process updates both images, so only one would be inoperable during an update at a time.
5: To prevent flashing to a less secure previous version, the OS image that does the image update work can be set to look at version IDs, or optionally, if the ID is signed with a certain flag, can allow earlier versions to overwrite newer ones, or have beta images be able to be downgraded if needed.
6: The image flashing would have to be via a physical process, such as a USB connection. This way, devices can't be upgraded over the network, which shuts out a lot of potential exploits.
I'm sure I've missed a few items, but it doesn't take a lot of engineering to have an update mechanism in place that is tamper resistant.