K
What would it actually take to obtain K ? How would they retrieve it from a running system ?
Is this a script kiddie possibility or more of a serious black hat challenge .
Crypto researchers from the University of Pennsylvania, working with Johns Hopkins cryptographer Matthew Green, have discovered a serious security blunder and branded it DUHK, which stands for Don't Use Hardcoded Keys. The vulnerability – described in depth at this “silly logo” website here – lies within an ancient pseudo- …
From: https://www.cryptosys.net/rng_algorithms_old.html#rng_X917
X9.17/X9.31 algorithm to generate the next 64-bit block
Given
D, a 64-bit representation of the current date-time
S, a secret 64-bit seed that will be updated by this process
K, a secret Triple DES key
Step 1. Compute the 64-bit block X = G(S, K, D) as follows:
I = E(D, K)
X = E(I XOR S, K)
S' = E(X XOR I, K)
where E(p, K) is the Triple DES encryption of the 64-bit block p using key K.
Step 2. Return X and set S = S' for the next cycle.
Given there are likely to be flaws that result in device reloads (across all potentially vulnerable devices) making K known and D a fairly small range, the vulnerability looks bad.
The only potential mitigation is that this may only apply to devices using older crypto options (I.e DES/3DES or MD5/SHA-1) as you shouldn't be using this for important stuff when AES GCM and SHA-2 are readily available for most encryption functions.
This post has been deleted by its author
Sorry, we're long past that point. Back when nothing much besides "attack at dawn" was using encryption, all you needed was that crypto holding until noon - but these days anything and everything uses encryption, including "long shelf life" things like documents, logs, and captured data streams that you don't want accessible anywhere within a lifetime. Using keys derived from a predictable engine that also produces publicly available nonces won't exactly do that kind of thing for you.
"When in the army the type of encryption used depended on the value of the information being passed. "
Which gave an indication of the value of attempting to crack it and the value of targetting those sending it.
One of the first principles of crypto is that you should use the same crypto for everything and encrypt everything including your laundry lists so that attackers don't get clued into what's valuable or not (which in turn means it should be strong crypto)
The more sadistic might choose to only encrypt their laundry lists and watch the spooks pile in to try and decode the "valuable data".
Yes and no--and mostly no. It is true than in WWII, we decrypted 95% of Japan's top-encrypted code and <30% of their less encrypted. But their top-encrypted system was not field-mobile. (Same issue in Europe, as I understand it.) You can only afford so much encryption--which is why AES does not use 8196 bit keys. Mobile hardware operates under a lot of hard constraints--encryption becomes something else you pay for.
Certainly, if any level of encryption carried the same cost as the highest, then I would encrypt my laundry list and rickroll. But it does not.
"How easy is it to carry out the attack? Is it practical?
Yes. Our attack against Fortigate device can be carried out on a modern computer in about four minutes. In the more general case, the practicality depends on the specific implementation details of the RNG."
Key problem. The seed value is hard coded in the program. Any implementation could do this.
A very bad idea, regardless of how "random" (and they make no comment on how good a generator it is) the PRNG is .
IOW "DUHK, you suckers !"
... crypto certifications require resources which could otherwise be used to have better crypto.
Or in a practical example: Imagine company X has a random number generator which passed certification. Now one of the engineers has a good idea to make it much more secure. They will be stopped from implementing it since any change would mean recertification which is expensive.
I feel it only fair to point out for the sake of accuracy in this world of “fake news” and questionable statistics that this post’s targeting of Fortinet is pretty unfair. The firmware in question (4.3) went out of support in 2014, and the issue was found in 4.3.13 and patched in all subsequent builds. Frankly if an IT admin is not keeping on top of their security patching at such a fundamental level then they need to be put into a dark room, have the door bricked up, wall paper applied and forgotten about. In the real world security engineers are aware that there are unsavoury people out there whose sole purpose is to get in to our little fiefdoms and wreak havoc, so we spend all our lives updating firmware, installing patches, deploying new versions, and inconveniencing users to try and stay one step ahead.
To say that this will “flay Fortinet first” given they fixed the issue 3 years ago and have since end of supported the entire 4.x line to move customers to the 5.x line is like writing an article entitled “Londoners dying of cholera and typhoid” focusing on the practice of slop buckets and failing to mention that time has passed, things have developed, and improvements have been made. As we’re aware London has sewers and deaths by cholera and typhoid are few and far between these days cos we aren’t tipping buckets of excrement out the window.
I know very well the pain involved in maintaining a secure environment and Fortinet aren’t perfect, but this article is simply inaccurate and needs to be fact checked by someone not working in the Trump White House.
hmm. while I appreciate your argument, I have many devices (hello TV, hello 'tablet', hello most consumer electronics) which are out of support, and have not been patched. Businesses are usually the same and simply play "hide the weak thing under the blanket of the external firewall".
Just because it was patched 3 years ago doesn't mean there are not hundreds of thousands of devices sitting around unpatched. There have been lots of botnets rolling printers and security cameras into their midst for exactly this reason.
Unfortunately the reality is that sysadmins don't buy all the gear, and it doesn't all get patched, so I think a fairer comparison would be an article like "there could be a problem with cars getting stuck in the tunnel because they run out of fuel as the fuel gauge is incorrect" < and your response is: well, everybody knows to fill up with fuel so this should never happen, and the new cars have a fixed fuel gauge and everybody should update their fuel gauges as soon as new ones are available.
So yes, you're right. But it's worth the article to get the word out to any of us who do have these devices and the ability to do anything about it. It's certainly not on par with Trump's - ahem - political commentary
It seems like the normal, prudent, default rules ought to be something like:
Apply software patches that correct vulnerabilities;
Upgrade software that is out of support;
Replace hardware that is out of support. is issued.
That makes sense whether you are a business or an individual consumer. Not doing them is accepting a risk that could be mitigated at a cost. Companies and individuals may do this consciously and rationally based on a proper risk analysis. More often they do it unaware of the risk, or based on a faulty risk analysis.
Consumer devices present the ugly problem that end of support dates often are not announced (and the support often is deficient anyhow), and few consumers can do a risk analysis anyhow.
So, before I buy something I need to have a full understanding of every design feature so I can perform a risk analysis?
One: burden!
Two: doesn't feel like I'm going to be able to do this without the source code and tool chain, 48 PhDs and a lot of time
Three: When products degrade due to wear and tear, I expect them to break in a safe manner. I don't expect my fridge to burn down my house and this is precisely why we have legal requirements for their safety. (Yes, these change over time but we still have product recalls as an option. I don't see why the cost should be borne by me except rolled up into the original purchase price)
We need legal requirements which dictate what is and what isn't a safe device. But it's the internet so it's confusing and normal rules don't seem to be adequate.
No: government approved does not equal safe, but there are existing standards bodies that span borders and something similar needs to be in place and enforced........ IMO, maybe I'm just lazy and cheap