An Internet of Trouble lies ahead as root certificates begin to expire en masse, warns security researcher Expiring root certificates will cause devices like smart TVs and refrigerators to fail in the next few years, security researcher Scott Helme has warned. Secure internet connections depend on the server presenting a valid certificate to the client, the most common problem being that the server certificate is out of date, …
Yeah, likely to be way I suspect, but hopefully some good may come of it in the shape of consumer awareness and pressure?
From a 'dumb' consumer perspective, the lack of software updates to things like Android phones and tablets is typically blind - the increased risk to un-patched vulnerabilities does not manifest itself in an meaningful way to most users. However, when services just stop working despite the hardware being perfectly ok, this is likely to cause anger and resentment. Enough anger to change manufacturer's behaviour?
What this could represent is a longer term shift in how consumers think about warranties. Traditionally, once a warranty expires, the lifespan of the product comes down to a mix of how well you look after it and pure luck. Is there a future where products themselves purposely stop working once the warranty expires? Will price differentiation carry Apple indefinitely as their estate of supported models continues to increase? How long do we have until updates as a paid for subscription service become the norm?
> Enough anger to change manufacturer's behaviour?
I'd say "not a chance".
Already some manufacturers (as reported by El Reg) don't hesitate to kill perfectly working kit to force the users to update, and if they aren't afraid to do something as obviously malignant as that, why would they bother about some highly abstract problem which isn't even entirely their own fault? "Sorry, the root certificate has expired" is a perfectly valid explanation, which puts the fault to a faceless, abstract entity which for the end user is as intangible as fate.
I'd say "not a chance".
Already some manufacturers (as reported by El Reg) don't hesitate to kill perfectly working kit to force the users to update, and if they aren't afraid to do something as obviously malignant as that, why would they bother about some highly abstract problem which isn't even entirely their own fault?
Belkin are doing just that with their Wemo NetCams at the end of this month.
https://www.belkin.com/us/support-article?articleNum=316642
There's no use for them after that except maybe as parts. Belkin killed off viewing via other means in a previous firmware update. The original end date was the end of last month which was pretty shitty timing. Given people might be in lockdown and using them for security at workplaces etc that sucks even more. Probably done it now to try and keep the news buried under Covid 19 related news.
Thanks for that link - I've bookmarked it, and every time someone I know expresses interest in some "IoT" cloud product, I'll send it to them.
There is no way that all use of this device should depend on some third party server.. I'm guessing the device connects to their server and you connect to the same server, to avoid NAT/firewall restrictions, but that shouldn't have anything to do with local use - local recording / local control over wifi from the app.
Even the outgoing bit should be configurable in cases like this, so a third party, or somone who knows what they are doing could keep it working. I find it hard to believe that they can justify the hard coding of this, and the intentional bricking of a device.
Belkin have been added to my shit list.
There should be legislation that says if they stopping supporting a device, they are required to open-source the design and software so that the consumer can fix the problem themselves. Yeah, I know in practise most won't but it means that, say, a webcam that has been manufacturer obsoleted will at least have eBay value to someone who can manage to update it. Plus, the threat of having to do this might encourage manufacturers to actually update stuff.
This. IIRC BMW have already tried it for their infotainment systems, and Tesla seem to be doing something sinister when cars are sold on.
Which is why I will never even consider a Tesla, and if BMW really does that they'll be on my shit list too.
So far VW seems to be somewhat reasonable, but I wonder how long that will hold out.
honestly yes many systems use a certification authority and its time to move on to a DNS based system where you can choose your CA (self signed or with a CA) it also nicely describes what legal system ( jurisdiction ) applies, .uk or .de
https://tools.ietf.org/html/rfc7671
easy to deploy today with your existing certificate with usefulness for SMTP and in the future HTTPS
This post has been deleted by its author
https://tools.ietf.org/html/rfc7671
Doesn't this either just move the problem to DNSSEC, so you get the same issue due to https://www.icann.org/resources/pages/ksk-rollover, or (more likely) avoid it only because of absolute trust of wherever you get your DNS answers from? (Genuine question.)
This doesn't change the situation that if a certificate, ticket of key is needed to connect to a central server the item is subject to the whims of the manufacturer in withdrawing support.
All this does is further highlight the utter stupidity of all this "SMART" crap that is being churned out in the name of progress.
Whilst I would love to be able to use DANE, browser support is missing not because they haven't added support yet but because browser vendors have independently and for different reasons actively chosen not to support it.
Without going in to all of the discussions on the issues with DANE in browsers, the problem we're meant to be talking about is the process of replacing root signing keys. DNSSEC has done this exactly once, which was delayed by 12 months due to the need to update client software. The amount of manual effort that went in means the theoretical automated key roll process is still pretty much untested and confidence that next time will work flawlessly is not great.
The procedure for rolling the DNSSEC root key involves signing a new key with the old one and publishing in advance so clients can install the new key before it goes live. Once the new key is in production and everything is running smoothly they will then use the new key to sign a revocation of the old key, which again is published for a short period to let clients know to remove it. Once the rollover period is complete the root zone returns to being simply a normal zone signed with a normal key with no record that the old key ever even existed.
The problem with rolling DNSSEC keys in this way is that even if everything works as smoothly and perfectly as it is theoretically designed to, those devices that were on a warehouse shelf during the rollover are now being shipped to customers with old keys and no way of securely updating them...
Any attempt to get around this problem will likely either involve a new set of keys to sign the current root key (which needs all of the same problems to be solved for it!) or devices going and automatically installing completely unsigned keys sourced from the very network it doesn't trust in the first place... Might as well just disable validation, or save yourself the bulky TLS library and stick to plain old HTTP!
> "... devices that were on a warehouse shelf during the rollover are now being shipped to customers with old keys and no way of securely updating them..."
But in that case the failure should be detected within the product warranty period so a full refund should be obtainable. In most cases, the burden of keeping warehouse products up to date would fall to the suppliers rather than the end user. There would still be a problem if the end user for some reason kept the product off-line for a year and missed the rollover.
One could argue that this problem is purely accidental because products are pushed out in the name of consumerism. On the other hand, consumerism has the dark side of planned obsolescence. The cynic may argue that the problem of "not updated" or "non updateable" gadgets is a long term plan to get sales up and going.
We'll have to see if this all is stupidity or malice. Significant amounts of stupidity do look a lot like malice. Maybe I'm too much of a cynic to trust the gadget pushers...
manufacturer doesn't care about device after 2 years, tops (and that only because EU forced them to care for so much)
couple that with humans being very bad at handling future threats (just look at our handling of global warming—a civilisation as we know it ending event) and you have this result
That's often true but not completely fair. I've certainly had products where the manufacturer has continued to provide updates for a lot longer than 2 years.
In the case of a friend of mine, he's got a fairly antique TomTom sat nav (yes! An actual, real sat nav device and not a smart phone like the rest of the world), which stopped working last year (or was it the year before? In forget!) when there was a GPS patch required. They provided and for free as well which was a pretty decent on a very old unit.
With consumer goods I think a lot of the UK based offices keep a veritable museum of old devices because 'manufacturing defect' type clams coming in under the UK sale of goods act which allows consumers to claim for repair or replacement within 6 years of purchase. A 5 year old TV which dies due to an expired root CA could be argued to have a defect by not being shipped with trust in a suitably long CA and that could lead them to either release an update to fix or even to provide a replacement device.
Tom-Tom, another evil company.
The older satnavs did indeed get a fix for the GPS week-rollover bug. However, that was delivered as part of the "sayonara, no more updates for you" message in the PC application.
If you have an old copy of TomTom Home, it forcibly updates itself to the latest version, that removes all of the features except the firmware updater.
No more map updates for your "lifetime" subscription.
All this, allegedly, is because the SD card the device comes with (2Gb) is not big enough for the latest maps. Bigger ones are, of course, cheap as chips nowadays, but no. They have used it as an excuse to dump their old products.
So, no more TomTom products for me!
Indeed, an expired CA authority certificate should fall under the UK and EU warranty laws for at least 5 years from date of purchase.
But will breaking iPlayer or Prime Video on a smart tv amount to a defect?
It sure would be nice to have laws that stipulate a minimum period of security updates too.
Or open-source the firmware after x years so people can update it themselves.
"yes! An actual, real sat nav device and not a smart phone like the rest of the world"
Lots of people have proper satnavs. Having a single device trying to do multiple critical functions at the same time usually ends up with one of the functions taking over at the wrong time and can be far more distracting on the road than having separate things doing separate jobs. One device to rule all the apps is ok for occasional use, but not on a day to day, constant use pattern.
I'm sure that's true but this friend is the only person I know who still uses a dedicated device in a car which doesn't already have a built-in sat nav (which is becoming increasingly common and probably yet another load of proprietary devices to become bricks when the manufacturer can't be bothered any more).
I totally get the idea of a single device sometimes being better than a multifunction one but then I'm a bit of a cheap skate so I'm not going to buy a dedicated nav device when I've already got a smart phone which does incredibly good navigation worldwide with live traffic/hazard and roadworks updates on accurate maps (although I must say I'm very impressed with TomTom's lane diagrams at junctions, which Waze/Google Maps don't do).
In the early days of having a smartphone all kinds of things went wrong when using it for navigation but these days it will happily play my music/podcasts whilst navigating and integrates well with my aftermarket Bluetooth kit for road alerts and phone calls
So for me to buy another device for maybe £200 (which is more than my phone cost) plus extra costs for updates and international maps just isn't an attractive option. Especially as it's another thing I'll need to hide or take with me at the end of each journey in case some little weasel decides to smash a window and pinch it.. I generally don't forget the phone - it's either in my pocket or it's mounted in the car.
So to each their own for now but I think the massive increase in smart phone use combined with all the new built-in solutions will eventually mean that dedicated units cease to exist
Most of the in-car sat nav devices built into cars are obsolete and out of date by the time the car leaves the production line. These are rarely, if ever, even given map updates leading to the almost humorour situation of being told to take the 2rd exit at the next roundabout in 50 yards while driving down a dual carriageway at 70 mph.
I can see you might need encryption to preserve the privacy of the user's choice of viewing, but you can do that without a certificate.
The domain name the iPlayer app connects to must be hardwired into the app itself, so presumably the certificate is acting as some form of identity check that the domain name hasn't been redirected somewhere else. But given that the iPlayer app has been provided by the BBC itself (or under its licence), you could perform the same check within the app without resorting to an external PKI service.
So is the PKI there to perform some other function, or is it just being used because the code is there already so it's easier than finding a domain-specific solution?
I used to work on this stuff (TV streaming) and my overriding opinion of it was (and still is) that the majority of the complexity in this regard stems from broadcasters having an inflated opinion of the value of the content the produce. ITV player is probably the best example of this - the complexity involved in streaming an advert, breaking off to show a bit of a program (eg emerdale or corri) and then going back to an advert (sarcastic? Me!?) is bonkers complicated. I can’t remember now, but it involves something like 2 or 4 certificate servers, plus the actual content streaming servers (one for the adverts and one for the program) and the chain of stuff that has to happen for it all to work is nuts!
And all this complexity is mostly because ITV don’t realise (or don’t want to admit) that todays emerdale/corri is tomorrow’s virtual chip paper (when did you last see a thriving black market in corri episodes? Nope. Me neither).
There are other issues too, of course. Maybe some of it stems from the idea that people would use their “smart” TVs to do their shopping etc etc. Of course nobody does because it doesn’t work very well compared to using a laptop, or even a phone.
And being able to download updates needs the device to trust the source (oh the irony!)
Oh, and Of course there is the matter of a lack of forward thinking :-)
the complexity involved in streaming an advert
Ironically, the need to insert ad breaks and overlay region specific (STV or ITV) DOGs actually makes is easier to grab stuff: once you intercept the RTMP stream you get the full uninterrupted programme - no ad breaks and no branding. Or rather, you could if you were so inclined...
The most pressing reason for using certificates from the end user's perspective is that many of the services accessed from the connected kit require logins and if you don't verify that the service you're sending credentials to is the right one, someone steals your login. For an example of what goes wrong when the certificates aren't validated, see this 2015 story.
Samsung made an internet-connected fridge. Yes, it's one of the dumber ideas ever, but apparently some people want email notifications while they're cooking. The fridge didn't bother to validate server SSL certificates, which made it possible to mount a man-in-the-middle attack. Since the fridge had access to email accounts to give email notifications, this allowed stealing of email credentials.
As someone has pointed out, once the certificate expires, you are in a hard place. If you don't verify the server certificate when you download a new firmware package, you have to assume that you've just installed malware on your customer's LAN. If the certificate fails verification, you really really ought to refuse to install the firmware update. In the case where your root certificate has expired, this leaves you in a place where you can't install the update that would fix the problem. In some cases, it will be possible for end-users to download and install an update. In other cases, the bit of kit is effectively bricked because either there is no feasible way for an end-user to install an update or because the average end-user is as likely to figure out the process as they are to grow antennae on their foreheads.
In the case of a browser, it doesn't know, a priori, what it is likely to be connecting to and a third party attestation is useful.
However, iPlayer (or whatever) knows exactly what it should be connecting to and the third party attestation offers nothing over what iPlayer could check for itself. At its most trivial, the app could contain the necessary certificate chain rather than rely on the one provided by the underlying system and an update to the app could update the necessary certificates.
Of course you have the slightly circular problem that if the app store certificates expire, you can't update the apps, but that's a problem the third party service provider doesn't have to work around itself.
I'm assuming the issue is that the APIs for some of these "smart" TV systems are in fact pretty minimal and don't offer you much beyond "render this URL as an H.264 video stream".
"However, iPlayer (or whatever) knows exactly what it should be connecting to and the third party attestation offers nothing over what iPlayer could check for itself. At its most trivial, the app could contain the necessary certificate chain rather than rely on the one provided by the underlying system and an update to the app could update the necessary certificates."
Not necessarily. What if the IP attached to the DNS entry changes? Or the DNS entry itself changes for whatever reason? Suppose the device has to jump through a proxy or two such that the entry it sees isn't the actual entry? And as long as we're in this department, consider Men-In-The-Middle (including sanctioned ones like secure proxies). It's the classic error: never assume what you think is permanent is actually permanent.
But the problem is fundamental: in some way or other, the client needs to verify that the server it's sending credentials to is actually the server it meant to send those credentials to and not some other server that's stealing those credentials.
There are all sorts of ways that that verification could be done and PKI certificates are only one of them; but they are a good choice for it precisely because they have a chain of trust with differing expiry intervals. The root certificate, which allows you to verify servers, expires rarely and the security precautions around it are extreme; the server certificate expires often but that doesn't matter because the client doesn't need to be updated when the server certificate is updated.
Anything you can suggest to replace that is almost certain to be worse.
So is the PKI there to perform some other function, or is it just being used because the code is there already so it's easier than finding a domain-specific solution?
Just because it's easier doesn't mean it's a bad thing: as with encryption, using existing code is generally a good thing for authenticating a server.
To answer your question in the title: I think the obvious answer is that certificates are intentionally providing a time limit to the trust, because eventually, the private key matching the public key in the root certificate will be discovered.
Say you wish to avoid PKI. On the face of it, embedding (say) an RSA public key in the client and validating signatures would work fine. But there would need to be some mechanism to periodically change the key, because eventually the private key will be discovered.
I think this could work safely through a chain (key0 used to sign key1, key1 used to sign key2 etc), but only if that chain is unbroken, which can't be guaranteed unless you trust key0 forever, which is a bad idea because eventually the private key will be discovered.
I can't see a way out of this...
I believe the OP is suggesting that there is no need for the iPlayer (or similar) chain of trust to go outside the BBC.
iPlayer can ship with Public Key A. It connects to Auntie, does the usual handshake using that key, all is well.
At intervals, Auntie gives iPlayer a new public key B, which it checks and installs locally, replacing the old key. It's safe, because the client has already decided to trust that server and has a well-encrypted link. Repeat until bored.
The only difference is that there's no root cert. So it works as long as the first connection is within the expiry date of the initial download or pre-installation, and it's run often enough.
For bonus points you could do things having like multiple valid keys, expiring each a year or two apart so a given client can't expire two keys at once.
The exact validity periods needed will depend on how long TVs spend on warehouse shelves or otherwise disconnected, but I'm sure there's good stats for that.
iPlayer can ship with Public Key A
I think you're describing the same thing as I was trying to. I called it key0.
So it works as long as the first connection is within the expiry date of the initial download or pre-installation, and it's run often enough.
The same is true if you use certificates from a public CA, and embed the roots in the client with a way to update them (provided that's done in time).
It's the expiry that makes it functionally similar, even though the detail is different. The benefit you describe comes down to having control over expiry. You could equally get this with certificates by using a private CA, without the wheel reinvention: you just need to be able to specify which CA certificate you trust and have a way to update that certificate.
The point is that there is no actual need for a chain, because the only key that matters is the one actually used today.
There is a need to ensure the local copy isn't replaced by $bad_actor, however that problem exists for a "root cert" in a chain of trust too and so the solution for one is the solution for both.
There will be a lot of people with some very expensive kit that has borked itself because of this issue. They will sue, sue and sue until they get a solution.
A lot of companies are walking blind into this mess. Some really don't give a F**k. They have your money and good luck trying to get any support.
If this gets bad enough the Politicians (who it seems are mostly Lawyers or PPE grads these days) will get involved which will only make things worse.
An awful lot of this kit is never connected to the interwebs so I'd like someone to explain why it needs security certificates in the first place.
OTOH, this is a disaster by design and as other comments have said this is all to get you to buy more stuff which will more than likely have even an even shorter lifespan before the same thing happens again.
>Any kit which isn't connected to the interwebs will presumably just carry on working as it is already, so there shouldn't be an issue in that situation?
Depends, Windows for example doesn't like running code with an expired certificate or running signed code that doesn't have a relevant root certificate in its store; so suspect much depends on what the kit does with certificates.
Personally, as use my TV in monitor/dumb-mode, with the Xbox handling all the smart functions, I'm hoping this won't be a problem. However, given services like Amazon Prime actually check and use HDCP, it would not surprise me if this has some form of certificate dependency and so people suddenly find their large 4K screens can only display stuff at SD (ie. DVD quality, not HD/Blueray quality) or worse get an HDCP error preventing content being displayed...
Not quite.
Windows will only complain if the software's signing date is after the cert expiry.
If the cert used expired in 2019 but the software was signed in 2018, it's still considered fine to install in 2020.
I'm not sure whether that applies to the root certs though, as I've not seen docs about that or had an opportunity to try it.
They will sue, sue and sue until they get a solution
Sale of Goods and Services Act (or whatever it's replacement is called this week) is your friend here. There is an automatic assumed warranty of "reasonable durability" - where "reasonable" is not defined in law, but would be considered on a case by case basis in court. Taking something simple to understand such as a pan for the kitchen - if you buy a pan for 50p off the market, then you can't reasonably expect a lot of durability from it; but if you splash out on something expensive (such as those heavy and expensive cast iron things from Le Creuset) then you could reasonably expect the handle not to drop off after a few months.
The key things is that in law there is no time limit to claim for faults which could reasonably be assumed to exist at time of manufacturer - though the statute of limitations constrains you to 6 years (5 years in Scotland). A certificate expiring and bricking a device is a built in fault - absolutely no wiggle room out of that one.
The claim is against the retailer, not the manufacturer - so as long as the retailer is still in business there is someone to claim against. I would imagine that if the likes of Dixons Group (owners of Currys & PC World) or Asda or Tesco, or ... turns round to manufacturers and basically said "you're carp has cost us £XM in claims - compensate us or never sell another product though us ever again" then there's enough clout to get the attention of the beancounters in even the biggest manufacturers.
But that relies on consumers realising what's gone on and actually claiming rather than just adding to landfill and buying more tat.
> But that relies on consumers realising what's gone on and actually claiming rather than just adding to landfill and buying more tat.
Indeed, and History has shown most people will just grumble a little, then go buy a replacement, of the same brand. Some will even be happy for the opportunity to get the newest and shiniest...
...."you're carp has cost us £XM in claims - compensate us or never sell another product though us ever again"....
Nope. Doesn't work like that. Not in todays upside down world of retail, it's more like ...
"Do as we say or we'll never let you sell another one of our products again"...
"[...] so as long as the retailer is still in business there is someone to claim against."
In the UK if you bought it on your credit card (over GBP100) and the supplier goes bust - then the credit card company is liable. It worked for me many years ago when an early CD writer didn't meet the published spec. The supplier folded during the dispute - and Barclaycard refunded the purchase price.
I suspect that would work to a degree but how about Amazon?
This needs to be across the board otherwise all that will happen is that those retailers with more interest in customer service will end up with nothing to sell.
Just sending a replacement does not necessarily help if it has the same certificates.
Unfortunately, a service being terminated is not the same thing in law as lack of durability. If the buttons fall off or the glued in battery dies ahead of time that's actionable, but there's no warranty relating to continued provision of support services or even "spare parts" beyond the statutory minimum consumer guarantee period (which includes the option of replacement with an "equivalent" in lieu of repair).
But this is about the equipment "failing" because a part of it has stopped working. IN this case I think it's a "slam dunk" case as our US friends might call it.
Has the equipment ceased to function - either in whole or part ? Yes
Is that due to a fault ? Yes, it's because a certificate has expired and so the equipment can't make secure connections.
Was that fault present, or could it reasonably be believed to be present, at the time of sale ? Yes, the certificate was part of the software, and it would have been obvious to anyone that it would expire on [some date].
So unless the retailer can that at least one of those statements is not true then they are liable and will lose in court. But since all three of those would be a given for the issue being described, they don't stand a chance. It's a completely different situation to the likes of Revolv where the equipment still "functions", but can't do something because an external service has stopped.
But that's a different (though related) debate - there needs to be some guarantee over provision of such services for at least a set time.
Why do we need encrypted/ssl connections to stream media ? I can turn a TV on and get it down an aerial and it is not encrypted, indeed everybody can snoop and see the traffic if they want.
What's the difference with streaming media, none. They could stream it over port 80 and it would still be more secure than the airwaves.
It's all down to DRM and them wanting to monetise the pap they produce.
Conveniently disguised planned obsolesence.
You might be thinking of the EPG data, which has some compression applied and the huffman tables needed to "decode" it are protected by the BBC. They use this to strong arm the equipment manufacturers into implementing their desired DRM methods
It doesn't stop someone with a generic DVB-T2 receiver from capturing the video/audio transport streams - these are not encrypted
TV on and get it down an aerial and it is not encrypted, indeed everybody can snoop and see the traffic if they want.
Third parties cannot see what you are watching in that case. Or see traffic from you back to the source.
Both of which happen when using a streaming service.
"Third parties cannot see what you are watching in that case. Or see traffic from you back to the source.
Both of which happen when using a streaming service."
Isn't a common "feature" of "Smart TVs" their ability to capture partial image data of whatever broadcast you're watching, so it can be phoned home and analysed in minute detail...
I can understand closed devices like IPcams and such, but can't you install certificates in Android? Wouldn't that be a potential way to work around the issue of certificate expiry?
Hmm, yes. Never used it but "Lock screen and security" -> "Other security settings" -> "Credential storage" looks to be the place.
> but there's a restriction in that you have to have lock screen security turned on.
And will get a permanent notification in your notification bar saying something along the lines of "network communications may be being monitored".
A long standing issue that Google, frankly, couldn't give two short fucks about - https://issuetracker.google.com/issues/36984301
If you're going to install additional certs on Android, the only real solution is to root the device
A lot of IoT devices are built around the ESP8266 which, while having libraries that support HTTPS, doesn't have enough RAM to be cast iron reliable in every situation. It's been one of the things that's stopped me attempting to build any serious prototypical hardware that could be turned into a production run - you've got to ensure your software uses the bare minimum of RAM and that your encrypted HTTP requests and responses don't exceed a certain size, or the stack and the heap collide. So you're left with the difficult choice of not supporting HTTPS comms at all (not good PR), or spending a huge amount of time optimising to death and validating the reliability of your code.
I'm certain a lot of IoT devices will simply cease working if they rely on an embedded copy of a root certificate for HTTPS support.
This makes Zigbee look more and more like a smart choice for IoT devices because expiring root certs isn't an issue in the end device (I'm coming more and more to the conclusion that all IoT devices should be as simple as humanly possible). Mind you reducing price of the ESP32, which has considerably more memory, will encourage manufacturers to switch. The Pi Zero is a better bet for hobbyists though.
And I am perfectly happy with the no-year update cycle on my very dumb and perfectly functional fridge, thank you.
As much as I can eventually understand the interest of a "smart" TV, I'm sorry but a fridge is never going to have the capability of automatically checking what is stored in it, so I fail to see the point.
And RFID is not going to tell me if the milk jug is half empty or almost full.
It's all a bloody waste of time and money.
"[...] a fridge is never going to have the capability of automatically checking what is stored in it, [...]"
I remember the days when supermarkets had to put a sticky price label on every packet and tin - to be transcribed by the checkout assistant on the till keys. Then came standardised bar codes on every product so they could be scanned. The cheap RFID tag idea is not quite universal yet - but potentially offers instant scanning of your full trolley.
IIRC there are now packages that contain "freshness" indicators for perishable items.
The intelligent fridge needs packaging innovations and standardisation - at a low cost per item. It will come.
Or just open the door and see what is in the fridge
This obsession with tech is the cause of so much of the waste we produce. Food waste is simply horrific because of a date, best before, sell by, display until etc.
Millions of tons of perfectly good food are binned because people are seemingly unable to assess that it is still okay. Some things are more susceptible or dangerous than others, meats and fish for instance but for heavens sake, just give it s sniff.
Millions of bits of tech are binned, mostly because there is a new, better, faster flashier model out, not because they are physically worn out.
Rant over.
"The intelligent fridge needs packaging innovations and standardisation - at a low cost per item. It will come."
It also needs to have built in scales on each shelf and door space otherwise it only knows you took a milk bottle out then put the same/another one back in. It won't know whether you had a splash of milk in your tea or just made a 1/2pt milk shake. Or how many slices of bacon you took out of the pack. And I'm not sure every local butchers or farm shop is going to be putting those tags onto each manually weighed out package. What you are suggesting could only work if every food item comes in a standardised, sealed supermarket package.
OR each package has some way to determine how full it is. Take the milk jug. Suppose the RFID tag includes a means to detect how full it is (say by using a conductive strip to detect the fluid level, there ARE ways to electrically detect fluid levels, and they don't necessarily require a lot of power to do given unplugged coffee urns and such).
I suspect with enough motivation, they can find some ways...
And people called me a luddite for buying a decent large-ish screen monitor with built-in speakers rather than a smart-TV. I don't even connect it to a 'smart-box' as I have a Freesat box for the live TV and if it is not available there then I can watch on my laptop. I have yet to hear a good reason to connect my white goods to the internet (or connect my lightbulbs/doorbell/thermostat/toilet)
OK...maybe the toilet was not a real option.....yet
It has long been recognised that the toilet has health diagnostics potential. IIRC the German toilet bowl had/has a little shelf for inspection before flushing.
Faecal matter is a diagnostic for various cancers etc. Currently a home test is merely a manual collection of a smear onto a doped window that can be "read" later in a lab. Dogs have been trained to sniff out characteristic scents of some conditions. The electronic artificial nose is the Holy Grail of many industries.
My diabetes flash glucose monitor is a "patch" on my upper arm. It can be read with a smartphone NFC and the results stored in the cloud for my doctor to look at when needed.
It is not just Covid-19 that is pushing the health services to remote diagnostics.
doorbell
When a visitor approaches my closed door they trigger an infrared beam. An Arduino box of tricks sends a chime signal to bell units throughout the house and garden. It repeats twice - just in case the first one didn't register on your consciousness "Is that the post?".
If the wired doorbell is pressed - then the Arduino sends a different chime signal to all the bell units - and repeats it five times or until you open the door.
Those units are currently on 433mHz.
There is another beam on the drive entrance that is only used to activate Halloween and Xmas decorations - the Arduino unit also governing diurnal curfews. The signals used for this were originally 433mHz - but it is now transitioning to wifi to control AC power points. The devices' intranet is a dedicated router isolated from the house PC intranet/internet.
Too bad we can't post pix (yet??) here on El Reg, I read this story earlier in the afternoon, and after that I had to help a user with a different issue, but there it was plain as day a microsoft domain complaining of a cert gone out of style! Gladly it was on a citrix session to some other poor sap's network, and not my worry!
Yes, provided you're prepared for your smart fridge to make a few assumptions thereafter for your safety...
ERROR41: This pork chop is from a pig whose grandmother hasn't been born yet. Temporal violation on bottom shelf. Discarding.
ERROR42: Waitrose Lemon & Herb Chicken on middle shelf may not be safe to eat due to thyme dilation effect.
NOTIFICATION: The carton of milk buried out of sight at the far back of top shelf was purchased last week and is fresh. Enjoy your Millennium Eve party!
I know, I know, it's "expired". But the public key hasn't changed and the cert is still useful for its purpose. Expirations are a made-up problem, sadly used to solve a real problem - non-functional CRLs. Can they please just fix the underlying issue so a cert can live until someone "expires" it??? Oh wait - then GoDaddy, DigiCert, Verisign, et al won't be able to keep reducing cert validity periods and keep charging outrageous sums for zero-effort renewals. Never mind.
Unfortunately if the only solution is CRLs and not certificate expiry dates then as time goes by the CRL will become so large that it will cease to be viable. Therefore expiry dates are a fair solution to things.
As for the cert providers "valuable" service in doing not very much other than processing invoices... yep. It's infuriating the price gouging that went on and is still largely going on.
The code written on them won't, as it's usually written by the typical modern developer who has no clue about security, accessibility or anything long term let alone error handling. However the devices themselves, and the libraries built into them, do try to apply the correct checks. Of course, baking an HTTPS stack into firmware has disadvantages if done badly or when standards change, therefore there will always be churn for this reason if nothing else.
At one point, a certificate inside a Java .JAR file, associated with APC UPS software expired.
Except, we didn't know that. All we knew was that every server suddenly went to 100% CPU, couldn't log in, couldn't do safe mode, couldn't do anything in terms of diagnosis on the machine itself. And when you looked at the data, everything matched recent backups, including the software JAR file that hadn't changed in years. Even if you restored from a known-good backup, same problem as soon as the clock updated (but, again, you wouldn't know that, it would just work for a minute and then go mad). Literally took down a network without any visible signature and no way to diagnose a live system.
It was only by one of those word-of-mouth fixes that it was determined that if you kill off the APC UPS software by deleting the entire folder, and then restart, the machines would operate as normal.
Eventually APC pushed an update, but it literally took out several networks that I was working on, and many colleague's networks. Obviously one of them noticed that the ones not on an APC UPS or using its monitoring agents to shut themselves down were unaffected, and spread the word.
Then the root cause analysis was a certificate inside a JAR expiring, causing the APC software to throw a paddy and bring the servers to their knees (for whatever reason). APC issued an update with the new certificate and a reinstall of it worked, but first you had to take down every affected machine, manually delete the APC software, then boot and reinstall.
I expect much the same problem in dozens, if not hundreds, of pieces of software when old root certificates start to expire, and they'll be the embedded ones as well as the server.
With our current What Me Worry? POTUS who prefers to ignore facts and any thing bad happening under his watch other than race hate, this will surely come to pass while our government will pretend it is not or at the most marginalize it and do everything they can to obscure the facts. He and his Citizens United backers could give a crap about any problems other than how much money they can wring out of the system.
In Frank Herbert's Dune complex electronics are outlawed. You can have a simple electric device but the sorts of problems we are having with certificates and hackers would be impossible. Why does your fridge need to connect to the Internet? Why does the video player need to encrypt video?
When we explained to our parent company that we wanted a root certificate valid for 25 years, they laughed at us. They were used to generating IT cerificates, and the idea that a piece of OT equipment may be around for longer than 3 years and maybe only connected to every 5 or 6 years were totally alien to them.
n the end we became our own CA, which may of been less secure, was acceptable for our use cases (and also got around the issue that our devices do not have DNS names so browsers tended to hate them )
Sectigo AddTrust External CA Root certificate expired on May 30, 2020. They sort of assumed that only 'modern' browsers visited web sites and forgot about everything else that may use SSL.
Sectigo was established as a seperate operating company from Commodo in 2017 at which time they added an ADD TRUST certificate to their certificate chain at this time with a 3 year expiry.
It doesn't appear to have been communicated that it would be best to reissue your certificates before the 30th May to ensure full compatibility nor (more obviously) ensure the root expired after customers certificates. Ours still had 3 or 4 months left.
It just meant reissuing and reinstalling SSL certificates. Obviously there was quite a lot of head scratching, getting certs and bouncing services to fix everything.
Surprised it took the reg so long to notice.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
