[9fans] An interesting article on the challenges chip designers face against secure startup

[9fans] An interesting article on the challenges chip designers face against secure startup

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

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!

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M2cd0d36e0a6b03ca1c3b15a8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[tlaronde]

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-M484bb3312349d42903435fed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]

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.


On Fri, Mar 28, 2025 at 8:06 AM <tlaronde@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-M023cc872fbda4674c9b7178f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5176 bytes --]

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[Skip Tavakkolian]

Isn't that what the TPM is supposed to provide in a verifiable way?

Arm's TrustZone presumably provides layered-isolation to keys and
signatures that can be verified all the way to the manufacturer.   I'm
guessing they might be the basis for TPM hardware implementation.

On Fri, Mar 28, 2025 at 9:56 AM ron minnich <rminnich@gmail.com> 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.
>
>
> On Fri, Mar 28, 2025 at 8:06 AM <tlaronde@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 / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mfcf4c51e9b2d7efd1db76cf8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[tlaronde]

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 <tlaronde@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

-- 
        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-Mc15ac56eb1ee48d971b9e158
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

ron minnich writes:

> 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.

Perhaps it's time to integrate TPM?  That's been in the back of
my mind for a long time, but I have never had suitable hardware
to trying monkeying around with it.  (That might change soon.)

--lyndon

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-M6a78a25b07f9c475d5184c68
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[Frank D. Engel, Jr.]

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, tlaronde@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 <tlaronde@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

Re: [9fans] An interesting article on the challenges chip designers face against secure startup

[Aleksandar Kuktin]

[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]

>On Fri, 28 Mar 2025 12:26:37 -0700
>"Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca> wrote:
>
> ron minnich writes:
> 
> > 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.
> 
> Perhaps it's time to integrate TPM?  That's been in the back of
> my mind for a long time, but I have never had suitable hardware
> to trying monkeying around with it.  (That might change soon.)
> 
> --lyndon

Hi all! A long-time lurker here.

I'd like to point out the problem with TPM is that, since the "trust"
chain originates with the manufacturer, or more accurately with
whomever controls the manufacturer, you'll never be in complete control
of the device. "Trusted computing" in this scenario means "can THEY
trust YOUR computer to serve THEM and work against YOU"? If you can't
change the key (all of them), or if you don't have the private key
(all of them), you simply don't have control over the boot process, and
if you don't have control over the boot process, you simply have no
control over the machine whatsoever. The machine can and will turn
against you when it's true masters order it to.

Then there's the entire thing about "war against general
computing". Etc. This all is generally discussed under the heading
"technofeudalism".

-- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mf2d73ed41ad414db5c2616ad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Host security using TPMs

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

Aleksandar Kuktin writes:

> I'd like to point out the problem with TPM is that, since the "trust"
> chain originates with the manufacturer, or more accurately with
> whomever controls the manufacturer, you'll never be in complete control
> of the device. "Trusted computing" in this scenario means "can THEY
> trust YOUR computer to serve THEM and work against YOU"? If you can't
> change the key (all of them), or if you don't have the private key
> (all of them), you simply don't have control over the boot process

[...]

There's no such thing as perfect security.  Each of us individually
decides what level of security is sufficient for our needs.  For
the purposes of running my Plan 9 network at home, if I could do
host authentication using TPM, that would be sufficiently secure
for my needs, and a *hell* of a lot more secure than the current
scheme.

--lyndon

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Mdb1e33d6715468d3f1891a45
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Host security using TPMs

[Wes Kussmaul]

On 3/28/25 18:04, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Aleksandar Kuktin writes:
> 
>>  ...the "trust"
>> chain originates with the manufacturer, or more accurately with
>> whomever controls the manufacturer, you'll never be in complete control
>> of the device. 
-- 

This such an important and overlooked point.

We partnered with, and invested in, StartCom, a certification authority 
that helped us build our Osmio CA. We chose them because of their 
reputation for integrity: they actually checked out the claims of domain 
owners before signing an x.509 SSL certificate (unlike many others.)

We were minority shareholders, so when the CEO decided to put the 
company up for sale we had no choice but to consent to selling this 
business with a noteworthy integrity asset.

So when a company with a noteworthy asset puts itself up for sale, of 
course it attracts buyers who lack that asset - right? So a Chinese 
company bought StartCom in order to issue fraudulent x.509 certificates.

Fortunately they were quickly caught by members of the CA Forum. All the 
browser makers quickly deleted the StartCom root from their browsers, 
and all of a sudden the users of sites backed by StartCom SSL 
certificates got the ugly go-away-do-not-trust-this-site message.

Certification authorities should be like the vital records departments 
of city hall. You may be able to buy the mayor, but everyone in the 
vital records department knows that their only asset is their integrity. 
You can't buy the vital records department.

The notion of a commercial certification "authority" is pure folly.

And attributing enduring significance to a company's privacy practices 
(hello Apple) is also folly. A big hedge fund or PE might decide there's 
money to be made by buying a controlling interest in Apple and getting 
it to act like the rest of Silibandia, stealing and selling personal 
information for a big boost in earnings and share value.

A company is not a person. Unlike a person's character, which is usually 
enduring, a company's character is created at the whim of its 
controlling shareholder.



*Wes Kussmaul*

*Reliable Identities, Inc.*
an Authenticity Enterprise

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Md91c073022804b38253c4251
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Host security using TPMs

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

Reductio ad absurdum: it all hinges on the rule of law or the whim of a
potentate.

On Sat, Mar 29, 2025, 8:49 AM Wes Kussmaul <wes@reliableid.com> wrote:

