The City of St. Gallen, Switzerland, has kicked-off a Smart Lighting project which is expected to save up to 65% of power thanks to the implementation of energy-efficient LED luminaires and an advanced remote control system.
Technology partners Paradox Engineering SA and Osram Lighting AG worked with St. Gallen Stadtwerke to design and develop the new infrastructure, now being piloted along Oberstrasse. Nearly 60 SL20 LED luminaires by Osram were installed on the road and connected to Paradox Engineering’s PE Smart Urban Network platform for remote monitoring and control.
This solution allows St. Gallen Stadtwerke to manage the entire streetlight area from a web-based console, switching on/off single or grouped lamps, varying light intensity whenever needed and tracking lamps performance. Customised lighting patterns can also be defined to schedule streetlights operations according to daytime and weekdays.
St Gallen (night view)
Moreover, the lighting system also features an optical sensor that detects traffic intensity and triggers luminaires to automatically dim light up and down upon vehicle transit.
Thank to this feature, light intensity is automatically adapted to traffic volumes, limiting waste of power and emissions when only a few cars and trucks pass by, as typically happens at night. The combination of Osram’s LED luminaires and Paradox Engineering’s network platform increases energy saving up to 65%, if compared with traditional streetlight architectures.
“Using energy and available resources responsibly is very important for an innovative City like St. Gallen. Street lighting has a direct impact on attractiveness of a city, so we were looking for the best possible balance between the need to save energy, emissions and money on one hand, and that to safeguard quality of life and public safety”, said Urs Etter, head of Public Lighting at St. Gallen Stadtwerke.
“We have been investing in LED systems for some years, and we are proud to turn on this dynamic Smart Lighting solution which will further improve our sustainability performance. As we invest for the future of our City, this technology is open to any extension and development we might need – and that’s a great benefit for us”.
PE Smart Urban Network is a natively interoperable platform enabling both Wireless IoT and Wireless Highspeed IoT applications over the same network. It will support the extension of Smart Lighting to Smart City to the entire City of St. Gallen, but also the future integration of other urban services. Easy integration of third party systems is even granted, offering the City the maximum flexibility to evolve at its own pace and without any legacy constraint.
Comment on this article below or via Twitter: @IoTNow OR @jcIoTnow
The post Smart dynamic LED street lights turn on in St. Gallen appeared first on IoT Now – How to run an IoT enabled business.
Read more here:: www.m2mnow.biz/feed/
Techstars, the worldwide network that aims to help entrepreneurs succeed, announced a new partnership with BSH, a global appliance manufacturer.
The partners will bring a new mentorship-driven accelerator programme to Munich, Germany, called BSH Future Home Accelerator Powered by Techstars. Techstars has a long history in Germany, dating back to our first Techstars Startup Weekend in 2010. This is the fifth Techstars Mentorship-driven Accelerator program in Germany, following successful accelerator programs in Berlin.
BSH and Techstars are looking for innovative startup companies from around the globe that will bring pioneering technologies to change the way digital consumers live, cook and do housework, especially in the heart of the future home – the connected kitchen.
The Techstars team with Tibor Kramer, Venture and Accelerator Partner at BSH Home Appliances Corporation
The companies will be supported throughout the Mentorship-driven Accelerator program with educational content and by a team of mentors who bring subject-matter expertise, business connections and access to resources.
BSH is one of the world’s most successful home appliance manufacturers, with global brands like Bosch, Siemens, Gaggenau, and Neff and have established industry leading standards through BSH Home Connect technology. The selected companies will benefit from BSH experience and knowledge, as well as an installed base of more than a million connected home appliances.
Applications for the accelerator open on July 23rd 2018 and the program kicks off in Munich, Germany in February 2019. Startups interested in applying should review the Application Toolkit.
Comment on this article below or via Twitter: @IoTNow OR @jcIoTnow
Read more here:: www.m2mnow.biz/feed/
It’s been nearly two months since the high profile BGP hijack attack against MyEtherwallet, where crypto thieves used BGP leaks to hijack MEW’s name servers, which were on Amazon’s Route53, and inserted their own fake name servers which directed victims to their own fake wallet site, thereby draining some people’s wallets.
It generated a lot of discussion at the time, however, it’s largely died down now, and people are content to carry on with their lives. What isn’t fully appreciated is that attack has, in fact, changed the game somewhat, and this means we all have to reevaluate our assessment of DNSSEC.
Why does DNSSEC factor into a hack that was executed via BGP hijacks? Well here’s the bad news, while it’s debatable how easy it is to execute BGP hijacks, there is no defined security protocol in place to prevent it. Really. Last year easyDNS had some of our own IP space hijacked and it took us about a week to get it straightened out. Thank God it was unused space, but the entire episode had me realize how loose the authentication of routing announcements really is. There’s some talk around implementing RPKI but it’s a long way off, if ever.
That leaves us with DNSSEC as our main line of defence against these attacks, of which there are certainly bound to be more.
Had MyEtherwallet DNSSEC signed its zone, and further, used TLSA pinning for their TLS certs, this attack would have been largely mitigated. Two of the resolver services which picked up the fake IP addresses for MEW were Google Public DNS and Cloudflare’s 18.104.22.168, both DNSSEC aware resolvers which would have instead returned failures instead of fake addresses.
Until now though,
DNSSEC hasn’t really caught on for two reasons:
First, historically speaking, old style DNS poisoning attacks (not using BGP leaks) were theoretically possible but not commonplace. Even without DNSSEC name servers started adding mechanisms like source port randomization and it made it increasingly harder to pull off cache poisoning.
Second, DNSSEC wasn’t easy to implement, and it wasn’t exactly “set-and-forget”. Worse, if you did it wrong like screwed up one of your key rollovers, you would hose your own zone. There is even a website that keeps track of high profile outages stemming from botched DNSSEC rollovers. It includes numerous entire TLD namespaces, the US military and even ISC, opendnssec.org and dnssec-tools.org, organizations that are chief advocates behind DNSSEC. Talk about the cobbler’s children have no shoes!
It’s no surprise then that businesses were reluctant to DNSSEC sign their zones because when they did the calculus, they thought they were more likely to experience a self-inflicted outage via DNSSEC misconfiguration than from having an attacker successfully poison or spoof their zone.
Aside from the difficulty in implementing and maintaining DNSSEC, there are also ideological objections. Those include the ideas that DNSSEC is simply flawed, insecure or doesn’t solve anything because of the centralized nature of DNS’ inverted-tree hierarchy.
A standard bearer for anti-DNSSEC deployment is posting called Against DNSSEC. It raises numerous objections to DNSSEC, some more tenable than others. Not long after, one of our developers, Zach Lym posted a response to it entitled For DNSSEC which rebutted the earlier post point-for-point. Both posts were at some point added to the Wikipedia DNSSEC citations section as embodying the opposite views to the issue.
In my mind the anti-DNSSEC article didn’t age well, considered with this addendum to that post’s mini-FAQ:
“What’s the alternative to DNSSEC?
Do nothing. The DNS does not urgently need to be secured.
All effective security on the Internet assumes that DNS lookups are unsafe. If this bothers people from a design perspective, they should consider all the other protocol interactions in TCP/IP that aren’t secure: BGP4 advertisements, IP source addresses, ARP lookups. Clearly, there is some point in the TCP/IP stack where we must draw a line and say “security and privacy are built above this layer”. The argument against DNSSEC simply says the line should be drawn somewhere higher than the DNS.”
This is bad advice. Because BGP leaks are now a thing (Cloudflare’s 22.214.171.124 was briefly BGP hijacked the morning I typed this), doing nothing is no longer an option. Since RPKI isn’t widespread now and the routing experts I talked to say it may never be able to scale. Since it is a certainty that more high profile, damaging and lucrative BGP hijacks are certain to follow, at this moment DNSSEC is the only game in town to defend against this kind of an attack.
Those who are operating their own ASNs can certainly use something like BGPmon or Artemis, and it’s better to have route monitoring enabled than not, but that’s still a matter of how fast your peers can slam the barn door shut after the horse is away. You want all of your key assets to not resolve to fake values, even for a moment, because there are ways attackers can use that brief window of time to promulgate fake DNS values that will last much much longer than the duration of the attack itself, days, weeks — a year.
Another criticism of DNSSEC is that because it relies on DNS, which is itself an inverted tree with a logically centralized root node, it is a “government or state” security system. Well, sure, in the sense that there exists an internet root and it is overseen by an entity at the discretion of a nation state, that much is true. But as much as I’m into decentralization, zero-knowledge systems, and even ideologically identify as an anarcho-capitalist, there is the practical reality that there is no clear path from where we are now to a fully decentralized anarcho utopia. Even if there is, it’ll be a multi-generational slog to get there.
Eschewing the one defence we have against an attack variant that poses an existential threat to anybody whose livelihood depends on being visible over the Internet today is pretty much tilting at windmills. Even the Ethereum Name Service WG which has been working on deploying ENS enabled domains, both under the Ethereum native .ETH TLD and in legacy DNS integrations like .XYZ went with DNSSEC to authenticate the validity of the ENS integration process.
So what do you do about it?
Easy. You go ahead and sign your zones for DNSSEC. We were already working on a ground-up rewrite of our DNSSEC implementation when this happened (truth be told, I coded the first one and it kinda sucked. It didn’t do anything with your DS records and was pretty shaky with key rollovers. Memo to staff: Don’t let the CEO code anymore.)
When the MEW / Amazon Route53 BGP hijack happened, we went to the mattresses accelerating our rewrite, it was like early days. Sleeping at the office, pizza and coffee at 4am, the works. What we have now, well it’s something else.
Now we have easyDNSSEC™ the world’s first Set-and-Forget DNSSEC™ deployment which fully eliminates the implementation hurdles I outlined above. No more worrying about botched key rollovers or remembering to re-sign the zone after an update, let alone how the hell do you get your DS records into your parent TLD? Just press the button and you’re done. End-to-end DNSSEC in about 1 second.
As always, we’ve pushed the new system live as beta, so start with your non-essential zones. When you enable DNSSEC for your zones you’ll notice your name servers will switch from easydns.* to easydnssec.* hostnames, this is because we’ve also signed those name server hostnames ahead of when we pull the trigger and sign easydns.com for real, which will happen soon.
Other enhanced security measures
Once you’ve decided to take the plunge and DNSSEC sign your zones, there are even more safeguards you can implement to further protect yourself. Some of these measures should have been implemented already anyway, like CAA. Some are not for the novice, and they are similar to the early days of DNSSEC implementations: if you miscalculate or lose track things, you can hose your zone. Still, others won’t work until you sign your zone with DNSSEC (DANE), but if you combine DNSSEC signed zones with the tactics below, you will be fairly well secured against attack vectors which can be launched via BGP leaks:
- Implement CAA records to assert what CA authorities can issue TLS certs for your domain. You should have these in place anyway, since the CA/Browser forum made Certificate Authority Authorization mandatory for all CA’s in 2017.
- Enable HTTP Public Key Pinning (HPKP) to guard against a future compromise of your CA. This one is non-trivial and you could potentially “brick” your website if you lose track of your keys. (HPKP is implemented via HTTP server headers, not in your DNS zone.)
- Publishing TLSA records for your hostnames that are secured via TLS. TLSA records enable, DANE which can be used to issue TLS certificates on your hosts and validate them without using a central CA. Doing so is not yet widely supported in browsers, but here we can also use TLSA to assert what CA’s can issue certificates on our domain and what the validation path should be.
Whether you employ any of the additional tactics above, once you DNSSEC sign your zone, if your upstream DNS provider or the IP space for your website (or any other part of your network) gets hijacked, your DNSSEC validation will break, and those using DNSSEC enabled resolvers will not see any fake sites. An outage is preferable to a spoof at this point.
Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.
Written by Mark Jeftovic, Co-Founder, easyDNS Technlogies Inc.
Follow CircleID on Twitter
Read more here:: feeds.circleid.com/cid_sections/blogs?format=xml
HPE is riding the IoT train.
HPE is riding the IoT train.