Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

White House unveils Cyber Trust Mark program for consumer devices

nextgov.com

Post reply on HN
Print view View original

91–100 of 164 posts

Re: White House unveils Cyber Trust Mark program for consumer devices

#91

Post by kube-system »

rkagerer wrote: post #56
kube-system wrote: post #32

Earlier quoted context omitted.

You might be getting a bit too far ahead of where the industry is at with some of those wishlist items. NIST's requirements are things that are best practices that everyone agrees with, like: * data stored/transmitted is secured by some kind of means * the device supports software updates * the device requires users to authenticate * the device has documentation * you can report security vulnerabilities to the develo…

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which…

Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device.

> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').

Quite a lot -- these are some of the easiest devices to hack. The only saving grace is that most of them are not connected to the internet so they are only vulnerable to local attacks. But garage doors, cordless phones, keyless entry, smart locks, smart home protocols, etc are notoriously vulnerable.

The reason you don't hear about new vulnerabilities each week is precisely because they're aren't updatable. The fact that they don't get updates with new vulnerabilities is not an advantage when they permanently have older vulnerabilities.

Re: White House unveils Cyber Trust Mark program for consumer devices

#92

Post by cesarb »

amaterasu wrote: post #66
ngneer wrote: post #65

Who are these UL Solutions? They seem to have come out of nowhere and hit the jackpot, inserting themselves as arbiters for security. Smells a bit like how Common Criteria proffered independent certification labs, which were no panacea either.

Underwriters Laboratories, UL. Look at the back of pretty much any mains powered device and you'll see their mark. They were founded 130 years ago, and test and warrant devices (typically high voltage) to be safe. Security is a new thing for them, but they're well suited to provide the services.

> Underwriters Laboratories, UL. Look at the back of pretty much any mains powered device and you'll see their mark.

I just looked at the closest mains powered device I have here (a fancy humidifier/fan), and only saw an Inmetro mark, there's no UL mark at all.

(My point is: plenty of people are not from the USA. I happen to have already heard that the UL is sort of the USA equivalent of our Inmetro, though like many things in the USA it's a private entity instead of a government entity, but the parent poster probably hadn't heard of that.)

Re: White House unveils Cyber Trust Mark program for consumer devices

#93

Post by lcnPylGDnU4H9OF »

dylan604 wrote: post #84
ok123456 wrote: post #78

Earlier quoted context omitted.

Can we add that it's self-repairable domestically?

What could we do to make something self-repairable domestically that would also make it not repairable otherwise? Like if you bought it here, but then took it with you internationally, would it suddenly not be repairable?

Curious if it would be possible for a manufacturer could do similar hardware attestation as what's done for iPhones while allowing for the hardware and its attestation key to be swapped for a different set only if one has a certain private encryption key.

I don't do hardware at all so this may be infeasible or misunderstood but I imagine a scheme whereby one needs the encryption key in order to properly change the key that the hardware attestation firmware is expecting. The attestation key is encrypted with a separate private key and is decrypted by the firmware with the corresponding public key.

Presuming that's feasible, it would only really work until that private key is leaked and our hostile trade partners pinky promise not to use it. Perhaps some licensing could be used to make the people who own the device to be responsible for repairing it at an approved repair shop but that still has to be enforced.

Re: White House unveils Cyber Trust Mark program for consumer devices

#94

Post by kube-system »

ocdtrekkie wrote: post #87
wpm wrote: post #86

Earlier quoted context omitted.

Local RF? What protocol? Proprietary?

It's proprietary but relatively easy to reverse engineer, the details are out there. In the US it uses like 914.5 MHz or something, and I can send instructions to devices with an extremely simple serial protocol on my computer. No Bluetooth, no Wi-Fi, no protocol sophisticated enough to distribute code. Just locally transmitted instructions.

Do they require auth and use solid crypto? If not, they are vulnerable, it's just that the vulnerability requires the attacker to be within range.

People thought old analog 900mhz cordless phones were fine until others realized you could just tune a radio to that freq and listen to your neighbors.

Re: White House unveils Cyber Trust Mark program for consumer devices

#95

Post by hn_throwaway_99 »

rkagerer wrote: post #56
kube-system wrote: post #32

Earlier quoted context omitted.

You might be getting a bit too far ahead of where the industry is at with some of those wishlist items. NIST's requirements are things that are best practices that everyone agrees with, like: * data stored/transmitted is secured by some kind of means * the device supports software updates * the device requires users to authenticate * the device has documentation * you can report security vulnerabilities to the develo…

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which…

> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').

