Thursday, 27 June 2019

Finally, a real collaboration between industrial IoT and enterprise Wi-Fi

"HPE announces the integration of ABB Ability™ Smart Sensor technology with Aruba access points from end of 2019."

Included in HPE's news release on Tuesday, June 18 2019 was an announcement of a new Intelligent Edge partnership with ABB: the 130-year old Swiss industrial equipment manufacturer.

ABB Motor Sensor
Motor Sensor. Photo from ABB catalogue
Integrations like this, in addition to the recently released SES-Imagotag Electronic Shelf Labels integration, are helping to differentiate Aruba products as IoT-friendly in a competitive market.

SES-imagotag electronic shelf label. Image from SES-imagtotag.com


The ABB integration is part of a suite of so-called "turnkey edge-to-cloud" solutions for Industy 4.0, which also includes cool toys like an IP55-rated enclosure announced in 2018 called the "Secure Edge Data Center", that can be installed nearer to the factory floor for handling all those time-sensitive operational workloads.

Back to the sensors: ABB has an existing sensor platform called ABB Ability Smart Sensors.
(The sensor capabilities are detailed at the end of this post.)


In the ABB Ability platform without Aruba APs, the sensors communicate over Bluetooth either to a phone within 1-10 meters, or to a ABB-supplied Bluetooth gateway within 50 meters (best case). From there, the information is sent to a cloud service which plots historical data onto graphs, shows lovely red icons when a sensor is alerting, etc.

While the details of the Aruba integration have not yet been announced, it is fair to assume that the BLE radios that have been included in the 300-series and 500-series Aruba APs will be put to use to replace the "gateway every 50 meters" functionality.

If it works anything like the aforementioned SES-Imagotag ESL integration, we can expect to be able to deploy it with a few simple lines of configuration that will allow the AP to bridge the BLE sensors to ABB's cloud servers.
While SES-Imagotag requires a USB dongle, I am hopeful that the ABB solution will be native, as it uses standard BLE.

European organisations can purchase directly from ABB online and the store page reveals subscription pricing of €99.00/device/year with their native gateways. There probably won't be any cost from the Aruba side though.


ABB Bearing Sensor
Bearing Sensor. Photo from ABB catalogue

The sensor portfolio includes:

Condition monitoring for pumps to get readings for:

  • Health parameters
    • Overall condition
    • Overall vibration (velocity rms)
    • Bearing condition
    • Misalignment
    • Unbalance
    • Looseness
    • Blade problems
    • Cavitation (under development)
    • Flow turbulence (under development)
    • Skin temperature (degrees)
  • Operating parameters
    • Radial vibration (velocity rms)
    • Tangential vibration (velocity rms)
    • Axial vibration (velocity rms)
    • Speed (rpm)
    • Operating hours
    • Number of starts


Mounted bearing sensors to get readings for:

  • Temperature
  • Vibration
  • with a traffic-light health dashboard visible in smartphone app

Low voltage motor sensors to get readings for

  • Health parameters
    • Overall condition
    • Overall vibration (velocity rms)
    • Bearing condition
    • Misalignment
    • Skin temperature (degrees)
  • Operating parameters
    • Radial vibration (velocity rms)
    • Tangential vibration (velocity rms)
    • Axial vibration (velocity rms)
    • Speed (rpm)
    • Operating hours
    • Number of starts
    • Supply frequency (Hz)
    • Output power (hp/kW)
    • Regreasing count-down

Wednesday, 12 June 2019

Guide to 5GHz Wi-Fi Channels in New Zealand (NZ)

Disclaimer: I am not a registered RF Engineer, and this is just my interpretation of the information. You are responsible for ensuring your own compliance with Radio Spectrum Management

Most web searches for information about 5GHz Wi-Fi channels result in America-centric or Euro-centric results, so I've compiled this post for New Zealand specific information.

This information was sourced from rsm.govt.nz and from the NZ Government Gazette Radiocommunications Regulations (General User Radio Licence for Short Range Devices) Notice 2019 of April 2019. The regulations therefore may have changed since the 2017 version that is referenced on Wikipedia's list of WLAN channels



You should be aware that ground weather radar, covering channels 114, 118, 120, 122, 124, 126 and 128, operates at nine locations across New Zealand. These being Kaeo, Tamahunga, Mamaku, New Plymouth airport, Mahia, Outlook Hill (Wellington), Rakaia Trig, Blue Spur Range (Hokitika) and Invercargill Airport. If 5GHz Wi-Fi equipment is to be deployed in the vicinity of these 9 locations, it is highly recommended that these channels be avoided, as the weather radar is licenced for protection from interference. If your equipment causes any problems to these licenced services, compliance action may be taken against you. ---RSM.govt.nz

Ch36 to Ch48 (Ch50/)

5150MHz to 5250MHz
Max EIRP -7.0dBW
Use is limited to wireless LAN indoor systems only.
In the band 5150 – 5250 MHz, the maximum power is −7 dBW (200 mW) e.i.r.p. and the maximum permitted power spectral density is −20 dBW/MHz (10 mW/MHz) e.i.r.p. or equivalently −36 dBW/25 kHz (0.25 mW/25 kHz) e.i.r.p.

Ch52 to Ch64 (/Ch50)

5250MHz to 5350MHz
MAx EIRP -7dBW or 0dBW (depending on Indoor or Outdoor usage)
Use is limited to wireless LAN.
Indoor-Only Systems: In the band 5250 – 5350 MHz, the maximum power is −7 dBW (200 mW) e.i.r.p. and the maximum permitted power spectral density is −20 dBW/MHz (10 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented. If Transmitter Power Control is not used, then the maximum power (e.i.r.p.) value must be reduced by 3 dB;
Indoor and Outdoor Systems: In the band 5250 – 5350 MHz, the maximum power is 0 dBW (1 W) e.i.r.p. and the maximum permitted power spectral density is −13 dBW/MHz (50 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented in conjunction with the following vertical radiation angle mask where θ is the angle above the local horizontal plane (of the Earth):


Maximum permitted mean power density

Elevation angle above horizontal

−13 dB(W/MHz)

for 0° ≤θ <8°


−13 - 0.716(θ - 8) dB(W/MHz)

for 8° ≤θ <40°


−35.9 - 1.22(θ - 40) dB(W/MHz)

for 40° ≤θ ≤45°


−42 dB(W/MHz)

for 45° <θ;

Ch96 (actually Ch100) to Ch144

We must not implement Ch96, typically we begin at Ch100 for Wi-Fi, but the document does specify that this piece of spectrum begins at 5470MHz which is Ch96.

5470MHz to 5725MHz
Max EIRP 0dBW
Use is limited to wireless LAN
In the band 5470 – 5725 MHz, the transmitter peak power must not exceed −6 dBW (250 mW). The maximum power is 0 dBW (1 W) e.i.r.p. and the maximum permitted power spectral density is −13 dBW/MHz (50 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented. If Transmitter Power Control is not used, then the maximum power (e.i.r.p.) value must be reduced by 3 dB.

Ch149 to Ch169 (actually Ch168)

The published frequency range includes Ch169, but we must not use Ch169 in New Zealand.

5725MHz to 5850MHz
Max EIRP 23 dBW
In the band 5725 – 5850 MHz, the transmitter peak power must not exceed 0 dBW (1 W) and the power spectral density must not exceed 17 dBm/MHz. The maximum power of any emission must not exceed 23 dBW (e.i.r.p.). Transmission is permitted from customer premise equipment with integrated antenna that is part of a point-to-multipoint system receiving from and transmitting to a central access point.


It is interesting to note that the RSM boundaries fall on the centre frequencies of wide Wi-Fi channels, meaning that the upper and lower halves of the channel may have different regulations. I invite any commenters to clarify this.

This diagram sets out the Wi-Fi channels that you can and can’t use in New Zealand.
and here is a static image in case that link becomes unavailable:





Aruba Outdoor AP Mounting Bracket Photos

These are the 4 outdoor AP mounting brackets for Aruba AP 270 series, 360 series, 370 series 275, 365, 367, 374, 377, 374, 380

MNT-H1 - JW054A - Hanging install (can tilt)
MNT- H2 - JW055A - Hanging install (flush, cannot tilt)
MNT-V1 - JW052A - Long arm pole/wall mount (300mm from wall)
MNT-V2 - JW053A - Short arm pole/wall mount (75mm from wall)

Important: If using AP377 or AP387 or other directional AP, don't use the wall mount or you'll end up aiming the antennas at the floor! Rather use the MNT-H1 mount on a wall or pole.


All will become clear when you see the photos:


Thursday, 11 April 2019

Dragonblood: Should you worry? (Wi-Fi WPA3 security vulnerabilities explained for the not-so-techie)

On 10 April 2019 I noticed a flurry of panicky news stories and posts around LinkedIn and Twitter. The Wi-Fi Alliance published a security update regarding security vulnerabilities in the new WPA3 Wi-Fi standards which WLAN vendors are expected to start rolling out en masse in 2019.

The WPA3 standards promised a far more secure environment than the aging WPA2 standards currently in use just about everywhere today. The vulnerabilities (named Dragonblood) already have their own webpage, logo, theme song, etc. so we know that non-technical company execs will be seeing this across their feeds and demanding information about the security of the million-dollar Wi-Fi refresh they've just paid for, by the end of the week.

Before we engage in mass hysteria, let's examine the vulnerabilities a little further and see if there is truly anything to worry about.

Is this report from a reputable source?
Yes! The analysis and POC code were written by Mathy Vanhoef (NYUAD) and Eyal Ronen (Tel Aviv University & KU Leuven). Vanhoef had also discovered the Krack attack vulnerabilites that got everyone worried in 2017.

Why "Dragonblood"?
It is trendy for vulnerabilities to be given catchy names as this makes it easier for them to be written about in the media and go viral. These vulnerabilities are mainly around the handshake key exchange mechanism used in WPA3 which is called Dragonfly, hence the analysis paper was titled Dragonblood. The researchers released 4 tools to demonstrate the specific attacks and named them Dragonslayer, Dragondrain, Dragontime, and Dragonforce.
Note that the Dragonfly family of handshakes is not only used in Wi-Fi. Other encryption-based systems could also be vulnerable.

Can the Dragonblood vulnerabilities be fixed?
Yes, mostly.
Thanks to the researchers' responsible disclosure of the vulnerabilities, major vendors already had patches in place or in the works before the public announcement was made. simply ensuring that the firmware on your network equipment is kept up to date is sufficient to mitigate or remediate against most of these vulnerabilities. (this is why it is important to use trusted brands and keep those support contracts up to date folks).
In at least one of the downgrade attack scenarios (explained in more detail later on), a device is tricked into connecting to a WPA2 network and then a WPA2 exploit is used. This can't be easily fixed but it isn't strictly a WPA3 exploit either.
Unless you're 100% in control of every device connecting to your network (and who is?), you can't update the client side devices. The good news here is that hardly any WPA3 client devices are released yet, so hopefully most will be fixed before anyone even buys them.

Cisco has already released a statement by the reputable Jerome Henry, saying "Cisco Access points are not affected by any of the vulnerabilities described. The Cisco AireOS and IOS-XE releases that support SAE for WPA3-Personal will also include protection mechanisms against these vulnerabilities. WPA3 clients may need to be updated and Cisco recommends finding the latest information from vendors’ websites."

I will update this page with statements from other vendors as they become available. Personally I'm looking forward seeing a comment from Dan Harkins, the computer scientist who wrote Dragonfly and EAP-pwd, and currently happens to be employed by Aruba Networks.

In summary: The sky isn't falling, keep your network devices up to date, keep your client devices up to date.

You can find more detail about the individual tools below.

Dragonslayer
From the readme: This is an experimental tool to test EAP-pwd implementations for vulnerabilities. We also strongly recommend to perform code inspections to assure all vulnerabilities have been properly addressed.

Should you worry?
No.
Virtually nobody is using EAP-pwd in their Wi-Fi networks. It is rarely even presented as an option. Unless your job involves actually building Wi-Fi devices, you don't need to worry about this.

Dragondrain
From the readme: The Dragondrain tool forges Commit messages to cause a high CPU usage on the target. This can for example be used to drain the battery of a device, or more generally to drain and exhaust resources.

The name is a play on the fact that this is a 'clogging' attack.

Should you worry?
Not if you keep your network devices up to date.
It is a denial-of-service attack. The authors have already given the solution to the vendors to implement i.e. use a dedicated, low-priority CPU thread to run this task so that the entire CPU can never be impacted.

Dragontime
From the readme: This is an experimental tool to carry out timing attacks against WPA3's SAE handshake. It was created to carry out attacks, not to detect whether an implementation is vulnerable in the first place. It was used to carry out the timing attack against MODP groups 22 and 24 as described in the Dragonblood paper.

This vulnerability actually has a CVE allocation: CVE-2019-9494

Should you worry?
Not too much.
You don't need to know what MODP (Modular Exponential) groups are, just that they are options implemented in cryptographic algorithms. Three groups have been identified here as being vulnerable while another three groups are suggested to be avoided. This can be fixed in a software patch that simply removes those groups as options (that is if the groups were ever used in the first place - according to the paper there were already known issues since 2017 with these groups, so they should have been avoided all along). The authors even state this "Note that most WPA3 implementations by default do not enable these groups"

Dragonforce
This is the tool that takes the information from the other tools and runs something similar to a dictionary attack to retrieve the keys.

What about that 'downgrade attack' mentioned earlier?
It is really difficult to move 20 years' worth of devices to a new encryption scheme, so the WPA3 standard allows for a compatibility mode, or transition mode, of operation where the network will simultaneously support WPA2 and WPA3. The attack in this case involves setting up an 'evil twin' SSID using only WPA2 and the client device connects to it because it knows that WPA2 is still permitted. WPA2 vulnerabilities are then leveraged to discover the keys.

Should you worry?
No more than you worried yesterday about your WPA2 networks.
The fix for this needs to come from the manufacturers of client devices. Samsung, Apple, Lenovo, etc. 
As a network operator you can run WIDS/WIPS to guard against this type of attack.


I'm having trouble sleeping at night, where can I find the full paper?
The full paper has been published at https://papers.mathyvanhoef.com/dragonblood.pdf