The Healthcare and Enterprise Wireless Experience

Nordic ULP Quarterly Q1 2015

Nordic Semiconductors latest Wireless Ultra Low Power publication.
www.nordicsemi.com
This issue is filled with yet again all the myriad of possibilities that BTLE and ANT can provide. The sky is definitely endless. Integra Systems, Inc. is working on several hardware/software applications for multiple vertical markets. We have worked with Nordic before on a very unique medical device application utilizing www.thisisant.com

Nordic Semiconductor's ultra-low power (ULP) wireless solutions support the latest demands of healthcare peripherals, specifically those that require smartphone connectivity by offering:

- Over-The-Air Device Firmware Update (OTA-DFU)
- Ultra-low power consumption – Years of battery life running from a single coin cell
- Multiprotocol SoCs - Single chip solutions capable of running more than one protocol on-chip including Bluetooth low energy and ANT
- Pin compatible SoCs - Pin compatible SoCs across Bluetooth Smart, ANT, and 2.4 GHz enables you to make one PCB design for a range of products
- Protocol/Application independence - The nRF51 series unique software architecture enables you to develop, compile, and test your application separately from the embedded protocol stack.
- Multi-vendor interoperability – Seamless connectivity to existing ANT+ and Bluetooth Smart systems
- Mobile phone connectivity – Seamless connectivity to mobile phones with built-in ANT+ or Bluetooth Smart.
- Small size– The combination of compact packaging options and support for tiny coin cell batteries supports the smallest wireless designs from watches down to key tags/fobs

OTA-DFU

The nRF51 Series are flash-based SoCs, as such they represent the most flexible solution available. A key feature of the nRF51 Series and their associated software architecture and S-Series SoftDevices is the possibility for Over-The-Air Device Firmware Update (OTA-DFU). See fig. 1. This allows firmware updates to be issued and downloaded to products in the field via the cloud. This enables OEMs to fix bugs and introduce new features to products that are already out in the marketplace. This brings added security and flexibility to product development when using the nRF51 Series SoCs.

Download NS_ULP_WQ_Q115_Spring_eR_NEW

The Connected Healthcare Delivery Network

This is a good video that depicts the wireless enabled hospital by Laird. It shows the connectivity that crosses the bounds of the hospital to the home.

www.lairdtech.com

http://www.lairdtech.com/support/learning-center/videos/connected-hospital

Bluetooth Smart Security BTLE

Coming back from HIMSSS in Chicago, it was interesting to see all the BTLE enabled wearable devices. It was also interesting to hear some of the comments regarding security and wireless devices..especially with the whole issue of cybersecurity. In fact this year was the first year that HIMSS had a special area devoted to cybersecurity. So please find the following covering BTLE and security.

Security, Bluetooth Smart (Low Energy)
To make sure the communication over Bluetooth® Smart (Low Energy, BLE, LE) is always secure and protected, the Bluetooth Core Specification provides several features to cover the encryption, trust, data integrity and privacy of the user’s data. We will further explain the technical details of those features in this article.
Pairing (also known as Association Models
The pairing mechanism is the process where the parties involved in the communication exchange their identity information to set up trust and get the encryption keys ready for the future data exchange. Depending on the user’s requirement and the capability of the device, Bluetooth has several options for pairing.
In version 4.0 and 4.1 of the core specification, Bluetooth Smart uses the Secure Simple Pairing model (referred to as LE Legacy after the Bluetooth 4.2 release), in which devices choose one method from Just Works, Passkey Entry and Out Of Box (OOB) based on the input/output capability of the devices.
With the release of the Bluetooth Core Specification version 4.2, security is greatly enhanced by the new LE Secure Connections pairing model. In this new model, the numeric comparison method is added to the other three methods and the Elliptical Curve Hellman-Diffie (ECDH) algorithm is introduced for key exchange in this process.
Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A] 5.4.2 Key Generation
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 3.6.1 Key Distribution and Generation
If you use LE legacy pairing, each of these association models is similar to BR/EDR Secure Simple Pairing with the exceptions that Just Works and Passkey Entry do not provide any passive eavesdropping protection. In LE Secure Connections pairing, the four association models are functionally equivalent to BR/EDR Secure Connections. The use of each association model is based on the I/O capabilities of the devices. You could choose the best pairing method based on the following table.

Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A] 5.4.1 Association Models
Key Generation
Key generation in Bluetooth Smart is performed by the Host on each LE device independent of any other LE device. Note: Key generation in BR/EDR is performed in the Controller. By performing key generation in the Host, the key generation algorithms can be upgraded without the need to change the Controller.
When using Bluetooth LE Secure Connections, the following keys are exchanged between master and slave:
• Connection Signature Resolving Key (CSRK) for Authentication of unencrypted data
• Identity Resolving Key (IRK) for Device Identity and Privacy
In LE Secure Connections, the public/private key pair is generated in the Host and a Secure Connection Key is generated by combining contributions from each device involved in pairing.
Encryption
Encryption in Bluetooth LE uses AES-CCM cryptography. Like BR/EDR, the LE Controller will perform the encryption function. This function generates 128-bit encryptedData from a 128-bit key and 128-bit plaintextData using the AES-128-bit block cypher as defined in FIPS-1971.
Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 3.6.2 Encryption Information
Signed Data
Bluetooth Smart supports the ability to send authenticated data over an unencrypted transport between two devices with a trusted relationship. This means that in some circumstances where the communication channel is not encrypted, the device could still have a method to maintain and ensure the data authentication. This is accomplished by signing the data with a CSRK. The sending devices place a signature after the Data Protocal Data Unit (PDU). The receiving device verifies the signature and, if the signature is verified, the Data PDU is assumed to come from the trusted source. The signature is composed of a Message Authentication Code generated by the signing algorithm and a counter. The counter is used to protect against a replay attack and is incremented on each signed Data PDU sent.
Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 3.6.6 Signing Information
Privacy Feature
Since Bluetooth 4.0, Bluetooth Smart supports a feature that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. The frequently changing address is called the private address and the trusted devices can resolve it.
In order to use this feature, the devices involved in the communication need to be previously paired. The private address is generated using the devices IRK exchanged during the previous pairing/bonding procedure.
There are two variants of the privacy feature. In the first variant, private addresses are resolved and generated by the Host. This is used in the pre-4.2 Bluetooth stacks. In the second variant, private addresses are resolved and generated by the Controller without involving the Host after the Host provides the Controller device identity information. Bluetooth 4.2 compliant devices use this design.
Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]
How Bluetooth Utilizes these Features to Protect Your Information
The goal of the LE security mechanism is to protect communication between devices at different levels of the stack. Below are commons types of attacks against various wireless communication protocols, and how Bluetooth addresses them.
Man-in-the-Middle (MITM)
A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel. One example is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones.
In LE Legacy pairing, MITM protection is obtained by using the passkey entry pairing method or may be obtained using the out of band pairing method. In LE Secure Connections pairing, MITM protection could be obtained by using the numeric comparison method as well as the previous two methods. To ensure that Authenticated MITM Protection (the protection through authentication) is generated, the selected Authentication Requirements option must have MITM protection specified.
Passive Eavesdropping
Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent. LE Secure Connection uses ECDH public key cryptography as a means to thwart passive eavesdropping attacks. ECDH provides a very high degree of strength against passive eavesdropping attacks. The algorithm provides a mechanism to exchange keys over an unsecured channel.
Privacy/Identity Tracking
Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address. This can be protected by frequently changing private addresses so only the trusted parties could resolve them.
Reference:
• BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]
The Bluetooth Smart specification has defined powerful security features to protect the communication of a user’s data and identity. Those features are either NIST compliant or FIPS approved. The Bluetooth SIG encourages and actively promotes the proper implementation of these security measures built into Bluetooth technology.

In Building Wireless Coverage DAS and Small Cells from SOLID

Have been covering www.solidtechusa.com for many years and have watched, Seth and Ken take this company to great heights. Believed in their vision from day one and they continue to be the innovators in this growing industry...both from a design and optical side of things.

Download HEALTHCARE_3PG_NWF

Download SK_TELECOM_2PG_L

Download SOLID_SUBWAY_CASESTUDY

HIMSS 2015 Brief Recap

HIMSS 2015 was very interesting and intense....like a record 42,000 attendees this year. Integra Systems, Inc., has been attending this meeting since 1997. We have been at the forefront of the beginning years of this event and seen a lot of changes...all positive. The challenge for any attendee was to actually figure out how to connect with technology and knowledge the space that they desired. The Interoperability Showcase, Connected Patient Gallery, and the Cybersecurity Commnand Center helped a lot to showcase specific technologies and offerings. However, with the amount of exhibits and attendees, it was like taking a drink from a fire hydrant. Heard this from several attendees.

As a side, it was good to see first hand the www.bd.com release of Intelliport. Integra Systems, Inc., was the engineering SME that over the course of five years that enabled the wireless engineering integration and final testing that led to the overall FDA 510(k) approval. http://www.bd.com/intelliport. This meeting also allowed for many strategic and investor discussions surrounding IOT, wireless sensors, and to include product development on the next generation cybersecurity enabled intelligent smart computer cards. We are currently developing patented solutions surrounding such.

While Integra Systems, Inc., has provided the engineering wireless sense for many technology companies and federal entities; we also have enabled companies to create a unique agnostic comprehensive marketing campaign to position their respective products in the marketplace on a global basis.

All in all, HIMSS 2015 in Chicago was another great event. If I go back to my experience in the 1980s with the AHA (American Heart Association), it seems that HIMSS has followed the same growth and challenge path. A lot more companies with smaller booth sizes.

HIMSS 2015 Annual Conference Chicago

Integra Systems, Inc. will be attending the annual www.himss.org conference for the 18th year. Receiving a press pass we intend to conduct a fair amount of interviews. In this time over a number of years a lot has changed at HIMSS. This conference has exploded into a somewhat CES show of healthcare. Not just software but virtually every available technology from infrastructure to now mobility applications. We will be commenting throughout the week on areas such as cyber security, telemedicine, sensors, and all the myriad of mobility applications.

When close to around 50,000 descend on Chicago…it will be interesting to say the least.

The showcases will continue to grow. A need is present for specific technology offerings.

Outcome of the Joint FCC-FDA Workshop

Outcome of the Joint FCC-FDA Workshop
March 31, 2015 - Washington D.C.

I attended this workshop yesterday, entitled Wireless Test Beds Workshop, Promoting Medical Technology Innovation – the Role of Wireless Medical Test Beds, a Joint FCC-FDA Workshop.

I applaud the FCC and the FDA for putting on this workshop. The purpose of this public workshop was to discuss the role of wireless test beds and their influence on the development of converged medical technology for clinical and non-clinical settings.

“Wireless medical devices must work as intended"…They must reliably, safely, and securely transmit the data that they collect”, as was stated in the welcome message.

As someone who has been in the wireless medical device world for thirty years, this was a lot of ground to cover. It seemed like we were “boiling the ocean”. A lot was discussed regarding WLAN (wireless LAN), co-existence testing, cellular, home healthcare, and dedicated spectrum versus unlicensed, etc. A lot of really good information was presented.

If we go back to the title of the overall workshop, it was about the Role of Wireless Test Beds. In this author’s opinion and experience this translates into the area of “how do you ensure a wireless connected medical devices and its application works as appropriate for its safe and intended use” within the healthcare institution. (This is specific to the hospital). Additionally, for any “RF/radio technology” to be available to the general public in the United States it has to pass certain EMI/EMC testing to meet EIRP (effective isotropic radiated power) guidelines for FCC approval.

In this case, I believe that wireless testing should center on:

1. Design of the wireless embedded module within the medical device to ensure effective roaming and security supplicant passing. Pre-testing should be carried out before the product is manufactured and for pre-submittal for a FDA 510(k).
2. Validation and verification of EMC/EMI in the presence of wireless emitters that measures validation and verification of network performance.
3. The design of the wireless network needs to support the intended use. This includes adequate RF coverage for areas of use of the clinical application.
4. Continued validation and verification of the wireless medical device in situ to ensure that any changes to the network performance does not degrade the intended application performance.

While I applaud this initial meeting; it would be helpful to have more of an engineering centric discussion next time. For example, case presentations could be:

1. Here are the problems and issues that we have encountered.
2. This is the testing and design of the solution that solved these problems over a variety of use models and environments.
3. These are the best practices for risk management of wireless medical devices when deployed in an enterprise healthcare environment.

At the end of the day, questions still came up from the audience about how to address the most basic problems of network security and quality of service in a wireless-enabled medical device network.

See the attached white papers that I have authored, that describe the process and testing that has been done with multiple medical device companies.

Download Ixia-david-hoglund-medical-device-testing-3

Download The_unique_wireless_medical_device_requirement_for_healthcare_wp_304-copy