Tons and tons? I don't understand this viewpoint at all. As the saying goes "There is no 'Internet of Things', just an Internet of unpatched Linux devices." That is, the primary vector for malware is devices that aren't (or can't) be patched after vulnerabilities are discovered.

Re: White House unveils Cyber Trust Mark program for consumer devices

#96

Post by kube-system »

timewizard wrote: post #58
kube-system wrote: post #38

Earlier quoted context omitted.

NIST isn't a bunch of dummies that don't know this. The requirements posed are not micromanagement of device design; some address your concern exactly... like a requirement that developers provide contact information to report vulnerabilities and that devices makers just can't ignore authentication entirely. But this is IoT stuff we're talking about here, not Lenovo/Cisco... but ReoLink/PETLIBRO/eufy/roborock/FOSCAM/…

> NIST isn't a bunch of dummies that don't know this They've provided thorough definitions and a label that implies they've all been understood by the manufacturer. It doesn't mean that this solves any real world problem. > Security (or the lack of it) in the IoT world is a whole different ball game. Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics" and often have…

> Those can be described as IoT devices. They're more appropriately categorized as "consumer electronics"

IoT devices are a subset of a much broader 'consumer electronics' category.

> and often have a firmware update right out of the box.

From major, established, mature companies, yes. Many device manufacturers in this category never issue firmware updates. Which is precisely why this is one of the requirements.

> This segment is not going to care.

Some may, some may not. The federal government will care, because they will be forced by law to comply.

> no third party testing can be exhaustive enough to prevent the obvious exploit from occurring.

Of course, no cybersecurity compliance plan can prevent exploits from occurring. If you try to address cybersecurity in that way, you will fail, anyway. The point is to place controls in place which are achievable, measurable, and help to mitigate risk.

> Even to the extent they can it then enforces a product design which cannot be upgraded or modified by the user under any circumstances.

NIST's requirements require the opposite of this.

Re: White House unveils Cyber Trust Mark program for consumer devices

#97

Post by nyrikki »

rkagerer wrote: post #56
kube-system wrote: post #32

Earlier quoted context omitted.

You might be getting a bit too far ahead of where the industry is at with some of those wishlist items. NIST's requirements are things that are best practices that everyone agrees with, like: * data stored/transmitted is secured by some kind of means * the device supports software updates * the device requires users to authenticate * the device has documentation * you can report security vulnerabilities to the develo…

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which…

You don't need access to persistent storage, especially with multi-entry executables like busybox, which are often similar to built in rootkits today.

I actually just spent time last week getting rid of tftpd, telnetd, netcat etc... on some IP cameras last week.

You only need a few k of ram to have a bot, especially with how it is almost the rule that embedded system run everything as root.

If you have the ability to do firmware extraction, look at just how bad the industry is now.

Re: White House unveils Cyber Trust Mark program for consumer devices

#98

Post by kube-system »

TeMPOraL wrote: post #69
kube-system wrote: post #32

Earlier quoted context omitted.

You might be getting a bit too far ahead of where the industry is at with some of those wishlist items. NIST's requirements are things that are best practices that everyone agrees with, like: * data stored/transmitted is secured by some kind of means * the device supports software updates * the device requires users to authenticate * the device has documentation * you can report security vulnerabilities to the develo…

The software update angle has already been commented on, but I'm not sure this one is a good idea either: > the device requires users to authenticate

No, it is a good idea. If someone is operating or changing settings on your baby monitor, doorbell camera, garage door opener, smart switch, light bulb, etc -- the developer should check to make sure that the actor doing so is authorized to do it.

Why in the world would anyone want unauthenticated access to these devices?

Re: White House unveils Cyber Trust Mark program for consumer devices

#99

Post by kube-system »

moritonal wrote: post #71
rkagerer wrote: post #56

Earlier quoted context omitted.

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which…

An interesting thought is how when devices couldn't auto-update, they had to work out the gate. I imagine this encouraged companies to do much better testing to reach a gold-plate before deploying.

This is true, but mostly only relevant to the expected user functionality. User acceptance testing in waterfall development doesn't often identify security vulnerabilities.

Re: White House unveils Cyber Trust Mark program for consumer devices

#100

Post by ndriscoll »

kube-system wrote: post #98
TeMPOraL wrote: post #69

Earlier quoted context omitted.

The software update angle has already been commented on, but I'm not sure this one is a good idea either: > the device requires users to authenticate

No, it is a good idea. If someone is operating or changing settings on your baby monitor, doorbell camera, garage door opener, smart switch, light bulb, etc -- the developer should check to make sure that the actor doing so is authorized to do it. Why in the world would anyone want unauthenticated access to these devices?

All of those things might have a authentication-free use-case for e.g. a babysitter (maybe not to change settings, but to use). For personal networks, being on your local LAN is in practice a decent form of authentication given the tradeoffs of otherwise having to manage credentials.
Post reply on HN