MacInTouch Amazon link...

Internet of Things (IoT) security issues

Channels
Security, Products, News


I'm experiencing something similar today, working on IoT products. One chip I'm working with (Nordic Semiconductors nRF52811) has an ARM processor running at 64MHz, with 24K RAM and 192K flash. There is no operating system worth speaking of - just a library of useful functions you can link against your app. There isn't even a file system - the flash is just an image of your application's compiled code and resources, mapped into the processor's address space alongside the RAM. You can actually develop quite a lot on such a chip, but you are forced to write very efficient optimized code in order to make it fit.
What kind of security can you implement in such a system? That's one of the big questions I've been seeing about IoT products. Apparently most of the 'things' already out there have little or no security, and many cannot be updated. I'm not working in the IoT field, but I did spend a while looking at security issues for a possible article and could not find enough solid information to write a solid article.
 


What kind of security can you implement in such a system? That's one of the big questions I've been seeing about IoT products. Apparently most of the 'things' already out there have little or no security, and many cannot be updated. I'm not working in the IoT field, but I did spend a while looking at security issues for a possible article and could not find enough solid information to write a solid article.
Well, first off, this chip has no Wi-Fi. All connectivity is Bluetooth and 802.15.4 (and related) protocols. So any Internet access has to be through a gateway device, a router with matching interface or a mobile phone with a connected app.