>
>
> On 3/28/25 18:04, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Aleksandar Kuktin writes:
> >
> >>  ...the "trust"
> >> chain originates with the manufacturer, or more accurately with
> >> whomever controls the manufacturer, you'll never be in complete control
> >> of the device.
> --
> 
> This such an important and overlooked point.
> 
> We partnered with, and invested in, StartCom, a certification authority
> that helped us build our Osmio CA. We chose them because of their
> reputation for integrity: they actually checked out the claims of domain
> owners before signing an x.509 SSL certificate (unlike many others.)
> 
> We were minority shareholders, so when the CEO decided to put the
> company up for sale we had no choice but to consent to selling this
> business with a noteworthy integrity asset.
> 
> So when a company with a noteworthy asset puts itself up for sale, of
> course it attracts buyers who lack that asset - right? So a Chinese
> company bought StartCom in order to issue fraudulent x.509 certificates.
> 
> Fortunately they were quickly caught by members of the CA Forum. All the
> browser makers quickly deleted the StartCom root from their browsers,
> and all of a sudden the users of sites backed by StartCom SSL
> certificates got the ugly go-away-do-not-trust-this-site message.
> 
> Certification authorities should be like the vital records departments
> of city hall. You may be able to buy the mayor, but everyone in the
> vital records department knows that their only asset is their integrity.
> You can't buy the vital records department.
> 
> The notion of a commercial certification "authority" is pure folly.
> 
> And attributing enduring significance to a company's privacy practices
> (hello Apple) is also folly. A big hedge fund or PE might decide there's
> money to be made by buying a controlling interest in Apple and getting
> it to act like the rest of Silibandia, stealing and selling personal
> information for a big boost in earnings and share value.
> 
> A company is not a person. Unlike a person's character, which is usually
> enduring, a company's character is created at the whim of its
> controlling shareholder.
> 
> *Wes Kussmaul*
> 
> *Reliable Identities, Inc.*
> an Authenticity Enterprise

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Me89e017e4f44e7959b79d809
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4298 bytes --]

Re: [9fans] Host security using TPMs

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 4729 bytes --]

There's a lot of money in this kind of exploit, and that, coupled with the
frequent use of reused keys, makes efforts to discover those keys
productive. I've been given some idea of just how much money goes into this
kind of work, and it's staggering.

And there's stuff like this: “We noticed that the key from an old Zen 1 CPU
was the example key of the NIST SP 800-38B publication (Appendix D.1
2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at least Zen 4
CPUs.” -- used on a successful microcode attack, now people are working to
make AMD cpus be risc-v cpus by changing their microcode. Same key across
millions of CPUs, wow.

And, there is the AST2500, which, if you type a certain string into it,
gives you full access. That string is baked into the chip mask. That string
was protected by an NDA, nothing more. A student found it out as part of a
project. The only fix is to not connect the serial pins ...

Anyway, I mainly wanted to mention the kind of problems there are, and how
much effort gets put into attacks, in case somebody wants to look again at
what to replace nvram with. It is good to skip over all the failed stuff --
although the chip vendors just keep doing the same thing over and over :-)

I like the TPM idea, if done the way Chromebooks do it. It's worked well.
The only guarantee chromebooks ever offered was that they could withstand
5m of physical access, no more, but that's more than most systems can
promise.

Thanks



On Sat, Mar 29, 2025 at 11:46 AM Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> Reductio ad absurdum: it all hinges on the rule of law or the whim of a
> potentate.
>
> On Sat, Mar 29, 2025, 8:49 AM Wes Kussmaul <wes@reliableid.com> wrote:
>
>>
>>
>> On 3/28/25 18:04, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
>> > Aleksandar Kuktin writes:
>> >
>> >>  ...the "trust"
>> >> chain originates with the manufacturer, or more accurately with
>> >> whomever controls the manufacturer, you'll never be in complete control
>> >> of the device.
>> --
>> 
>> This such an important and overlooked point.
>> 
>> We partnered with, and invested in, StartCom, a certification authority
>> that helped us build our Osmio CA. We chose them because of their
>> reputation for integrity: they actually checked out the claims of domain
>> owners before signing an x.509 SSL certificate (unlike many others.)
>> 
>> We were minority shareholders, so when the CEO decided to put the
>> company up for sale we had no choice but to consent to selling this
>> business with a noteworthy integrity asset.
>> 
>> So when a company with a noteworthy asset puts itself up for sale, of
>> course it attracts buyers who lack that asset - right? So a Chinese
>> company bought StartCom in order to issue fraudulent x.509 certificates.
>> 
>> Fortunately they were quickly caught by members of the CA Forum. All the
>> browser makers quickly deleted the StartCom root from their browsers,
>> and all of a sudden the users of sites backed by StartCom SSL
>> certificates got the ugly go-away-do-not-trust-this-site message.
>> 
>> Certification authorities should be like the vital records departments
>> of city hall. You may be able to buy the mayor, but everyone in the
>> vital records department knows that their only asset is their integrity.
>> You can't buy the vital records department.
>> 
>> The notion of a commercial certification "authority" is pure folly.
>> 
>> And attributing enduring significance to a company's privacy practices
>> (hello Apple) is also folly. A big hedge fund or PE might decide there's
>> money to be made by buying a controlling interest in Apple and getting
>> it to act like the rest of Silibandia, stealing and selling personal
>> information for a big boost in earnings and share value.
>> 
>> A company is not a person. Unlike a person's character, which is usually
>> enduring, a company's character is created at the whim of its
>> controlling shareholder.
>> 
>> *Wes Kussmaul*
>> 
>> *Reliable Identities, Inc.*
>> an Authenticity Enterprise
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Me89e017e4f44e7959b79d809>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4aedea377a3d63c1-Mba9c4f64e4edf2ca9e619983
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6513 bytes --]