Unsafe random bit generation algorithms

December 18, 2013
Followers: 0 people
11

Unsafe random bit generation algorithms

Followers: 0 people
December 18, 2013

ColdFusion Enterprise installation includes FIPS compliant RSA BSAFE JCE Crypto Provider. Default algorithm used by this library for random number generation is ECDRBG (A variant of Dual Elliptic Curve).  RSA has released an advisory regarding same (ESA-2013-068) listing unsafe random bit generation algorithms. 

ColdFusion sets the default random number generator algorithm to FIPS186Random (JVM argument -Dcoldfusion.jsafe.defaultalgo=<algorithm>) which is completely safe to use.  So good news is by default your ColdFusion 10 installation is secure. Note that CrypotJ libraries are not available in Standard installation of ColdFusion. 

ColdFusion 9 family uses BSafe library 3.6 which doesn’t make use of ECDRBG based algorithms. It uses SHA1PRNG as default random number generation algorithm. There is no impact on coldfusion 9. JVM argument -Dcoldfusion.jsafe.defaultalgo is not available in ColdFusion 9 family.

Following table lists unsafe random bit generation algorithms.

Algorithm Identifier Algorithm
ECDRBG Dual EC DRBG (128 Bit)
ECDRBG128 Dual EC DRBG (128 Bit Default)
ECDRBG192 Dual EC DRBG (192 bit)
ECDRBG256 Dual EC DRBG (256 bit)

Pete from CF community has also blogged about the same here

Other Links:

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-A%20Rev%201%20B%20and%20C

http://en.wikipedia.org/wiki/Dual_EC_DRBG

Comments (11)
2013-12-18 07:49:19
2013-12-18 07:49:19

@Shilpi – Congratulations! Didn’t know you were expecting, is this your first?

@Adam / @Carl – I think what Pavan meant by ColdFusion standard installation… is the Default ColdFusion installation, not Standard vs Enterprise.

Guys – let’s not overlook that this is good news, security issue averted by Adobe’s defaults.

I agree it could have been communicated more clearly and with more info. I brought this issue to Adobe last week after doing my research on it, so I had already spent a lot of time looking into this. My blog entry wasn’t an attempt to clarify this one, I was nearly finished with it when I found this blog entry.

Like
2013-12-17 14:11:41
2013-12-17 14:11:41

Also just found myself wondering… has Shilpi been sacked as “Security Tsar”? I dunno who Pavankumar is, but I would have thought the security boss would be releasing this sort of announcement. And… erm… maybe following-up client questions..?


Adam

Like
2013-12-17 14:08:47
2013-12-17 14:08:47

@Carl: oh right. So one has to question why this article takes pains to deal with Standard, and specifically glosses-over Enterprise.

TBH, just in case people don’t read the comments, I think Adobe should take down this article and replace it with a copy of Pete’s.

This article perhaps does more harm than good, if indeed it has achieved anything at all beyond stirring the community’s “WTF” response, and encouraging Pete to release his own article.


Adam

Like
2013-12-17 12:48:00
2013-12-17 12:48:00

The post also doesn’t clarify that this only applies to CF Enterprise. As Pete Freitag points out in his blog post, only CF Enterprise ships with the RSA BSAFE crypto provider.

Like
2013-12-17 11:11:42
2013-12-17 11:11:42

I’d just like to second what Peter says, Peter (err… you know what I mean). *Now* I understand the issue.

Adobe: I’m sure you can compare the two blog articles, and see what I mean. Maybe you should engage Peter to write your security-oriented blog articles in future.

Cheers.


Adam

Like
2013-12-17 10:27:42
2013-12-17 10:27:42

Thanks Pete – clear, coherent and understandable.

Hopefully Adobe can learn from your example for next time.

Like
2013-12-17 10:04:05
2013-12-17 10:04:05

I know you want to hear answers to your questions from Adobe, but I’ve written up my research on this issue here: http://www.petefreitag.com/item/827.cfm

This issue does also apply to CF9 and CF8 since they also include RSA’s BSafe libraries (In CF Enterprise), the CF8,9,10 installations I checked already had coldfusion.jsafe.defaultalgo=FIPS186random set, but you should double check your installations.

Like
2013-12-17 04:33:01
2013-12-17 04:33:01

The more I read this blog article, the less I think I understand. I dunno if it’s because I’m thick, or it’s because the English is very unclear.

What are you actually trying to say here? Do we need to change our JVM.config args to include this coldfusion.jsafe.defaultalgo=FIPS186random setting?

I don’t want to sound rude, but might it be an idea to get someone who’s a bit more comfortable with “International English” to rewrite this? The Indian English approach of omitting articles (ie: “A” and “The”) make it a bit hard to untangle the meaning of text, sometimes. And I don’t think it’s helping here.

Forget about all the NIST stuff… just tell us what we need to do, if anything. EG: “if you have this config, you need to change this; if you have this other config, then you don’t need to do anything”, etc. Also – as Peter alludes to – which versions of CF are impacted, etc, is kinda essential info too.


Adam

Like
2013-12-17 04:10:38
2013-12-17 04:10:38

Please confirm:

1. Does this affect default installs, where the setting has not been modified?

2. Does this affect CF9, or is it related to CF10 only?

Like
2013-12-17 02:56:53
2013-12-17 02:56:53

NIST has recommended not to use the dual elliptic curve deterministic random bit generation algorithms as they contain a backdoor. With this backdoor one can infer the state of the PRNG by observing a few outputs.

Reference:
http://en.wikipedia.org/wiki/Dual_EC_DRBG

Like
2013-12-17 02:24:59
2013-12-17 02:24:59

What are the ramifications of this?


Adam

Like
Add your comment