Most current asymmetric cryptography (public key) is vulnerable to
various forms of attacks from quantum computers of a threshold size, not
yet achieved but potentially feasible to see happen in the
not-too-distant future.
Symmetric ciphers (ex. AES, twofish) are generally more resistant.
As to knowing who as physical access, that goes out the window if your
laptop or cell phone gets stolen. Secure boot / encryption is more
about protecting devices to the greatest extent possible when you lose
physical control over them.
On 3/28/25 14:06, tlaro...@kergis.com wrote:
On Fri, Mar 28, 2025 at 09:20:44AM -0700, ron minnich wrote:
The relevance to plan 9: we have this thing we've used for about 30y now,
known to many of us as sdE0/nvram.
IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea
being you had some bit of NVRAM on your system, hard to get to, which was a
good place to stash a key.
X86 has always had the battery-backed CMOS memory, and it's always been too
small to hold anything useful, certainly not big enough for NVRAM, so I
always assumed that is why we ended up with sdE0/nvram. [Although, note, on
the LANL supercomputers, we did use a few bytes of CMOS to remember a
node's location on the source-routed Myrinet: not totally useless :-)]
Creating a 512B partition on persistent storage to hold a secret key is, I
guess, what you do when you are on systems without a decent place to put
it. It never struck me as safe.
I figure that at some point somebody is going to come in and show us a
better way to do it. Should that happen, it's good to be aware of just how
real the threats are. So I thought it would be nice to know, and possibly
interesting as well.
My point, that was not clear I admit, is that I think that more than
90% of the threats come from the manufacturers and the vendors of the
devices or the software, so that focusing on reducing the 10% left to
0.0001% or less is forgetting that this leaves the 90% intact.
In the same order of ideas, I believe that present cryptography is
indeed hard to break digitally but I'm convinced that it can be
broken analogically---so that everybody uses digital cryptography that
_almost_ nobody can break, but that one or two entities can and that
they would be embarrassed if different not digital means were used.
As long as somebody has physical access to the device (I guess this
was the case for tampering with voltage)...
One has to know exactly who has access. As long as the physical
access is under control (for both the human beings and the material
they bring with them), is there really a problem? The problem seems
more the hype around a "100% trustworthy device" for RPI.
On Fri, Mar 28, 2025 at 8:06?AM <tlaro...@kergis.com> wrote:
On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote:
search for: keysight rp2350 hardware attacks
(I'm done including links :-)
Short form: it's getting easier by the day to put together glitching
hardware, for under $1000, and uncover those keys!
[From the PR departement] This demonstrates once more:
- That security relies first on simplicity (despite the
conclusion, there is a mention about software too, i.e. compilers:
"Due to an unlucky arrangement of instructions emitted by the
compiler, injecting a fault which skips one out of two very specific
instructions confuses the chip into rebooting to the hazardous boot
type".);
- That security has a cost and to maintain efficiency,
strong security has to be done only once, and that it would
be more secure for a task, verified, to execute once on a dedicated
core than having to verify it at each running slot of time, having
verified too that it had not been altered while sleeping and that the
context on the core or the caches have not been "polluted" by a
concurrent task.
On the obvious side---it will probably not be a scoop to a lot of
people---, I discovered, while working on the driver for the
RTL 8125 and al. NICs, that there are instructions to allow
to turn off the blinking led showing that there are network exchanges...
All in all, trusting something that one doesn't build entirely (from
hardware to software)---it may exhibit then errors but from involuntary
faults---is, at best, naivety.
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M8c4b99bd55d8720b5e5e56b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
