[HN Gopher] Exploiting Undocumented Hardware Blocks in the LPC55S69
___________________________________________________________________
Exploiting Undocumented Hardware Blocks in the LPC55S69
Author : smklein
Score : 49 points
Date : 2021-04-30 16:19 UTC (6 hours ago)
(HTM) web link (oxide.computer)
(TXT) w3m dump (oxide.computer)
| myself248 wrote:
| The response from NXP is just incredible. Heck of a job their
| "certified security test labs" are doing, if this has just been
| sitting out there for years waiting for some curious end-users to
| find it.
|
| What's the point of those certified labs, then? To think inside
| the box and tell their client only what they want to hear?
| ohazi wrote:
| The test lab industry is a grift. They just sell "LGTM"
| stickers for $30k a pop.
|
| NXP and every other chip company are all just (correctly?)
| expecting that they will end up needing to do fewer respins by
| keeping the door to the closet where they keep their skeletons
| shut.
|
| The problem is that NXP and their direct customers only care
| about exposure to _liability_ for their products being insecure
| crap. It 's the end users who actually suffer when their
| security tokens and HSMs are defeatable by anyone with some
| reversing skills and a few months to spare.
|
| I don't know anyone who genuinely believes that the "secure
| microcontrollers" available today are even remotely secure. All
| chip companies act like this. You'd think that _one_ of them
| would be motivated to release a line of chips with an open boot
| rom and all of the "oops bits" documented and just let the
| public have at it. Sure, they'd have to do a few respins, but
| by the time they were done, they'd completely own the market of
| products that genuinely need real security and not just rubber
| stamp security.
| hlandau wrote:
| Beyond closed ROMs, it's even worse when entire lines of
| chips are locked behind NDAs.
|
| It's always irked me you could never get programmable
| smartcards, except via a VM like Java or BASIC. The reason
| for this AIUI was that smartcard chips tended to consist of
| an 8051 plus a large customer-specified mask ROM, and very
| little flash. Except nowadays this is no longer the case, and
| platforms like ST's ST32 have ARM SC000 cores and, AIUI, are
| all-flash based. Except they may as well not exist for my
| purposes since they're entirely NDAware. Non-VM user-
| programmable smartcards exist, you just can't have them.
|
| I suspect that part of this is antiquated attitudes and/or a
| refusal to accept Kerchhoff's principle by NXP, and that part
| of it is a similar attitude held by its customers, the
| organisations that buy smartcards. NXP's comments here as
| regards the LPC5S69 almost seem to insinuate something like
| "We don't rely on security by obscurity ourselves, but some
| of our customers have outmoded ideas about security and would
| complain if we opened things."
| bsder wrote:
| > I suspect that part of this is antiquated attitudes
| and/or a refusal to accept Kerchhoff's principle by NXP
|
| That is attributing far too much agency to the players
| involved.
|
| The real issue is much simpler: "We don't want to be
| bothered supporting anyone who isn't throwing around enough
| money that we're willing to actually do the design for
| them."
| elcritch wrote:
| It's really unfortunate that hardware vendors are obsessed with
| shipping closed source firmware and ROM. Fortunately there's been
| a slow and steady buildup of pressure as open source has started
| being pushed lower into the stacks. Great to see Oxide Computers
| pushing on this. The rest of the NXP software stack is pretty
| open.
|
| Overall the LPC55S69 chips are pretty impressive chips! They have
| dual cores with plenty of 16 bit ADC's and 16 bit DAC's built in,
| which is amazing. With good platform support from Arduino,
| Zephyr, etc it means you can get high quality signals in a single
| chip, and have two cores to process the data (one for real time
| data, the other for communications and controls).
| kosma wrote:
| I am the author of the STM32F1 FPB security bypass exploit.
| Seeing this happen again, with another manufacturer, but this
| time with undocumented silicon, is just appalling. They will
| never learn. At least NXP replied to the email... I never got a
| reply from ST.
___________________________________________________________________
(page generated 2021-04-30 23:01 UTC)