ENCSecurity markets a file encryption system, and it’s used by SanDisk, Sony, Lexar, and probably others. Despite it using AES as its algorithm, its implementation is flawed in multiple ways—and breakable.
The moral is, as it always is, that implementing cryptography securely is hard. Don’t roll your own anything if you can help it.
Ray Dillinger • June 13, 2022 9:06 AM
secure cipher – not all that hard.
You need to know some things and you need to understand them. You need some basic math. Strong mathematical intuition and skill in at least some kind of higher math (topology, abstract geometry, differential equations, number theory, etc) is helpful but not absolutely required. If you don’t have it, you can stick to a tried-and-true architecture like a Feistel Cipher.
secure implementation – much much harder.
You have to start with a lot of knowledge from libraries and system calls that even professional programmers have probably never touched in their lives, going all the way down to grotty bits and bytes and how to do things with them without invoking undefined behavior. Even so this will take months of your life and multiple rounds of review. And even then – even if nobody has found a hole it it by the time you publish – you will be constantly waiting for some black hat to show you how you made a boneheaded mistake.
secure cipher worth using – much much MUCH harder.
Making a secure cipher with a secure implementation is very hard. Making a secure cipher that uses less compute power than AES to achieve similar security is damn near impossible (or AES wouldn’t have won the standardization). That higher math skill mentioned above as ‘helpful’ in designing a secure cipher is damn near a requirement in designing a secure cipher worth using. The kind of secure cipher a dilettante can design with AES level security will use at least 10 to 100 times the CPU that AES uses. If your higher math is strong, you may get it down to something in the 3-to-30x CPU range while remaining confident. But there’s not one designer in ten thousand who could get anything remotely competitive with it. So even if you come up with a secure cipher and secure implementation, there will be no point in using it.
secure key generation, distribution, storage, and management, with protocols to do useful things – just about out of reach.
Even the best of the best mess this up. There are so many flawed protocols and flawed key management systems out there – and these are mostly the best efforts of real pros – that it’s terrifying. Sometimes it’s a straightforward mistake like storing keys unencrypted somewhere or failing to design a protocol that does what people are going to use it for and believe it does. Sometimes it’s an egregious failure-by-design like early implementations of WEP and cell phone towers where it’s hard to imagine it wasn’t intentional. Sometimes it’s things like ‘ciphersuite negotiation’ that leaves an attacker free to do a downgrade attack, or protocol implementations that allow an attacker to jump to a completely different state by sending an unexpected out-of-band message, bypassing controls and redirections. But almost NO new protocol or key management scheme goes live without major flaws lurking it it waiting to be discovered. These things get the hardest review of all – review by mobsters looking to make a buck.
Ted • June 13, 2022 9:18 AM
Was a product claiming “AES-1024 military grade encryption“ a beckoning to security researchers?
As Sylvain goes on to say, the product offered AES keys sizes that were outside the standards. AES has key sizes of 128, 192 or 256 bits, but not 512 or 1024 bits.
High five to the researchers for henceforth finding issues that led to two CVE’s. CVE-2021-36750 for a predictable (hard-coded?) salt. And also CVE-2021-36751.
Maybe I’m wrong, but it seems like a bit of a surprise to find these issues in very common products.
TimH • June 13, 2022 9:23 AM
Curious what the liability is, “selling security as a product”, when secure when it isn’t.
Does the fine print absolve not following industry standard practice?
Chelloveck • June 13, 2022 9:25 AM
“Don’t roll your own anything if you can help it.”
SanDisk, Sony, Lexar, and probably others took that advice, and look where it got them. If most programmers aren’t competent enough to write their own encryption (and I agree that they aren’t) how can they be competent enough to evaluate someone else’s implementation? How does one judge which implementations are and are not secure enough for the purpose?
Mexaly • June 13, 2022 9:34 AM
SanDisk, Sony, and Lexar are not brands that I would look to for security products.
Especially a not freebie on a cheap thumb drive.
Especially not Sony. They have a reputation.
Winter • June 13, 2022 9:39 AM
@Ray Dillinger
secure cipher – not all that hard.
As our host remarked: Anyone can design a cipher that he himself cannot break (M/F)
The important point is not to design a cipher, but to battle test it with the community. No cipher that has not been tested by fellow cyptanalylsts is worth using.
Matthias U • June 13, 2022 11:02 AM
“it’s implementation” — “its”. Please.
MikeA • June 13, 2022 12:35 PM
@Matthias U
There’s an implementation for the Incompatible Timesharing System?!?
Good to know for all the hard-core Retro Computing (aka Computational Necromancy) fans. Time to blow the dust off the 6502 assembly version of Lucifer.
Ray Dillinger • June 13, 2022 1:01 PM
Absolutely true – anybody can design a cipher that they themselves cannot break. That much is easy. To get a cipher that other people can’t break, you have to know a middling amount of stuff. Probably one or two college classes worth, IME.
To design an efficient cipher that other people can’t break is Masters or Ph.D work.
But, my point is the cipher is NOT the hardest part. It’s not even the hardest part to get right. Ciphers are rarely broken. Protocols, key management, key distribution and storage, key generation, cipher mode implementations, buggy code, flawed protocols, etc, are broken EVERY. SINGLE. DAY.
Neill • June 13, 2022 3:22 PM
Increase security by adding a warning label to Post-its:
NOT TO BE USED FOR PASSWORDS
bender • June 13, 2022 3:31 PM
Do people actually use this stuff? Isn’t the functionality baked into modern Windows versions? Why trust something that came bundled with a $9.99 USB stick over what’s already in the OS?
I always assumed anything on these USB sticks is malware, spyware, or at best useless crapware, and everyone immediately deletes it…
Ted • June 13, 2022 3:52 PM
If anyone is interested in hearing the ‘true life story’ from ENCSecurity’s point of view, there’s a conference talk that sheds some light on the flaw discoveries and remediations.
It sounds like Boi Sletterink was working as a security consultant on behalf of EMCSecurity. He describes the company as being in “maintenance” mode when these flaws were revealed.
He had to pull together a team to deal with this and overcome obstacles such as summer holiday and part time staffing.
Clive Robinson • June 13, 2022 6:00 PM
@ bender,
Isn’t the functionality baked into modern Windows versions?
There has always been questions over MS’s encryption, and some of the people raising questions are shall we say quite experienced.
Which brings us onto,
Why trust something that came bundled with a $9.99 USB stick over what’s already in the OS?
So as noted MS’s OS encryption for file storage has question marks hanging over it. So all you are realy saying is you think MS are more trustworthy than a European (Dutch) company.
The reality is,
1, Trust Microsoft
2, Trust ENCSecurity
3, Trust company XXX
4, Trust some combination.
My prefrence where possible is option 4, whilst not possible with all file encryption what you do is “chain” the systems or as it’s file systems you “matryoshka”[1] the “Bag of Bits”(BoB) files and file systems on the theory that mistakes in the different encryption systems will probably not align.
Personally I’m also in favour of doing both stream and block ciphers with caching. As this can help get other issues better under control.
For example whilst the use of a stream cipher alows easy changing of bits, bytes, words or any data size, it’s open to “bit fliping attacks” on the ciphertext in transit or at rest.
Block ciphers are used in “modes” which can cause a whole heap of other problems as well, for the same reason as stream ciphers you do not want to use block ciphers in “Electronic Code Book”(ECB) mode or similar. Because in reality ECB is just a simple “substitution cipher” so you can swap blocks especially if the plaintext aligns with the cipher block size and boundaries.
To limit both of these attacks you need to use a “Message Authentication Code”(MAC). Essentially these are a chained function over the BoB using a crypto secure hash which you attache to the file in some way.
But these MACs have their own problems, especially with say a video file a few hundred megabytes long. You do not want to have to repeatedly re-hash the whole video file each time you change just one bit… It would make watching glaciers look like formular one racing in comparison.
You can “sub-block” the file and MAC each one of those then MAC the MACs but again you have to be carefull how you do things.
But there are other issues such as backup files. If you have a file and you edit it, when you save the edited version as a new file to disk you can see the new and old ciphertext files are basically the same file by the fact that they start with the same values and only start to deviate where the plaintext files differ. When tied to the position of the files in the file system structure, this leaks information that can assist an attacker.
You have to be carefull for other reasons such as OS paging it can cause all sorts of issues just as with backups but a whole bunch more on top.
Solving all these and other problems securely is quite hard and takes some careful thinking.
I’ve yet to see a consumer / commercial file encryption system you can readily get that does all of this…
[1] From a childs wooden toy the Matryoshka or Russian Dolls nest inside of each other, like the layers on an onion.
MrC • June 14, 2022 12:40 AM
It’s not really accurate to say that they botched their AES implementation. Rather they (1) rolled their own KDF, which was garbage, and (2) rolled their own scheme for chaining AES128, which turned out easily reducible to a single iteration of AES128.
Anywho, Chelloveck has a point. ENCSecurity rolled their own crypto and it was a predictable train wreck. But SanDisk/Sony/Lexar refrained from doing their own implementations and trusted an “expert” instead — and it was still a train wreck. What could SanDisk/Sony/Lexar have done to avoid this outcome? It seems to me that we have a sort of multi-party Dunning-Kruger problem: The set of skills needed to verify that your “expert” has produced a sound crypto implementation is the same set of skills you’d need to do a sound implementation yourself in the first place. Hence, no one to whom the “don’t roll your own” maxim applies is competent to distinguish actual experts from clowns like ENCSecurity. A similar problem exists when selecting mechanics or lawyers, and I’m not aware of any good solution in those cases either.
SpaceLifeForm • June 14, 2022 3:50 AM
@ Ted
LOL.
If attacker knows plaintext … what could go wrong?
Thanks for digging that up.
karaya1 • June 14, 2022 5:18 AM
I’ve actually seen a good paper that proposed “AES-512” (using 64-bytes block instead of 16-bytes like all standard AES variants, with corresponding changes in operations and an extensive discussion about its security), so I was looking forward to seeing something similar implemented & broken. However, that was not really the case. Bummer.
LucyCarter • June 14, 2022 7:43 AM
Is there fear AES will be broken, or that AES-256 isn’t strong enough? Even the DoD is looking for something better. No, I’m not talking about post-quantum public key.
All these ideas for bigger keys, more rounds, which don’t make any difference but nothing better for key management. They say, that’s your problem!
Clive Robinson • June 14, 2022 8:28 AM
@ LucyCarter,
Is there fear AES will be broken, or that AES-256 isn’t strong enough? Even the DoD is looking for something better.
AES is only clasified by the NSA as,
“Secret for data at rest”
A bland statment which hides a quite awful dirty secret…
That is AES is not sufficiently secure to be used in “on line mode”, but is still OK in “off line mode”.
The problem is not that the “algorithm” has been broken, it’s still “theoretically secure”, but “practical implementations” especially in software can hemorrhage information by side channels, that realistically can not be easily avoided.
As the DoD is moving from it’s ultra expensive “Green Radio”[1] boxes to the likes of Apple Smart Phones[4], they need something better than AES, a lot better.
[1] Military radio systems are called “Green Radio” simply because they are very nearly all “green” in colour, though many are actually way more “energy efficient” than consumer or commercial equivalents.
[2] Whilst the use of Smart devices worked for the US troops in the Middle East, the current goings on at the far east of Europe show a very different picture. So I suspect the US DoD will be having yet abother “re-think”.
Canis familiaris • June 14, 2022 8:45 AM
This is why I ignore built-in ‘security’ on USB drives and other media (like SSDs) and use LUKS.
Winter • June 14, 2022 9:43 AM
@Clvie
That is AES is not sufficiently secure to be used in “on line mode”, but is still OK in “off line mode”.
But, as you have written, an efficient cypher is sensitive to side channel attacks.
If all you need is security “at rest” the inefficiencies to secure for “on line” could make the whole enterprise unworkable. With “on line” too inefficient to be useful, and no “off line” mode for security, you could end up with nothing at all.
As has been written befor:
“The only system that is truly secure is one that is switched off and unplugged, locked in a titanium safe, buried in a concrete vault on the bottom of the sea and surrounded by very highly paid armed guards,” says Eugene H. Spafford, director of the Purdue Center for Education and Research in Information Assurance and Security. “Even then I wouldn’t bet on it.”
Clive Robinson • June 14, 2022 11:46 AM
@ Winter,
buried in a concrete vault on the bottom of the sea and surrounded by very highly paid armed guards
I hope those dudes can not only swim but know their decompression tables well 😉
But more seriously,
If all you need is security “at rest” the inefficiencies to secure for “on line” could make the whole enterprise unworkable…
As @Bruce will no doubt confirm, few people like using “mixed ciphers” where you use one cipher for storage and another for communications.
In part because of the “Key Managment”(KeyMan) issues, and in part because of “user” issues.
It’s one reason the industry is moving away from “uset keys” and heading down the “user passphrase” route.
Where you as a user never get to see the actual crypto-keys, they are derived from a “master secret” that is protected by the passphrase.
If the master secret “gets the chop” then theory has it all the files are secure because the keys can not be derived as needed. But equally as well if the Key Manager keeps a copy of the master secret back at HQ then two things can be done easily.
1, The user can be locked out very easily.
2, All the files can be recovered by the Key Manager / Sys Admin.
If that Master Secret is kept “out of jurisdiction” then the user under a civil justice system can not be compelled to “give the key” because they never had knowledge of them.
If they have say a laptop with just one of a pair of private keys then the master secret can be removed for traveling. When they arive at their destination having got through customs and boarder patrol and the like, they do the following,
1, Generate a random unique “nonce”.
2, Encrypt it with their PubKey
3, Send it to HQ.
4, HQ encrypts the master secret with the received “nonce”.
5, After making “duress checks.
6, Encrypts the nonce encrypted master secret with the other PubKey.
7, Sends that to the user.
8, The user decrypts with their PubKey, then decrypts with the nonce to obtain the master secret.
9, Uses the master secret to obtain the necessary file keys.
Security Sam • June 14, 2022 5:24 PM
Certainly any memory leak
Will make encryption weak
While any covert channel
Will create a porous panel.
SpaceLifeForm • June 14, 2022 5:53 PM
@ Security Sam
Silicon Turtles
When “constant time” is not.
Hertzbleed attack targets power-conservation feature found on virtually all modern CPUs.
Old kit does not have this problem.
lurker • June 14, 2022 8:36 PM
@SpaceLifeForm
Hertzbleed (and friends) cannot depend on a cast-iron network between attacker and victim. Thus the timing measurements might be run on the victim machine via another exploit . . .
SpaceLifeForm • June 14, 2022 11:09 PM
@ lurker
re: Hertzbleed (and friends) cannot depend on a cast-iron network
Do you mean to imply that a nearby upstream router during off-hours will not work?
Clive Robinson • June 15, 2022 12:59 AM
@ SpaceLifeForm, lurker,
re: “Dynamic Voltage and Frequency Scaling”(DVFS) power side channel.
This is not exactly new.
Power Side Channels have been known since the 1990’s and Smart cards. Back at the end of the 1990’s a certain US individual Paul Kocker patented various “analysis techniques” to try and corner the market, even though they were already publically known. Which put a dent in researchers abilities.
At the time I told him in email that you could do his “Diferential Power Analysis”(DPA) by the use of Active EM attacks so did not need to connect to the terminals (I’d also told Ross Anderson about EM attacks, and how they could be used to bypass the self clocking logic he was looking at using to get around power analysis as it could force the chip to “lock to the frequency” (I’ve mentioned “injection locking” several times on this blog and how it was discovered with mechanical pendulums by Huygens back in the mid 1600’s (oh and how it’s only in this century physicists got to grips woth it[1]).
Then there was using the heat that caused “Delta F” changes in system CPU XTALs that can be seen on the network and used to tell “Honey Pot” systems and which computers are shared in Xaas / Cloud / Rented web sites.
@ Robert T, @Nick P, and myself discussed ways of using such stepping to get information out of systems by “power analysis”.
And as I said just a the other day[2] it horrifies me how little software developers and engineers etc realy do not understand time on computers down at the physics levels. You’ld be surprised at just how much info leaks caused by people not understanding “Process, System, Wall” times and how they interact.
Oh and do you remember back to the NIST AES competition and how the NSA “rigged it”, so that “time channels” would get put into all the candidate algorithm software as well as making it freely downloadable, knowing full well that it would just get downloaded and put in consumer / commetcial applications and libraries. Which it did, and haemorrhaged data via timing side channels on the network and so why AES is only certified for “data at rest” “Off line” usage. Something I mentioned yet again just yesterday[3].
But then as I’ve repeatedly said about “Specmanship” and,”Gofaster Stripes” in hardware and Intel deliberately holding back information so they would get the Xmas sales boost to profits and one of their C staff could sell off their shares before a potential share price drop on the bad news, these CPU hardware bugs are “The Xmas gift that’s going to keep on giving”.
@ ALL,
Side channels that leak secrets are most frequently “time based” but the time aspect is most often a “symptom” not the “cause”. Think of skin rashes, for illnesses if you want a biological metaphor. I spent considerable time explaining this with True Random Number Generators on this blog if people want to go back and look it up.
The primary underlying cause behind “time side channels” is “work” in the physics sense with the utilisation of coherent energy to process information into non-cohearent energy cross modulated with a time signiture of the work being done. As should have been taught in high school science Energy / time utilisation is called Power and that is what DVFS, DPA, XTAL Delta F, and many more side channels that leak information are.
Almost always, such energy / time signitures get out on the cables and communications from a computer, and why I spend as much time talking as I do about “Emission Security”(EmSec), “segregation” / “issolation” and “Energy Gapping”…
[1] https://phys.org/news/2016-03-huygens-pendulum-synchronization.html
Clive Robinson • June 15, 2022 1:31 AM
@ SpaceLifeForm, lurker, ALL,
Do you mean to imply that a nearby upstream router during off-hours will not work?
As under bridges are the favourite roost of feral town pigeons, so you shall find the US IC roosting on upstream routers…
Both types are diseased, scaby parasites that are a significant health risk to the general public. So should be eradicated by the usual pest control methods of shot and poison.
SpaceLifeForm • June 16, 2022 1:00 AM
@ lurker, Clive, ALL
The beauty of HertzBleed is that the attacker does not have to perform the attack in a given time window (say 36 hours).
The attacker can take 36 days, or more.
It does not matter how long it takes, the key (pardon me), is that the key will eventually leak.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Clive Robinson • June 13, 2022 8:02 AM
@ ALL,
It’s not just the software you have to observe that,
“The moral is, as it always is, that implementing cryptography securely is hard.”
It’s the hardware as well. Consumer and Commercial systems are not designed to be secure, and these days most suffer from,
“Conect it all communications”
Basicaly they are like little broadcast stations, on which confidential information leaks in oh so many ways…