Welcome
About
News
Anonymous Reporting
Tools
MCA Chatter
Library
V-ID Terminal
Support
My Account

News

Icon representing US Coast Guard Bulletin: Cyber Adversaries Targeting Commercial Vessels
US Coast Guard Bulletin: Cyber Adversaries Targeting Commercial Vessels

June 21st 2019
Icon representing Would you pay $1m for a laptop full of malware?
Would you pay $1m for a laptop full of malware?

May 23rd 2019
Icon representing Singapore Opens Maritime Cybersecurity Operations Centre (MSOC)
Singapore Opens Maritime Cybersecurity Operations Centre (MSOC)

May 22nd 2019
 
 
 

Don't Use Hard-coded Keys

 
October 25th 2017
Hard-coded keys and pseudorandom numbers flay Fortinet first, other vendors probably also in play
Crypto researchers from the University of Pennsylvania, working with Johns Hopkins cryptographer Matthew Green, have found a serious security issue and branded it DUHK, which stands for Don't Use Hardcoded Keys.

The attack, explained at the “silly logo” (Green's words) Website here, is in an ancient pseudo-random number generator (PRNG) protocol, deprecated in many products, but still present in plenty including around 25,000 devices made by Fortinet.

The protocol in question is the ANSI X9.31, which lingers from the 1990s. Until 2016 it was approved by the US government's FIPS Cryptographic Module Program, and uses a fixed key as one of the inputs to generate pseudorandom numbers.

As Green explains:

“If an attacker were to obtain K (one of the pseudorandom number generator's (PRG's) input values somehow, and then was able to learn only a single 16-byte raw output block (Ri) from a working PRG, she could do the following: (1) guess the timestamp T, (2) work backwards (decrypting using K) in order to recover the corresponding state value V, and now (3) run the generator forwards or backwards (with guesses for T) to obtain every previous and subsequent output of the generator.

“Thus, if an application uses the ANSI generator to produce something like a random nonce (something that is typically sent in a protocol in cleartext), and also uses the generator to produce secret keys, this means an attacker could potentially recover those secret keys and completely break the protocol.”

Fortinet's exposure (for which patches are available, you know what to do) was discovered by combing US government certifications to identify possibly-vulnerable vendors, and combing documentation to identify how the PRNG was configured.

Other vendors identified as formerly supporting X9.31 included:

Those who have offered updates: BeCrypt, Cisco (Aironet products), MRV Communications' LX-4000T/LX-8020S, Neopost Technologies, and Vocera Communications;
The group was unable to confirm fixes for products from Deltacrypt Technologies, Neoscale Systems, Renesas Technology, TechGuard Security, Tendyron, or ViaSat.
While the paper – and many headlines – draw attention to Fortinet, there's a good reason for that: of the twelve devices the researchers identified as potentially vulnerable, they could only access Fortinet's firmware for analysis.

This raises the possibility that other un-patched systems are still out there, which use crypto modules that support X9.31.

A handy example is processor vendor Xylinx. The company licenses Helion Technology crypto modules for use in its devices; if a downstream OEM designed a product with a fixed K, Green confirmed to The Registerthe product would be vulnerable.

As he writes in his post: “It’s almost certain that this small Fortinet vulnerability is just the tip of the iceberg”.

Returning to the Fortinet example: the group was able to get through what ranks as a Holy Grail of decryption, successfully recovering data sent over VPN sessions.

The co-authors on the paper are Shaanan Cohney and Nadia Heninger of the University of Pennsylvania, and is attached here as a downloadable PDF.

Source
Portable document format
Portable document format 486,25 KB
October 25th 2017 11:51

Keywords