Researchers bake malware protection directly into SSDs(tomshardware.com)
tomshardware.com
Researchers bake malware protection directly into SSDs
https://www.tomshardware.com/news/researchers-bake-malware-protection-directly-into-ssds
24 comments
Is this also true for random OS churn etc? Basically when using the SSD as a “persistent cache”
You could probably get a tape to work like this if you can prevent rewinding.
i.e. a log structured file system.
Specifically a WORM. Like Plan 9 had with Fossil and Venti or as in Foundation https://swtch.com/~rsc/papers/fndn/
I really wouldn't trust this if the hardware encryption on SSD's is anything to go by. Microsoft actually defaulted Bitlocker to software encryption because the state of things were so bad.
I'm also wondering how the hashes will be kept up to date. Will it require a host program to communicate with the drive over a proprietary protocol? If so then that arguably makes this pointless, as obviously they're only going to work on Windows.
I'm also wondering how the hashes will be kept up to date. Will it require a host program to communicate with the drive over a proprietary protocol? If so then that arguably makes this pointless, as obviously they're only going to work on Windows.
As a matter of principle, I'm opposed to attaching even more computers outside the user's control to supposedly "personal" computers.
In the pursuit of security (or just the excuse of it), more functionality is being given to opaque, locked systems (SSD firmware, management engines, etc.), instead of freedom-respecting solutions (there is no technical reason systems can't be fully open-source, with user-controlled cryptographic keys, and a tamper-evident mechanism as some smartphones already have - i.e. a "bootloader unlocked" warning message).
This moves power away from users and to the manufacturers, contributes to the jenga-tower of technical complexity, and eventually worsens security, once vulnerabilities in these systems are inevitably found:
https://en.wikipedia.org/wiki/Intel_Management_Engine#Securi...
In the pursuit of security (or just the excuse of it), more functionality is being given to opaque, locked systems (SSD firmware, management engines, etc.), instead of freedom-respecting solutions (there is no technical reason systems can't be fully open-source, with user-controlled cryptographic keys, and a tamper-evident mechanism as some smartphones already have - i.e. a "bootloader unlocked" warning message).
This moves power away from users and to the manufacturers, contributes to the jenga-tower of technical complexity, and eventually worsens security, once vulnerabilities in these systems are inevitably found:
https://en.wikipedia.org/wiki/Intel_Management_Engine#Securi...
The modern "Software operating system" is a lie, it talks to an abstraction of other systems that masquerade as a predictable machine presented to them with known interfaces.
Linux is the new 'hardware compatibility layer'
Linux is the new 'hardware compatibility layer'
How would it ever work without the companion software? One of the motivation is that users don't install anti-ransomware software, but they do have to install this companion software that is effectively anti-ransomware, don't they?
I don't see the appeal compared to a fully software-based solution.
I don't see the appeal compared to a fully software-based solution.
Some people argue that sufficiently advanced ransom ware will evade or disable your software only solution but the same could be true of this it is just different and possibly more difficult to evade
Cool, where's the source code? Oh, right. No, thank you.
Much more interesting you can run Linux on HDD firmware of 2013 [1]. That would allow you to implement such yourself.
[1] https://spritesmods.com/?art=hddhack
Much more interesting you can run Linux on HDD firmware of 2013 [1]. That would allow you to implement such yourself.
[1] https://spritesmods.com/?art=hddhack
Detecting and/or preventing encryption might be useful, but since recent ransomware also downloads sensitive data files and uses the threat of disclosure to force payment, the encryption is only part of the problem.
While interesting, I would never buy such an SSD due to the performance hit.
On a Gen4 NVME with 7/6Gb read/writing speeds, I'm sure you can afford that performance hit.
Doesn’t that make the speed hit worse? Faster the drive the faster everything in the pipeline has to be.
Not everything is about throughput, I'm actually more interested in latency.
Also, I wouldn't buy it because I don't want anti-virus built into my hardware. I'm just not interested in the protection it provides.
Also, I wouldn't buy it because I don't want anti-virus built into my hardware. I'm just not interested in the protection it provides.
Believe Cigent claims to do something in the same vein
https://www.cigent.com/cigent-secure-ssd
https://www.cigent.com/cigent-secure-ssd
To cause complete data loss does not need much data to be written. I'm wondering how firmware can distinguish legitimate and malicious ones.
It'a a team of researchers. I'm sure they have a lot of great ideas. They could check every byte to see if it is a malicious one.
Or they could check if bits are malicious.
Just check for the evil bit.. its easy.
Alternative headline: Researchers do not know that FDE exists.
What I would trust:
A backup medium (SSD or whatever) which only allows writes to empty space. Unless a switch is manually switched from "write" to "update".
In "write" mode, it would only allow writing to empty space.
In "update" mode, it would allow writing everywhere.
I would leave it in "write" mode most of the time. For me, a typical SSD has enough space for years of incremental backups. If I should ever want to delete old backups, I would set it to "update" mode to do that and then set it back to "write" mode.