Regarding software installation, there are two mechanisms. If you use a JTAG interface (basically a few pins hard-wired to the chip, attached to the development kit's USB port), you can install anything. But in a shipping product, you would probably not connect those pins to anything, so they are only an avenue for attack if someone cracks open the case and attaches an interface to the chip's pins.

DFU (device firmware upgrade) can be done over wireless (Bluetooth or 802.15.4) or over UART (basically a serial port). In order to do that, you need to use a bootloader. The chip has RSA and AES encryption hardware and the bootloader library in ROM (where the DFU code resides) makes it extremely easy to compile an RSA public key into your bootloader. With such a bootloader installed, the DFU procedure will reject any image (application, "SoftDevice" protocol stack or replacement bootloader) that isn't signed with the matching private key.

In other words, if you set up a secure bootloader, then the only way to install unauthorized software (or remove the security from the bootloader) requires you to either hack the hardware (to expose the JTAG interface) or get the private key needed to sign images. Either of these is typically a "game over" scenario for any security model.

Of course, you still need to guard your app against buffer overruns and the usual kinds of errors.

Some IoT SoCs (not the Nordic nrf52 series, unfortunately) also include a system of OTP (one-time-programmable) memory, sometimes known as "soft fuses". With these, you can lock-down a board so that the installed public key can never be replaced regardless of authorization and credentials. Some will also have OTP registers to physically disable JTAG, debugging and access to the installed public key, making it harder to hack your way past the security. Some also allow you install an AES key alongside the RSA public key in the OTP memory so you can encrypt your application images, to protect them from prying eyes.

I've seen these technologies in Qualcomm's QCA4020 SoC and Cypress Semiconductor's PSoC 6 products.

If you're looking for documentation for your research, all three of these manufacturers make their docs available on-line. Nordic's and Cypress's are available to download. Qualcomm requires you to have a Qualcomm developer account, but it is free - approval usually takes less than a day in the US.

There are many other IoT SoCs out there and I'm sure they have differing levels of security support, but these (Nordic, Qualcomm and Cypress) are the ones I currently know something about.
 


IoT creates really challenging security issues. I've heard about a family of products from a company called UniFi that can be used in home to create separate and secure WiFi networks. Does anyone have experience with them?
 


IoT creates really challenging security issues. I've heard about a family of products from a company called UniFi that can be used in home to create separate and secure WiFi networks. Does anyone have experience with them?
My experience with this is with respect to the parent company, Ubiquiti Networks, and with UniFi as one of their product lines, aimed at wireless networking and very, very satisfactorily deployed at four of the companies with which I'm associated. The product line has delivered in some of the more challenging wifi environments that we've faced, including warehouse, manufacturing shop floor, and multi-building campus layouts.

As is increasingly the case, there's no direct web access to the devices, but instead a proprietary controller and interface. It does help that the controller can be on purchased proprietary hardware or the controller software can be installed on off-the-shelf computers and is fairly platform-agnostic. Frequent enough firmware updates, active community, good documentation available.

I actually have UniFi networking equipment in use at home, just to take advantage of some of the monitoring capability, even though I actually use Eero equipment for my wifi (and a couple of AirPort Express units for the audio tie-in, as well as a couple of Time Capsules for Time Machine backup).
 


IoT creates really challenging security issues. I've heard about a family of products from a company called UniFi that can be used in home to create separate and secure WiFi networks. Does anyone have experience with them?
UniFi is actually just a brand name of products produced by Ubiquiti Networks, the latter perhaps being more familiar to many. They have been around for a while now, and I have recommended their UniFi access points to several, due to the project needs. Not sure I would consider them for home use, as they might be a bit of overkill, but for small organizations on up, they are worth considering, and they seem to have a solid reputation.
 


(A little humor...)
I get it. A zillion apps and devices for choosing music, setting your thermostat, adjusting the "mood" of your lighting, playing games, summoning a car, searching the web, etc. Few actually involve productivity.

What I want is a real productivity app:
"Alexa! Weed my yard!"
For that, I might even give up all my email addresses.

(Monsanto should invent an IoT "Roomba" device for weeding gardens, hardscapes, etc. The company would reap an enormous, global army of support from homeowners and businesses which they could use in their battle over Round-Up.)
 



UniFi is actually just a brand name of products produced by Ubiquiti Networks, the latter perhaps being more familiar to many. They have been around for a while now, and I have recommended their UniFi access points to several, due to the project needs. Not sure I would consider them for home use, as they might be a bit of overkill, but for small organizations on up, they are worth considering, and they seem to have a solid reputation.
I have a new construction project and expect a lot of IoT/home automation in the house, especially over time. My goal is to separate my internal WiFi/LAN data network from all the IoT and both from a guest WiFi network. I also want to be able to connect securely from outside the house to access IoT for some things and the LAN for others, maybe by setting up a couple of VPNs to secure the connections. UniFi offers very powerful WiFi access point devices and strong router/gateway/security capabilities. I'd just like to know if anyone else has worked with this stuff before and has an opinion on whether it's worth the expense and effort.
 



My goal is to separate my internal WiFi/LAN data network from all the IoT and both from a guest WiFi network. I also want to be able to connect securely from outside the house to access IoT for some things and the LAN for others, maybe by setting up a couple of VPNs to secure the connections. I'd just like to know if anyone else has worked with this stuff before and has an opinion on whether it's worth the expense and effort.
This is exactly my setup. I have a Ubiquiti router and 5 access points (connected by gigabit ethernet, so I haven't tested the mesh capability) - very fast and reliable wifi everywhere in a 3-story house, in spite of a very large number of interfering networks in the neighborhood.

I have 3 SSIDs active - one for the family, one for guests, and one for IoT devices. None of the networks can talk to any of the others, but all can access the internet. I'm just above the basic level of networking sophistication, and I could do much, much more with some study.

I originally set this up with an EdgeRouter but switched to a Security Gateway, which was much easier to configure. All the devices are configured through a single application that runs on a Mac (it is a Java application, so very portable).

On my list now is setting up a VPN to a new vacation home — doesn't look hard, but I have not done it yet. Overall very happy.
 


IoT creates really challenging security issues. I've heard about a family of products from a company called UniFi that can be used in home to create separate and secure WiFi networks. Does anyone have experience with them?
Generically, a number of vendors (e.g., Ubiquity, Peplink) provide support for isolating questionable devices on separate VLANs that cannot cross over into your cozy home networks. The basic idea: Have one or more separate SSIDs for your IoT devices, isolate them (using absolute or internal firewall isolation) by tying these SSIDs to specific VLANs that have no (or internal firewall-limited) access to the rest of your network, and you can sleep reasonably well at night while your thermostat is being invaded by evil packets.

It works well, and at consumer prices.
 




This is exactly my setup. I have a Ubiquiti router and 5 access points (connected by gigabit ethernet, so I haven't tested the mesh capability) - very fast and reliable wifi everywhere in a 3-story house, in spite of a very large number of interfering networks in the neighborhood.
I have 3 SSIDs active - one for the family, one for guests, and one for IoT devices. None of the networks can talk to any of the others, but all can access the internet. I'm just above the basic level of networking sophistication, and I could do much, much more with some study.
I originally set this up with an EdgeRouter but switched to a Security Gateway, which was much easier to configure. All the devices are configured through a single application that runs on a Mac (it is a Java application, so very portable).
On my list now is setting up a VPN to a new vacation home — doesn't look hard, but I have not done it yet. Overall very happy.
Not to be nosy, but how did you deal with mobile phone app access to LoT devices? That is, a Nest thermostrat requires that your mobile device, say iPhone, be on the same network as the Nest thermostrat to be able to control it.
 



Not to be nosy, but how did you deal with mobile phone app access to LoT devices? That is, a Nest thermostrat requires that your mobile device, say iPhone, be on the same network as the Nest thermostrat to be able to control it.
Nest does not require you to be on the same network. I have had a Nest for many years, and the iPhone app works great outside of my house. I use it in the winter, when out of town/state, to turn on my heat half a day before coming home, to allow the house to warm up.
 


Not to be nosy, but how did you deal with mobile phone app access to LoT devices? That is, a Nest thermostrat requires that your mobile device, say iPhone, be on the same network as the Nest thermostrat to be able to control it.
Maybe not Nest, but there are other IoT devices that should be isolated from your internal network, but that still need to be able to talk to other devices. At work we ran into this issue with our Airtame devices, which are wireless HDMI receivers for conference room TVs. Using their app, any laptop on the same network can broadcast their screen wirelessly to the TV. That's great, but since most guest networks isolate devices from each other, it wouldn't work on the guest network for visiting presenters. With a Cisco/Meraki wifi network, but no VLANs, we simply couldn't find a way to make it work except on the internal network. The same is true for the Sonos speaker system. That really should be on the guest network, along with everyone's phones, but then you can't use it. Then of course there's printers which you may want to give guests access to.

So the thing to do in a home situation may not be to set up an actual "guest" network, but to simply set up separate networks with different access rights/restrictions (call it guest or whatever you like). I know that sounds like the same thing, but it seems that by default a guest network only allows traffic to and from the internet and nothing else. It may be easier to take an open network and lock it down rather than to take a guest network and try to open it up, because there could be some baked-in restrictions. Having a device that's accessible by both a guest and internal network, is going to be difficult without really digging into the configurations and possibly setting up your own VLANs.
 


One popular model for IoT devices is for them to maintain a connection to a cloud service (I assume Nest uses Google's cloud; AWS and Microsoft Azure are also very popular). When you remotely access your device, your mobile app connects to the cloud service, which maintains a "shadow" of the device's state (e.g. via AWS Device Shadow Service).

The device may keep an always-on connection to the cloud service (if power and connectivity is in abundance), or it may periodically connect, in order to sync state, and remain disconnected the rest of the time (typically, for battery-powered devices or those on cellular networks).

It also provides a security benefit, that your IoT device doesn't need you to open a port in your firewall. In order to hack the device, you need to hack (or hijack) the cloud service it is using, which can be pretty difficult, especially for major cloud providers if your devices are kept up to date with the provider's latest security patches.

Of course, this model doesn't work if you need to communicate directly with your IoT device (e.g. JJakucyk's wireless HDMI receivers) or if you want your IoT devices to communicate directly with each other, bypassing the cloud.
 


When our USB-connected Epson inkjet stopped working this spring, we bought an HP OfficeJet 5200, which insisted on a connection to our WiFi and to HP servers. Thanks to HP, the printer's default admin username can't be changed, but we did set a secure password and disabled the printer's embedded web server. Still, as convenient as WiFi printing is, should we worry about IoT and intrusion? We never leave the printer on, but check out Dan Goodin's report on ArsTechnica:
Microsoft catches Russian state hackers using IoT devices to breach networks
Hackers working for the Russian government have been using printers, video decoders, and other so-called Internet-of-things devices as a beachhead to penetrate targeted computer networks, Microsoft officials warned on Monday.

“These devices became points of ingress from which the actor established a presence on the network and continued looking for further access,” officials with the Microsoft Threat Intelligence Center wrote in a post. “Once the actor had successfully established access to the network, a simple network scan to look for other insecure devices allowed them to discover and move across the network in search of higher-privileged accounts that would grant access to higher-value data.”
 


When our USB-connected Epson inkjet stopped working this spring, we bought an HP OfficeJet 5200, which insisted on a connection to our WiFi and to HP servers.
Yuck. I just looked at that model's user guide [PDF], and it has no Ethernet port! All access is via USB (which means only the connected computer, unless that computer is configured for printer sharing) or Wi-Fi.

For what it's worth, the printers I use at home and at work are all connected to their respective LANs via wired Ethernet. Printing via Wi-Fi is available via the network's base station, just like everything else on the network.

Regarding security, there are two possible ways for printers to support Wi-Fi printing. One is for the printer to join your LAN (you provide the SSID and password). At this point, anyone on the LAN can access it. If an attacker breaks into your LAN, he can access the printer, but that's no different from a non-wireless printer. An attacker that doesn't have access to the LAN won't have access to the printer.

The other mechanism is for the printer to establish itself as its own Wi-Fi access point, either instead of, or in addition to, joining your LAN. This is what HP calls "Wi-Fi Direct" (page 88 of the user manual for your OfficeJet 5200).

You sometimes see devices like this when you're looking for a Wi-Fi LAN to join and see SSIDs that are printer brand/models. Anyone who knows (or has hacked) the printer's password (assuming one is even configured) can print, which means an attacker can use it to spew junk faxes at you. And if there is a security hole in the printer's firmware, an attacker can use it to access your LAN (assuming, of course, that the printer is also on your LAN, either via Wi-Fi or Ethernet).

I would recommend disabling Wi-Fi Direct. If you do, then anyone trying to access the printer will have to join your LAN through some other means (e.g. knowing your router's SSID and password), which should close that particular attack vector.

Alternatively, if you really need Wi-Fi Direct for some reason, configure the printer to not join your Wi-Fi LAN. Then there won't be any way to tunnel from the printer to your LAN, the downside being that all printing will have to be via Wi-Fi Direct or a direct USB connection.
 


... Regarding security, there are two possible ways for printers to support Wi-Fi printing. One is for the printer to join your LAN (you provide the SSID and password). At this point, anyone on the LAN can access it. If an attacker breaks into your LAN, he can access the printer, but that's no different from a non-wireless printer. An attacker that doesn't have access to the LAN won't have access to the printer....
Attackers already have access to our LANs in many cases — the "firewall" effect of Network Address Translation (NAT) only applies to IPv4. IPv6 traffic may be directly routed to your LAN, making "an attacker breaks into your LAN" moot.

Thus every device must be configured with sufficiently secure credentials, including unique passwords for every IoT device, such as cameras, printers, doorbell buttons, and the like.

An interim solution for IoT is to configure only IPv4 addresses and disable IPv6. This will work for a few years, but IPv4-only devices and networks are steadily becoming more rare.

A firewall appliance between your LAN and the Internet can provide additional protection — some newer routers can provide this, but they are not widely deployed as yet. And anyway, many successful malware infections come from evil sites often suggested by phishing emails. No firewall can save you from these.
 


IPv6 traffic may be directly routed to your LAN, making "an attacker breaks into your LAN" moot
Thanks, James! One of the suggested "clicks" to make a Synology NAS more secure is to disable IPv6. I did that, not knowing why, just assuming IPv6 merely enabled a magnitude of increased IP addresses. You've explained the why. Now I'm wondering what the difference is that allows IPv6 traffic through the NAT router, directly to the LAN?
 


Ric Ford

MacInTouch
Here's some information about IPv6 configuration options for AirPort devices and also configurable at System Preferences > Network > Advanced > TCP/IP > Configure IPv6:
Super User said:
What are the differences between the IPv6 options in AirPort Utility?
  • Link-local only: Only create a link-local fe80::/64 address via StateLess Address AutoConfiguration (SLAAC). Link-local addresses are not publicly routable. This is the IPv6 equivalent of IPv4's 169.254/16 link-local addresses. The base station will be reachable via IPv6 only from other devices on the data-link networks (wired and wireless Ethernet) directly connected to the base station. It will not act as an IPv6 router or gateway for any other devices. This is the closest you can get to "IPv6 Off" on an AirPort base station, because the AirPort Utility relies on IPv6 link-local as a last resort for connecting to a local base station even if there is an IPv4 subnet mismatch (IPv6 link-local was engineered with a concept of interface-scoped link-local addresses so that it can be active on all interfaces of all devices at all times and never suffer from subnet mismatches and other connectivity problems that IPv4, even IPv4 link-local, suffered from).
    Use this option if you don't want your base station to be reachable from the IPv6 Internet.
Turning on Apple's firewall (and/or using a third-party firewall) might be wise.
macOS User Guide said:
Change Firewall preferences on Mac

Use the Firewall pane of Security & Privacy preferences to turn on the firewall in macOS to prevent unwanted connections from the Internet or other networks....
 


Thanks, James! One of the suggested "clicks" to make a Synology NAS more secure is to disable IPv6. I did that, not knowing why, just assuming IPv6 merely enabled a magnitude of increased IP addresses. You've explained the why. Now I'm wondering what the difference is that allows IPv6 traffic through the NAT router, directly to the LAN?
Short Answer

The devices on your LAN use globally unrouteable RFC 1918 IPv4 addresses. No data addressed to these addresses should ever be received by your router and should be rejected if it is. However, the devices on your LAN may use one or more globally routable IPv6 addresses, which are routable on the Internet. Data for these will arrive at your router and will be automatically forwarded to the LAN.

Long Answer, Wandering into Security Implications

The notable difference between IPv4 and IPv6 is the size of the address used to identify the end point of a connection — sort of like a telephone numbers adding area codes and country codes to allow direct dialing without requiring a phone operator. The increase in address size allows for orders of magnitude more devices to connect directly to the Internet. Here is a quite simplified explanation of the situation:

IPv4
For various technical reasons, there are less than 2^32 IPv4 addresses available in the whole Internet, not enough for all the existing devices. So your Internet Service Provider (ISP) typically assigns only a single address to your Customer Premises Equipment (CPE, we just call it a router). In this context, Network Address Translation (NAT) uses additional connection data (port number) to route data arriving at the assigned global WAN address to local LAN addresses and ports. Address mappings are set up automatically by outgoing connections like web access. Incoming data lacking a matching port number does not reach your LAN. This is the 'firewall' effect of NAT, but none of this prevents you from requesting a download of malware, so NAT is not really an effective security firewall.

IPv6
IPv6 has the potential ability to address more than 3 billion end-points. This removes the requirement for NAT as the world moves all end systems to IPv6. Your ISP assigns a unique global IPv6 address for your CPE (router) and a block of global IPv6 addresses (by address prefix) for use on your LAN. This allows every device on your LAN to have one or more IPv6 addresses which are directly reachable from anywhere on the Internet having IPv6 connectivity. Your local router automatically forwards data with locally-used global IPv6 addresses to devices on your LAN.

Security Implications
  • Every end-point system — desktop, laptop, router, printer, camera, doorbell button, etc. — must be configured as securely as possible.
  • Turning off IPv6 on NAS or other devices is an interim solution to prevent unwanted external IPv6 access. This assumes dependence on the NAT 'firewall' effect and requires continuing to support IPv4 in clients of NAS, etc.
  • Configuring IPv6 Unique Local Addresses (ULA) on NAS, printers, and the like makes them unreachable from the Internet, as your router will not forward traffic addressed to a ULA from your ISP (ULAs are by definition unrouteable on the Internet).
  • Ultimately, security is the responsibility of every end system and user. Use of robust and unique authentication for every login and application connection, and keeping up with security updates, are the fundamental first steps. There are lots of other steps, but that is not the primary topic for this post.
 


Long Answer, Wandering into Security Implications...
Nice post by James R Cutler! A quick comment about IPv6 on local nets: various Apple services, like Bonjour and AirDrop, use IPv6 for at least some of their functionality, and IPv6 may be required for basic functionality on non-Apple devices. It can be very tricky to configure devices correctly for both security and functionality.

For example, I'm fairly proficient in network design and protocols, but I still spent the better part of a day troubleshooting why a new printer only was available when connecting to a LAN via 2.4 GHz but not 5 GHz, while other printers were available via both, even after I realized that it was an issue with IPv6 configuration. The manufacturer's tech support was absolutely useless, so I spent a lot of time searching the Net and methodically adjusting and recording settings until I reached a solution.

My point here is not to get into specific examples but simply to point out that device manufacturers often do not make it easy to understand the impact of IPv6 on functionality or to customize device configurations easily. We may be in for a bumpy road as the IPv6 transition continues.
 


Attackers already have access to our LANs in many cases — the "firewall" effect of Network Address Translation (NAT) only applies to IPv4. IPv6 traffic may be directly routed to your LAN, making "an attacker breaks into your LAN" moot.
While true, this is exaggerating the danger just a bit.

When you have an IPv4 network without a firewall, you have a relatively small pool of addresses - typically 8 or 16. Even if you've been around long enough to have been assigned a Class B address, that's still only 64K addresses, so someone can quickly port-scan every address in the block until something hits.

With IPv6, however, you are typically assigned a 64-bit address block. And devices that generate their own addresses in this block use a randomization algorithm. So an attacker that just starts at PREFIX:00:00:00:00:00:00:00:01 and works up is going to be scanning for a long time before hitting something.

Of course, if the attacker knows a valid IP address (e.g. because you originated traffic from it), that's a different story. But that still won't be enough to quickly find a device that isn't making outbound connections to the attacker's network (like your printer, most likely).

In other words, although good security and firewalls are necessary with IPv6, the odds of a random script kiddie finding your devices is much lower than with a non-firewalled IPv4 LAN.

Also worth noting is that, even with a firewall, use of IPv6 can create privacy concerns, because your address is not translated. It can be used to track your usage and (depending on how your address is created) could even track you when you roam across different networks.

If this interests you, you may want to look at these IETF documents:
  • RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
  • RFC 7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms
 



I found this article on IPV6 security, FWIW:
APNIC Blog said:
Common misconceptions about IPv6 security

Misconceptions can be dangerous. This is especially true when they lead to network insecurity.

In this post I’ll seek to set the record straight for several of the most common misconceptions about IPv6 security.

IPv6 is more/less secure than IPv4
There are two big misconceptions about IPv6 security:
  • IPv6 is more secure than IPv4
  • IPv6 is less secure than IPv4
Neither [is] true. Both assume that comparing IPv6 security with IPv4 security is meaningful. It is not.
 



Here's some information about IPv6 configuration options for AirPort devices and also configurable at System Preferences > Network > Advanced > TCP/IP > Configure IPv6:
Turning on Apple's firewall (and/or using a third-party firewall) might be wise.
I immediately tried this on my Time Capsule (5th-gen tower). The configuration update failed the first time, requiring a physical restart. The IPv6 option hadn't changed. Second time worked as expected. I will watch out for are any unanticipated consquences. Thanks for this tip.
 


Not to pick the nit too much, but isn't that 3 billion too small by a few quadrillion? IPV4 has 4.something billion...
Yup, I messed up that number. 2^128 is 340,282,366,920,938,463,463,374,607,431,768,211,456. The current IPv6 recommendation allows for assignments from 2^125 possible addresses but assigned as prefixes (address blocks) from 2^61 possible blocks of 2^64 addresses. 2^61 is 2,305,843,009,213,693,952. However you describe these numbers, they are big. And the current assignments are currently assigned from 1/8 of the total possible addresses.

Someday, in a century or so, we might have to add an "area code" to IP addresses like, sol, mercurius, huo3-xing1, terra, luna, venus, saisei, kronos, and the like. But the users will simply enter something like mars^www.apple.com, and data will be routed between planet/moon/star networks by name and leave the final address lookup to the "local" DNS. And this will be required more for traffic reduction than for address considerations.
 


Someday, in a century or so, we might have to add an "area code" to IP addresses like, sol, mercurius, huo3-xing1, terra, luna, venus, saisei, kronos, and the like. But the users will simply enter something like mars^www.apple.com, and data will be routed between planet/moon/star networks by name and leave the final address lookup to the "local" DNS. And this will be required more for traffic reduction than for address considerations.
“Hey, with IPv8, we should be able to address every galaxy in the universe.”
― Dennis E. Taylor, We Are Legion
 


“Hey, with IPv8, we should be able to address every galaxy in the universe.”
Well, there are apparently "only" 1011 galaxies in the universe or so, but as each galaxy has lots of stars, there could be 1023 stars. And let's add another factor of 10 or so for planets. Now we are talking a big address space! (Oh, and I forgot about the multiverse....)
 


Well, there are apparently "only" 1011 galaxies in the universe or so, but as each galaxy has lots of stars, there could be 1023 stars. And let's add another factor of 10 or so for planets. Now we are talking a big address space! (Oh, and I forgot about the multiverse....)
Using RFC 3587 as a reference, there are approximately 2^125 IPv6 addresses available. That is around 4.25×10^37. Combined with some form of private network addressing, there is plenty to serve mankind without even thinking about IPv8.
 


We are having a solar panel system array installed, and one of the accessories for the SolarEdge converter is a wifi kit, which allows our access to internet to view energy production monitoring/performance.
Does this introduce network security concerns?​
Backdoor access to the home network?​
Vulnerability by hackers?​
Compromising security of data over the network, like log-in data?​
 


We are having a solar panel system array installed, and one of the accessories for the SolarEdge converter is a wifi kit, which allows our access to internet to view energy production monitoring/performance.
Does this introduce network security concerns?​
Backdoor access to the home network?​
Vulnerability by hackers?​
Compromising security of data over the network, like log-in data?​
Well, hmmm,all these things are possible! It depends on quite a bit.

The inverter(s) I am guessing will use a power-line-like communication over your household wiring, which this kit picks up for display.

I don't know this brand, but in my case, the kit then squirts the data out to the monitoring company, which informs a web status page - all and good. Sounds like this thing does the web status page locally?

If you want to control what this thing is doing, you'll have to incorporate devices that control access on your network. You want to investigate things called VLANs, which are like virtual LANs, and put the kit onto its own net.

Hmmm, or I suppose if it's just sitting there not connected to your home's uplink to the internet, it's not talking to the outside world at all, and then I wouldn't worry too much about what it's doing – it will be on its own WiFi world, and you take a peek at it to see if you need to trim branches or brush snow off your panels.
 


Well, hmmm,all these things are possible! It depends on quite a bit.
The inverter(s) I am guessing will use a power-line-like communication over your household wiring, which this kit picks up for display.
I don't know this brand, but in my case, the kit then squirts the data out to the monitoring company, which informs a web status page - all and good. Sounds like this thing does the web status page locally?
If you want to control what this thing is doing, you'll have to incorporate devices that control access on your network. You want to investigate things called VLANs, which are like virtual LANs, and put the kit onto its own net.
Hmmm, or I suppose if it's just sitting there not connected to your home's uplink to the internet, it's not talking to the outside world at all, and then I wouldn't worry too much about what it's doing – it will be on its own WiFi world, and you take a peek at it to see if you need to trim branches or brush snow off your panels.
Well, basically it is talking to the internet. The converter talks to the wifi kit at the modem and uploads data to a remote server on the web, which we would access via a login account.

I am waiting for word from Solaredge to clarify any issues.

My concern is sort of based on the new articles about home monitoring systems like Nest, which are being hacked.

This is over my head – networks were never intuitive to me. I think there is something pertinent with whether this device is an outbound data generator
or allows inbound data** ... but does it operate completely independently? I would think all data transferred has some potential of being sifted through the device, or the device allows a back door entry point. Like I said... over my head.

** It must allow inbound data, as it has a facility for firmware updates on the devices, etc. ;-(
 


It must allow inbound data, as it has a facility for firmware updates on the devices
It depends on how you choose to define the term. All networked devices receive packets from elsewhere (a transmit-only device is generally not useful unless it is purely a data-collector).

The real question is whether it must receive unsolicited inbound data – that is, accept data it didn't ask for or accept an inbound connection it didn't request.

And, no, devices don't need to do this in order to support firmware updates. They can instead send requests (a.k.a. "phone home") to check for updates and initiate the download when they are available. They can either do this on a schedule or only when you explicitly ask them to, which is definitely safer than keeping an open port for a remote server to connect through.
 


... The real question is whether it must receive unsolicited inbound data – that is, accept data it didn't ask for or accept an inbound connection it didn't request. And, no, devices don't need to do this in order to support firmware updates. They can instead send requests (a.k.a. "phone home") to check for updates and initiate the download when they are available. They can either do this on a schedule or only when you explicitly ask them to, which is definitely safer than keeping an open port for a remote server to connect through.
Thanks for the clarification.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts