On 04/04/2017 12:36 PM, Steve Coleman wrote:
On 04/04/2017 10:29 AM, taii...@gmx.com wrote:
Opal is proprietary garbage,
Actually its an open standard, not controlled by any government or
corporation. One link I provided was to the standard which gets down
to the data structure byte memory layout and data interchange
requirements.
Open standards are arbitrary and they mean nothing, the actual
implementation is what matters.
How many drive firmwares are open source? (zero)
I could write up a secure system standard in 5 minutes, it takes no
effort and it isn't special.
and proprietary crypto schemes are almost always terrible.
They use standard encryption algorithms that have to pass very strict
compliance tests before a product is certified. The OEM implementation
inside the drive might be "terrible" but the algorithms will be
correct or it won't pass regression test certification.
As I sad just because it uses "AES" or whatever doesn't mean it is
secure, using standard algorithms doesn't equal security as the
implementation is always terrible (and if it isn't terrible there is no
way to tell as you don't have the source)
Crypto exploits are not algorithm hacks they're framework exploits 99%
of the time.
I guarantee those "opal" drives already have exploits for them floating
around the darknet.
(there is also no real way to check that it is actually
working and still working).
Difficult, yes, but not impossible. One link I provided was NIST
tearing one apart for deep inspection of the implementation.
Governments do this all the time. Granted you may not want to go to
that extreme, but other people do. Its just that those deep dives
generally don't get published.
That is impossible, you can't know for sure without the source.
You could pay millions for reverse engineering and still not know for
sure, and of course you would have to pay again every time they release
a new drive or firmware update both of which are a dime a dozen.
On the other hand, one should be able to read the firmware off the
drive and then decode it with IDA Pro to see exactly what the drive
does, if you are that interested. I take it your not that motivated to
prove its not garbage. I get that. I happen to have an natural
curiosity in that way.
TXT is intel marketing,
I plead no contest there. It is however better than doing nothing.
Each technology generally raises the bar a few notches. I would not
bet my life on any one technology. The best solution comes from using
the strengths of each technology to make up for the weaknesses of the
others. Understanding how to layer the strengths is the key to a
secure system. '
Again TXT is simply convenience, and it is pointless as to have it you
require a closed source BIOS - and every TXT laptop also has ME. there
is no "raising the bar" with anything that intel makes.
TXT is intel's marketing name for DRTM, intel's TPM's don't have user
configurable CRTM anyway so the security is questionable.
Serious question: Ok, I am curious, if all these technologies you
mentioned are "garbage", then what do you see as the technological
solution to securing your own systems? Do you have one technology in
mind that someone could not find a way to hack through?
thanks in advance for your response,
Steve.
Uhh you buy a libre native init blob free[1] coreboot system[2], flash
the onboard flash chip with signing keys grub2 loader that loads your
own signed kernels and then you enable write-lock on the chip so that it
cannot be flashed internally.
Problem solved.
What do you need all this security for anyway? (I see .edu maybe you are
a comp-sci student/enthusiast?)
[1] Most "coreboot" systems these days (ex: purism) are not open source,
with them coreboot is simply a wrapper layer that performs not hardware
init everything is done by binary blobs.
[2] There are currently three systems that fit this category which are
available brand new right now.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b7386d59-5de3-5b62-5947-86f336d4126a%40gmx.com.
For more options, visit https://groups.google.com/d/optout.
