U.S. patent number 10,841,104 [Application Number 16/422,175] was granted by the patent office on 2020-11-17 for system and method for secure relayed communications from an implantable medical device.
This patent grant is currently assigned to Poltorak Technologies LLC. The grantee listed for this patent is Poltorak Technologies LLC. Invention is credited to Alexander I Poltorak.
United States Patent |
10,841,104 |
Poltorak |
November 17, 2020 |
System and method for secure relayed communications from an
implantable medical device
Abstract
The present invention provides systems and methods for
supporting encrypted communications with a medical device, such as
an implantable device, through a relay device to a remote server,
and may employ cloud computing technologies. An implantable medical
device is generally constrained to employ a low power transceiver,
which supports short distance digital communications. A relay
device, such as a smartphone or WiFi access point, acts as a
conduit for the communications to the internet or other network,
which need not be private or secure. The medical device supports
encrypted secure communications, such as a virtual private network
technology. The medical device negotiates a secure channel through
a smartphone or router, for example, which provides application
support for the communication, but may be isolated from the
content.
Inventors: |
Poltorak; Alexander I (Monsey,
NY) |
Applicant: |
Name |
City |
State |
Country |
Type |
Poltorak Technologies LLC |
Suffern |
NY |
US |
|
|
Assignee: |
Poltorak Technologies LLC
(Suffern, NY)
|
Family
ID: |
54783259 |
Appl.
No.: |
16/422,175 |
Filed: |
May 24, 2019 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20190288860 A1 |
Sep 19, 2019 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
15948667 |
May 28, 2019 |
10305695 |
|
|
|
14968336 |
Apr 10, 2018 |
9942051 |
|
|
|
14214077 |
Dec 15, 2015 |
9215075 |
|
|
|
61799720 |
Mar 15, 2013 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L
63/0272 (20130101); H04L 9/006 (20130101); G16H
40/67 (20180101); H04W 12/02 (20130101); H04L
63/0823 (20130101); H04W 12/033 (20210101); H04L
9/3268 (20130101); H04L 63/04 (20130101); H04L
63/0428 (20130101); G16H 20/17 (20180101); H04L
2209/88 (20130101); H04L 2209/80 (20130101); H04W
12/33 (20210101); Y02D 30/70 (20200801); A61B
5/0006 (20130101); H04W 12/43 (20210101); G16H
20/30 (20180101) |
Current International
Class: |
H04L
9/32 (20060101); H04L 9/00 (20060101); H04W
12/00 (20090101); H04W 12/02 (20090101); A61B
5/00 (20060101); G16H 40/67 (20180101); G16H
20/30 (20180101); G16H 20/17 (20180101); H04L
29/06 (20060101) |
References Cited
[Referenced By]
U.S. Patent Documents
Other References
Oyvind Borthus and Tomas Mikael Engh, "Privacy protection in a
mobile Biomedical Information Collection Service", (Master's
Thesis), Agder University College, Grimstad Norway (May 2005).
cited by applicant .
Ross, David Andrew. "Securing IEEE 802.11 wireless LANs." (2010).
Ph.D. Thesis Queensland University (2010). cited by applicant .
Fischer, Martin. "Enhancing the ReMoteCare prototype by adding an
SNMP proxy and video surveillance." (2008). University of Techn.,
Sydney. cited by applicant .
Pankakoski, Veikko. "Experimental design for a next generation
residential gateway." (2010). M.S. Thesis Aalto University (2010).
cited by applicant.
|
Primary Examiner: Schwartz; Darren B
Attorney, Agent or Firm: Hoffberg & Associates Hoffberg;
Steven M.
Parent Case Text
CROSS REFERENCE TO RELATED APPLICATION
The present application is a Continuation of U.S. patent
application Ser. No. 15/948,667, filed Apr. 9, 2018, now U.S. Pat.
No. 10,305,695, issued May 28, 2019, which is a Continuation of
U.S. patent application Ser. No. 14/968,336, filed Dec. 14, 2015,
now U.S. Pat. No. 9,942,051, issued Apr. 10, 2018, which is a
Continuation of U.S. patent application Ser. No. 14/214,077, filed
Mar. 14, 2014, now U.S. Pat. No. 9,215,075, issued Dec. 15, 2015,
which is a non-provisional of and claims benefit of priority under
35 U.S.C. .sctn. 119(e) from U.S. Provisional Patent Application
No. 61/799,720, filed Mar. 15, 2013, the entirety of which are
expressly incorporated herein by reference in their entirety.
Claims
What is claimed is:
1. A communication device, comprising: a wireless network digital
communication transceiver, configured to communicate with another
wireless digital communication transceiver through a multi-hop mesh
network comprising at least one untrusted intermediate node,
according to a multi-hop mesh networking communication protocol; an
external interface, configured to at least one of receive
information from a sensor, and to generate a control signal for an
output device; and at least one automated processor, configured to:
receive an identification of a remote server through the wireless
network digital communication transceiver, the identification being
automatically securely and reliably transmitted from an
authenticated source through the at least one untrusted
intermediate node; updating the identification of the remote
server, after receipt of the identification using secure and
reliable communications through the at least one untrusted
intermediate node; check the remote server against a
remotely-hosted certificate revocation list, using secure and
reliable communications through the at least one untrusted
intermediate node; perform a secure and reliable key exchange with
the remote server if a certificate of the remote server is not on
the certificate revocation list, through the at least one untrusted
intermediate node, secure from interception key information by the
at least one untrusted intermediate node; and establish an
encrypted communication channel based on the secure and reliable
key exchange with the remote server by communications through both
the wireless network digital communication transceiver and the at
least one untrusted intermediate node; and communicate information
between the encrypted communication channel and the external
interface secure from interception and secure from undetected
message modification by the at least one untrusted intermediate
node.
2. The communication device according to claim 1, wherein the
communicated information comprises control information for
execution by the at least one automated processor.
3. The communication device according to claim 1, wherein the
communicated information comprises sensor data from the external
interface.
4. The communication device according to claim 1, wherein the
encrypted communication channel comprises the Internet.
5. The communication device according to claim 1, wherein the
wireless network digital communication transceiver comprises a
wireless personal area network device.
6. The communication device according to claim 1, wherein the
wireless network digital communication transceiver comprises a
wireless local area network device.
7. The communication device according to claim 1, wherein the
encrypted communication channel comprises a cellular communication
channel.
8. The communication device according to claim 1, wherein the
encrypted communication channel comprises a virtual private
network.
9. The communication device according to claim 1, wherein the
wireless network digital communication transceiver comprises an
IEEE-802.15 transceiver and the at least one untrusted intermediate
node comprises a smartphone executing an untrusted downloadable
app, the untrusted downloadable app having access to communications
packets of the multi-hop mesh networking communication
protocol.
10. The communication device according to claim 1, wherein the at
least one automated processor is configured to receive the
identification of a remote server based on an initiating inbound
received communication through the wireless network digital
communication transceiver.
11. The communication device according to claim 1, wherein the at
least one automated processor is configured to establish the
encrypted communication channel based on an initiating inbound
received communication through the wireless network digital
communication transceiver.
12. The communication device according to claim 1, wherein the at
least one automated processor is further configured to block
execution of commands for control of the external interface
received through the wireless network digital communication
transceiver which are received outside of the encrypted
communication channel.
13. A communication method, for controlling a communication device
comprising: a wireless network digital communication transceiver
communicating with another wireless digital communication
transceiver through a multi-hop mesh network comprising at least
one untrusted intermediate node, according to a multi-hop mesh
networking communication protocol; an external interface for at
least one of receiving information from a sensor, and generating a
control signal for an output device; and at least one automated
processor, the method comprising: checking an identification of a
remote endpoint for communications against a certificate revocation
list; performing a key exchange with the identified remote
endpoint, if the identified remote endpoint is not the on the
certificate revocation list, through the at least one untrusted
intermediate node; establishing an encrypted communication channel
based on the key exchange with the remote endpoint by
communications through the wireless network digital communication
transceiver and the at least one untrusted intermediate node; and
communicating information between the encrypted communication
channel and the external interface, the receipt of identification,
the check against the certificate revocation list, and the
communicated information each using communications secure from
undetected message modification by the at least one untrusted
intermediate node, and the key exchange, and the communicated
information each being secure from interception of key information
by the at least one untrusted intermediate node.
14. The method according to claim 13, further comprising: receiving
an identification of the remote endpoint through the wireless
network digital communication transceiver; and automatically
securely transmitting the identification of the remote endpoint
from an authenticated source through the at least one untrusted
intermediate node.
15. The method according to claim 13, further comprising executing
control information contained in the communicated information by
the at least one automated processor.
16. The method according to claim 13, further comprising
transmitting sensor data from the external interface in the
communicated information.
17. The method according to claim 13, further comprising at least
one of updating an identification of a remote endpoint and
initiating the encrypted communication, based on an unsolicited
inbound communication received through the wireless network digital
communication transceiver.
18. The method according to claim 13, wherein: the encrypted
communication channel comprises the Internet; the wireless network
digital communication transceiver comprises at least one of a
wireless personal area network device and a wireless local area
network device; the encrypted communication channel comprises a
cellular communication channel; the encrypted communication channel
comprises a virtual private network; the at least one untrusted
intermediate node comprises a smartphone executing an untrusted
downloadable app; and the untrusted downloadable app has access to
communications packets of the multi-hop mesh networking
communication protocol.
19. A non-transitory computer readable medium storing instructions
for control of at least one automated processor of a communication
device comprising a wireless network digital communication
transceiver communicating with another wireless digital
communication transceiver through a multi-hop mesh network
comprising at least one untrusted intermediate node, according to a
multi-hop mesh networking communication protocol, and an external
interface at least one of receiving information from a sensor, and
generating a control signal for an output device, the instructions
comprising: instructions for checking an identification of a remote
endpoint for communications against a certificate revocation list;
instructions for performing a key exchange with the identified
remote endpoint, if the identity of the remote endpoint is not on
the certificate revocation list, through the at least one untrusted
intermediate node; instructions for establishing an encrypted
communication channel based on the key exchange with the remote
endpoint by communications through the wireless network digital
communication transceiver and the at least one untrusted
intermediate node; and instructions for communicating information
between the encrypted communication channel and the external
interface, wherein the instructions for the receipt of
identification, the instructions for the check against the
certificate revocation list, and the instructions for the
communicating of information each define communications secure from
undetected message modification by the at least one untrusted
intermediate node, and wherein the instructions for performing the
key exchange, and the instructions for communicating of information
each define communications secure from interception of key
information by the at least one untrusted intermediate node.
20. The non-transitory computer readable medium according to claim
19, further storing instructions for control of at least one
automated processor for receiving an identification of the remote
endpoint through the wireless network digital communication
transceiver, the instructions for receiving the identification of
the remote endpoint defining communications which automatically
securely transmit from an authenticated source through the at least
one untrusted intermediate node.
Description
FIELD OF THE INVENTION
The present invention relates to the field of implantable medical
devices, and more particularly implantable medical devices having
wireless data communications transceivers.
BACKGROUND OF THE INVENTION
The present invention relates generally to systems and methods for
providing secure and private communication channels for implantable
medical devices using public communication networks and potentially
insecure devices as intermediaries.
Implantable and programmable personal medical devices are becoming
common. In some cases, these represent applications ("apps") for
smartphones. In other cases, regulated medical devices communicate
through commercial off the shelf technologies. In both these cases,
it is possible for provide communications to be intercepted,
revealing potentially personal or confidential information.
Further, it may be possible to modify communications, leading to
misdiagnosis, improper treatment, or other harm.
For example, a smartphone app or the platform on which a smartphone
app executes may include security vulnerabilities, even if the app
is digitally signed. For example, of the medical device is a
defibrillator, this could be reprogrammed to fail to generate a
required discharge, or to discharge in a harmful or lethal
pattern.
It is therefore desirable to make use of ubiquitous consumer
technologies for communications, while isolating the privacy and
security risks inherent in such technologies.
Oyvind Borthus and Tomas Mikael Engh, "Privacy protection in a
mobile Biomedical Information Collection Service", (Master's
Thesis), Agder University College, Grimstad Norway (May 2005),
expressly incorporated herein in its entirety, presents FIG. 1
which indicates a problem which persists to this day. How does one
secure the communication from the patient to a provider, and from
the provider to the patient, where the data communicated is
private, and corruption of that data may be life-threatening?
Borthus and Engh do not consider security of the "handheld device"
as an issue to be addressed.
The use of a mobile wireless sensor gives the patient the
possibility of being at home and doing his or hers normal daily
activities while being monitored, but it also creates the need for
new mechanisms for privacy protection. Fensli, R., E. Gunnarson,
and T. Gundersen (2005) "A Wearable ECG-recording System for
Continuous Arrhythmia Monitoring in a Wireless Tele-Home-Care
Situation," presented at The 18th IEEE International Symposium on
Computer-Based Medical Systems, Dublin, Ireland. For the patient to
stay in his normal environment gives several benefits for both the
patient and the quality of the monitoring. The patient will be more
relaxed and the recordings will not be affected by the stressful
situation at a hospital.
A mobile wireless sensor is a compact electronic electrode attached
to a patient that can measure different biomedical signals. In this
scenario we are using a sensor for electrocardiogram (ECG)
recordings as an example. This sensor will continuously measure and
wirelessly transmit sampled ECG-recordings using a built-in
RF-radio transmitter. The RF-radio receiver converts the
ECG-samples by the use of a microcontroller before transmitting the
ECG-samples to a standard personal digital assistant (PDA). The
sensor measures ECG-signals with a sampling frequency up to 1000
samples per second. Crawford, M. H. et al. (1999) "ACC/AHA
Guidelines for Ambulatory Electrocardiography: Executive summary
and Recommendations" American College of Cardiology. The signal is
digitalized with 10-bit resolution, requiring up to 10 kb/s of
bandwidth plus overhead to transmit to the PDA. The range of the
RF-radio signal is up to 10 meters. The transmitter chip used by
the sensor described in Fensli et al. is a RF-transmitter CC1050
from ChipCon, operating at 869.700 MHz, with a bit rate of up to
76.8 kbit/s. The sensor will transmit continuously, and will be
attached to the patient for 3 days to a week at a time. The sensor
is a disposable unit, and will only be used once.
A PDA is used to receive the information from the sensor of Fensli
et al. and will often have 400 to 600 MHz processor, 64 to 128 MB
of internal memory and a memory card with capacity of more than 2
GB for storing data. The PDA has both a short range wireless
RF-radio device and a GPRS card installed. The PDA is an
"intelligent" unit, using automatic arrhythmia detection algorithms
for analyzing the signals from the sensor and decides if the
recordings are within normal values. As long as the signals are
within normal values the PDA will regularly send an extract of the
recordings to an electronic health register (EHR) connected to the
Internet by the use of GPRS communication. If an abnormal ECG
activity is encountered, the PDA will store 1 minute of the ECG
recordings and then transmit the recordings to the EHR server.
There are several security and privacy threats relevant to this
scenario. From a medical standpoint it is very important that the
PDA only receives data from the correct sensor, and not from other
devices in the same area. Keeping the integrity of the data is also
very important to avoid false alarms or incorrect normal signals.
The data must also be protected in such a way that possible
attackers cannot get access to personal information about the
patient.
For the transmission of data from the PDA to the EHR, and between
users in the national health network many of the same threats
applies. Integrity, security and privacy must be protected when
sending electronic messages containing sensitive medical and
personal information. The electronic messages contain a lot more
sensitive information than the data packets sent from the sensor
and thus require a higher level of security protection. Non
repudiation is especially important when sending messages regarding
medication and diagnosis.
Bluetooth is a short range radio standard designed for low power
consumption. On Jun. 14, 2002 the Bluetooth standard was published
as IEE 802.15.1. Subsequent versions have been published. Bluetooth
operates in the unlicensed industrial, scientific and medical (ISM)
band at 2.4 to 2.485 GHz, using a spread spectrum, frequency
hopping, full-duplex signal at a nominal rate of 1600 hops/sec.
Bluetooth SIG (2004) "Specification of the Bluetooth System". The
adaptive frequency hopping (AFH) was designed to reduce
interference between wireless technologies using the 2.4 GHz
spectrum. The AFH detects other devices and avoid the frequencies
used and can take advantage of the available frequencies. The AFH
hops among 79 frequencies at 1 MHz intervals to give high
interference immunity. The range of Bluetooth devices range from 1
to 100 meters depending on the device class used. Class 1 devices
use a power of 100 mW giving it a range of up to 100 meters, class
2 uses 2.5 mW and have a range of up to 10 meters, and class 3 uses
1 mW and have a range of up to 1 meter. Class 2 is the most
commonly used. Version 1.2 has a gross data rate of up to 1 Mbit/s
and Version 2.0 with Enhanced Data Rate (EDR) has a gross data rate
of up to 3 Mbps. The effective transfer rates are respectively
723.1 kbit/s and 2.1 Mbit/s. Bluetooth devices communicate in small
groups of up to 8 devices, called a piconet. One device plays the
"master" and the rest (up to 7) devices are "slaves". Data can be
transferred between master and 1 slave at any given time, and the
master switches between slaves in a round robin fashion.
Simultaneous transmission from master to multiple slaves is
possible, but rarely used.
A Bluetooth device will transmit the following sets of information
on demand: Device name; Device class; List of services; and
Technical information. Any device can perform an inquiry to find
other devices with which to connect, and any device can be
configured to respond to such inquiries. If the device trying to
connect knows the address to the device, it will always respond to
inquiries with the information mentioned above if requested for it.
Use of the devices services may require pairing or owner accept,
but the connection itself can be established by any device and held
until it goes out of range. All devices have a unique 48-bit
address, but these are generally not shown in inquiries and instead
user friendly "Bluetooth names" are used. These names can be set by
the user and most devices come with a standard name set by the
manufacturer. All devices also have a 24-bit class identifier,
providing information about what class of device it is, for example
mobile phone, headset or computer.
Bluetooth devices can be paired to establish a trusted connection.
By user input (a pin code) they can learn a shared secret key known
as a "passkey". A device can then cryptographically authenticate
the identity of another device. With some devices, like wireless
earphones, it is impossible for the user to enter a pin code, and
the device has a fixed pin code, which can be entered into the peer
device. Trusted devices can also encrypt information they transmit
so no one can "listen in". The encryption can be turned off, and
the passkey is stored in the device's memory, and not in the
Bluetooth chip itself. The trusted connection can be canceled by
either device at any time. Devices will generally require pairing
or user input before it allows a remote device to use its
services.
In order to communicate with other Bluetooth devices a device must
be able to interpret certain Bluetooth profiles. These profiles
define the possible applications. 24 profiles are defined and
adopted by the Bluetooth SIG, for example: Generic Access Profile
(GAP) which provides the basis for all other profiles. This profile
describes which features must be implemented in all Bluetooth
devices, generic procedures for discovering and linking to devices,
and basic user-interface terminology; Basic Imaging Profile (BIP).
This profile is designed for sending images between devices and
includes the ability to resize, and convert images to make them
suitable for the receiving device; and Human Interface Device
Profile (HID) provides support for devices such as mice, joysticks,
keyboards, etc.; Advanced Audio Distribution Profile (A2DP). Also
referred to as the AV profile, it is designed to transfer a stereo
audio stream like music from an MP3 player to a headset or car
radio.
On the link layer Bluetooth uses the SAFER+ algorithm for
authentication and key generation, and E0 stream cipher for
encrypting packets. The link layer security is independent of
possible application layer security. The SAFER+ (Secure and Fast
Encryption Routine) algorithm is a block cipher with block size of
128 bits, and a default key size of 128 bits. Wikipedia.org "SAFER"
en.wikipedia.org/wiki/SAFER. The cipher uses 8 rounds with 4
stages; a key-mixing stage, a substitution layer, another
key-mixing stage, and finally a diffusion layer. The E0 is a stream
cipher. Wikipedia.org "E0 (cipher)",
en.wikipedia.org/wiki/E0_(cipher). It generates a sequence of
pseudorandom numbers and combines it with the data using a XOR
operator. The key length is usually 128 bits, but may vary. For
each iteration E0 generates a bit using 4 shift registers of
different length (25, 31, 33, 39 bits), and two internal states,
each 2 bits long. For each clock cycle, the registers are shifted
and the two states are updated with the current state, the previous
state and the values in the shift registers. Four bits are then
extracted from the shift registers and added together. Then the
algorithm XORs that sum with the value in the 2-bit register. The
first bit of the result is output for the encoding. E0 is divided
in three parts: 1. Payload key generation; 2. Key stream
generation; and 3. Encoding.
The setup of the initial state in Bluetooth uses the same structure
as the random bit stream generator. We are thus dealing with two
combined E0 algorithms. Using the 128-bit key, Bluetooth address on
48 bits and the 26-bit master counter an initial 132-bit state is
produced at the first stage. The output is then processed by a
polynomial operation and the resulting key goes through the second
stage, which generates the stream used for encoding. The key is a
multiple of 2 varying from 8 to 128-bits length. 128 bit keys are
generally used. These are stored into the second stage's shift
registers. 200 pseudorandom bits are then produced, and the last
128 bits are inserted into the shift registers. It is the stream
generator's initial state.
Shaked and Wool showed (Shaked, Y. and A. Wool (2005) "Cracking the
Bluetooth PIN" Shaked, Yaniv, and Avishai Wool. "Cracking the
bluetooth pin." In Proceedings of the 3rd international conference
on Mobile systems, applications, and services, pp. 39-50. ACM,
2005;
www.eng.tau.ac.il/.about.yash/shaked-wool-mobisys05/index.html (May
2, 2005)) that the PIN code used by some devices to add security
can be easily broken, even on an old computer. They described a
passive attack, in which an attacker can find the PIN used during
the pairing process. They used less than 0.3 seconds to crack a
4-digit pin, as used by most devices using a pin code, on a Pentium
III 450 MHz computer and even faster on a new 3 GHz Pentium IV. If
two Bluetooth devices perform pairing in a hostile area, they are
vulnerable to this attack. Lu, Meier, and Vaudenay (Lu Y., W.
Meier, and S. Vaudenay (2005) "The Conditional Correlation Attack:
A Practical Attack on Bluetooth Encryption" Crypto'05, Santa
Barbara. CABA "Standards and protocols"
www.caba.org/standard/zigbee.html (Jan. 18, 2006)) presented an
attack on the E0 stream cipher. Using a conditional correlation
attack developed and optimized against Bluetooth two-level E0 they
attack a recently detected flaw in the resynchronization of E0.
Their best attack finds the original encryption key for two-level
E0 using the first 24 bits of 223.8 frames and with 238
computations. This is the fastest and so far only practical
known-plaintext attack on Bluetooth encryption.
ZigBee Alliance was incorporated in August 2002, and announced the
ZigBee standard in December 2004. The ZigBee standard was released
public in June 2005. Other wireless transfer methods are focusing
on transferring large amount of data as fast as possible, but
ZigBee is going the other direction. It focuses on low powered
devices with a need for security and sending small amounts of data.
The ZigBee standard was created to "enable reliable,
cost-effective, low-power, wirelessly networked, monitoring and
control products based on an open global standard" ZigBee Alliance
"Our Mission". www.zigbee.org/en/about/(online May 25, 2006). The
most common devices that use ZigBee are industrial automation,
remote metering, embedded sensors, medical devices, smoke and
intruder alarms, interactive toys, building automation and home
automation. ZigBee operates in the European 868 MHz ISM band with
one channel, the American and Australian 915 MHz ISM band with 10
channels or the 2.4 GHz ISM band with 16 channels. The data rate is
250 kbit/s in the 2.4 GHz band, 40 kbit/s in the 915 MHz band, and
20 kbit/s in the 868 MHz band. ZigBee Alliance (2004) "ZigBee
Specification v1.0"; Kinney, P. (2003) "ZigBee Technology: Wireless
Control that Simply Works", Kinney Consulting LLC, Chair of IEEE
802.15.4 Task Group, Secretary of ZigBee BoD, Chair of ZigBee
Building Automation Profile WG. Transmission range is typical
between 10 and 75 meters. The ZigBee protocol supports up to 65,536
nodes. It has handshaking for transfer reliability.
The ZigBee stack architecture is based on the standard seven-layer
c is controlling the access to the radio channel. The mechanism
used is called CSMA-CA. The MAC layer also transmits beacon frames,
synchronization, and provides reliable transmission mechanisms. The
network layer has 3 main functions: join and leave networks, apply
security, and route frames to their destinations. In a coordinator
device, the network layer has the responsibility to start a new
network and discover what kind of application services nearby
devices. It also assigns addresses to newly assigned devices. The
network layer supports star, cluster three and mesh topology. As
mentioned above, the APL layer consists of Application Support
sub-layer (APS), ZigBee Device Object (ZDO) and
manufacturer-defined applications. The APS is responsible for
maintaining the tables for binding i.e. the ability to match two
devices and forward the messages between two devices. The ZDO
define the role of a device in the network (network coordinator,
coordinator, or end device), initiate and/or respond to binding
requests, and establish a secure connection.
ZigBee has several different security mechanisms (ZigBee Alliance
(2005) "ZigBee Security specification overview"), and are found in
the MAC layer, NWK layer and the APS layer. Among them are
freshness, integrity, authentication, and encryption. The freshness
checks prevent replay attacks. It uses incoming and outgoing
freshness counters that are reset every time a new key is created.
The integrity checks prevent anyone from modifying the message, and
supports up to 128-bit message integrity. Authentication is handled
either in the network level or the device level. The network level
authentication is achieved when using a common network key. This
will prevent attacks from outsiders, and it has very little memory
cost. The device level authentication is achieved when using unique
link keys between pair of devices. This prevents attacks from both
outsiders and insiders, but has a higher memory cost. ZigBee
supports 128 bit AES encryption. This encryption can be used either
at network level or device level, and is handled the same way as
authentication. The encryption can be turned on or off without
impacting the freshness, integrity or authentication. ZigBee can
also add security to frames. ZigBee Security can add headers to the
data frames at the MAC, NWK, and APS layers. ZigBee supports 3
types of topologies: Star, Cluster tree and Mesh.
In a star topology the network is controlled by a PAN coordinator
(network controller). All end devices can only talk to the
coordinator. The coordinator is almost always in a listening mode,
except when new end devices are trying to connect. The star
topology supports up to 65,536 end devices. It is a very simple
layout and has low latency. Oyen, G.E. (2006) "ZigBee and IEEE
802.15.4: A brief introduction". In a cluster tree topology the
tree structure is rooted at the PAN coordinator. The coordinator
initiates the network, and the children (end devices) routes
through parents in a hierarchy. It uses a multi-hop topology to
increase the network range. The cluster tree topology is not ideal
for network devices that require low latency. The idea with mesh
topology is that messages can be routed from any source to any
destination. The way this is done is that every FFD is functioning
as a router for all its neighbors. Like cluster tree topology, the
mesh topology uses multi-hop topology to increase the network
range. It has high reliability, since the messages can go many
routes. If one or more of FFD disconnects, the messages still gets
to the destination, but uses another route than it normally does.
This way it is self-configuring. Since this topology depends on the
routers, it may not be ideal for battery driven networks, as the
routers will have relatively large power consumption.
Only one Zigbee coordinator (ZC) is required in each ZigBee
network. It is the most capable device in the network, and
initiates the formation. It is the root of the network tree, and
might bridge to other networks. It acts as a PAN coordinator (FFD)
and as a router when the network is formed. The ZC also acts as a
repository for security keys. The coordinator is also assumed to be
the trust center, which is responsible for allowing new devices
into the network and for distributing keys. It is possible for the
trust center to be a dedicated device. The Zigbee Router (ZR) is an
optional component in a ZigBee network. The routers associate with
the ZC or with other previously associated ZR. The ZR acts as a
coordinator (FFD) and is used as a local address
allocation/de-allocation device. It is used in multi-hop routing of
messages. The ZR also looks after its own Zigbee End Device (ZED).
The ZED contains very little functionality. It is limited to
communicate with its coordinator. The ZED is not allowed to
associate or participate in routing. It requires the least amount
of memory and is therefore cheaper than ZC or ZR. It has low power
consumption since its parent puts it to sleep.
When a new device is installed in the network, it will initiate
queries to discover already active ZigBee devices in the network.
The request is either an IEEE address request, which is unicast, or
a NWK address request, which is broadcast. When the unicast request
is sent, it assumes the NWK address is known. When the broadcast
request is sent, it carries the known IEEE address as payload. The
response on these queries is dependent on the three device types
mentioned above: ZED, ZR and ZC. The ZED responds to the query by
sending its own IEEE or NWK address. The ZR responds to the query
by sending its own IEEE or NWK as well as the IEEE and NWK address
of all the other devices connected to the ZR. The ZC responds to
the query by sending its own IEEE or NWK as well as the IEEE and
NWK address of all the other devices connected to the ZC.
There are 3 different key types used in ZigBee; master key, link
key and network key. The master key is used as basis for long term
communication between devices, and can be either factory installed
or be set up over the air or using out-of-band mechanisms. The link
key is used for security between two devices. The link key is also
used to authenticate devices to the coordinator device. The network
key is used for security in a network. The link and network keys
can be factory installed, be set up using a symmetric key-key
exchange handshake or be sent from the trust center.
A wide range of ZigBee transceivers that are suited for use in a
wireless sensor are available on the commercial market, from
suppliers like ChipCon, CompXs, Helicomm Inc. and others. Newer
models can come with built in hardware support for data encryption
and authentication using AES on the link layer. An example of such
a chip is the ChipCon CC2510. ChipCon "CC2510 Product Information"
www.chipcon.com/index.cfm?kat_id=2&subkat_id=12&dok_id=258
(online May 24, 2006). The CC2510 is a powerful 2.4 GHz ISM band
System-on-Chip designed for low-power and low-voltage wireless
communication applications. This chip includes a dedicated 128-bit
AES coprocessor to minimize the MCU usage when encrypting. It also
has a dedicated DMA controller which moves data from a peripheral
(in our case the sensor) to the memory with almost no intervention
from the MCU. This way the MCU workload is reduced to a minimum.
The chip has a 32 kB of programmable flash memory and 4 kB of RAM.
This chip is developed to be energy efficient and have a low unit
cost.
The ZigBee device installed in the PDA will most likely be an SD or
CF card. Since our PDA must have a GPRS card, which usually is a CF
card, the ZigBee card will be an SD card. An example of a ZigBee SD
card is produced by C-Guys. C-GUYS www.c-guysusa.com (online May
24, 2006). They are a company that specializes in developing
different SD and SDIO devices, such as SD controllers, memory
cards, adapters and card readers. One of their products is a ZigBee
SDIO card for use in PDA. The SDIO card is using the standard
ZigBee frequency, the 2.4 GHz ISM band, has 250 kbps data rate and
10-meter range.
GSM offers several security services (Schiller, J. (2003) Mobile
Communications, second edition, Addison-Wesley, pages 93-156), and
they are found either in the SIM card or the AuC (authentication
center, a separate system in the network that contains the
algorithms for authentication and the keys for encryption). The SIM
card stores personal data and a secret key Ki, and is only accessed
with a four-digit PIN number. After MS authenticates itself, the MS
and BTS (base transceiver station) encrypts all voice and data.
There are 3 types of algorithms: A3 for authentication, A5 for
encryption and A8 for generation of the cipher key. The algorithms
are very weak, but it is possible for the network providers to use
stronger algorithms for encryption or user can provide stronger
end-to-end encryption. To encrypt the messages, a key Kc is created
by using the individual key Ki and a random number by generated by
the A8 algorithm. The Kc key is calculated both in the MS (SIM) and
the network, and is not transmitted over the air interface.
GPRS (general packet radio service) is a packet-oriented operation
in the GSM system, often called 2.5G, since the technology lies
somewhere between 2G and 3G (2nd and 3rd generation mobile
technology). en.wikipedia.org/wiki/GPRS (May 24, 2006). The idea
behind GPRS is Wikipedia.org "GPRS" that all or some GSM-channels
(time slots) are combined to one channel with higher capacity.
Schiller, J. (2003) Mobile Communications, second edition,
Addison-Wesley, pages 93-156. While GSM was primarily designed for
voice transmission, GPRS is a more data-oriented transmission. The
transmission is packet-oriented so that many users can transfer
data when they need it, and don't use bandwidth when they have
nothing to send. This type of transmission is especially designed
for frequent transmission of small volumes of data, e.g., typical
web requests or web response. The overall goal is the provision of
a more effective and cheaper packet transfer for typical Internet
applications that rely solely on packet transfer. The ISP is
usually taking charge for the data volume transferred instead of
charging for the connection time. Andersen P. B. og R. Johnsen
"Mobiltelefon--Ikke bare prat" in (Ed.) Kunnskapsforlagets
.ANG.rbok 2000 fag.grm.hia.no/ragnarj/mobile_syst/tradlos_komm.pdf.
By doing it this way, the user is "always on", and no connection
has to be set up for the transfer.
For each new GPRS radio channel, the GSM can locate between one and
eight time slots within a TDMA frame. Schiller, J. (2003) Mobile
Communications, second edition, Addison-Wesley, pages 93-156. All
time slots can be shared by the active users. It is possible to get
a transfer rate to 170 kbit/s if you have max slots and are using
the fastest coding, but a more realistic bit rate is 30-80 kbit/s.
Wikipedia.org "GPRS" en.wikipedia.org/wiki/GPRS (May 24, 2006).
CS-4 is the fastest coding scheme, but the least robust. This
coding is available near the Base Transceiver Station (BTS). CS-1
is the slowest coding scheme but is most robust and is available
when the Mobile Station (MS) is further away from the BTS. The GPRS
operators usually reserves at least one-time slot per cell to
guarantee a minimum data rate. Users can specify a QoS-profile
themselves. This determines the service precedence (high, normal,
low), reliability class and delay class of the transmission and
user data throughput. The latency of GPRS is incurred by channel
access delay, coding for error correction, and transfer delay in
the fixed and wireless parts of the network. Due to these parts
involved, the latency is very high, even with small packet sizes. A
round trip is often higher than 1 sec, even with packets as small
as 128-bytes. Table 2 shows some examples of the delay classes with
different service data units (SDU) sizes. A MS (Mobile Station)
that are using GPRS are considered a part of the internet and are
assigned a private IP address. The operator translates the IP
address into global addresses at the GGSN (Gateway GPRS support
node) using a NAT (Network Address translation). The advantage of
this approach instead of giving the MS an "ordinary" IP address is
to protect the MS against attacks. The private IP addresses are not
routed through the internet, so it is impossible to reach an MS
from the internet. Other security mechanisms are the same as
GSM.
EDGE (enhanced data rates for GSM evolution) is a digital
enhancement of GSM, and the next step towards 3G and UMTS (EDGE is
also called 2.75G, Wikipedia.org, "2.75G"
en.wikipedia.org/wiki/2.75G (Mar. 23, 2006)). EDGE is using an
enhanced modulation scheme and other techniques to get data rates
up to 384 kbit/s using the same carrier size and frequencies as
GSM. EDGE does not require any changes in the GSM core networks,
but the base stations have to be upgraded. Wikipedia.org "EDGE"
en.wikipedia.org/wiki/EDGE (May 24, 2006). Besides better data
rate, the most important addition to GSM is CAMEL (customized
application for mobile enhanced logic). CAMEL is an intelligent
network support, and the services offered are especially effective
when a subscriber is roaming between international network
operators. Meskauskas, P., "Customised Applications for Mobile
Enhanced Logic (CAMEL)". Examples are no-prefix dialing and
seamless MMS messages from other countries. EDGE is backward
compatible with GPRS, and will use GPRS as transmission in those
areas without EDGE support. Norway's largest telecommunication
company, Telenor, has very good national EDGE coverage (Telenor
Dekningskart telenormobil.no/dekninginnland/index.do (online May
25, 2006)
www.telenor.no/bedrift/produkter/mobil/merom_umts_edge.html), and
offers a download rate of 100-200 kbit/s and upload rate of 50-75
kbit/s.
UMTS (universal mobile telecommunication system) is a third
generation mobile technology used in Europe and Japan, and the 3G
successor of GSM. Wikipedia.org "UMTS" en.wikipedia.org/wiki/UMTS
(May 23, 2006). To avoid very high implementation cost, UMTS try to
reuse as much GSM/GPRS technology and infrastructure as possible.
It is especially designed for high-speed services like video
telephony. All signals use the same frequency band, a 5 MHz wide
band licensed to network operators. The signals are multiplied with
a chipping sequence which is unique to each user. If someone tries
to tap the signal, it would appear as noise to him if he doesn't
know the spreading code. In its initiation phase, UMTS has a
theoretical bit rate of 384 kbit/s in high mobility situations, and
up to 2 Mbit/s in stationary user environments. UMTS Forum, "What
is UMTS?"
www.umts-forum.org/servlet/dycon/ztumts/umts/Live/en/umts/What+is+UMTS_in-
dex (online May 25, 2006). It takes twice as many base stations as
GSM to achieve the same coverage, and to get fully fledged UMTS
features including Video on Demand, a base station need to be set
up every 1-1.5 km. Some of the downsides of UMTS (as it is today)
are: very poor coverage, poor battery life on the MS, impossible to
provide complete UMTS features in rural areas, and lack of consumer
demand for 3G.
Hash functions are the most versatile of all cryptographic
primitives. Bishop, M.
(2003) Computer Security Art and Science, Addison-Wesley. It can be
used for encryption, authentication, and a simple digital
signature. The typical use of a hash function is digital
signatures. The idea behind hashing is to take a long string of
bits (or bytes) as input, run a hash function, and produce a fixed
length hash sum. Mao, W. (2004) Modern Cryptography Theory &
Practice, Bristol, Prentice Hall. If you have a message (m) and a
hash (h), you are signing h(m) instead of signing m. The reason for
signing h(m) is that the message (m) are usually very large, up to
millions of bits, but the hash functions are usually between 128
and 256 bits, thus making it much faster and more effective. One of
the practical problems with selecting a hash function, is that
there's only a couple methods to choose from Wikipedia.org
"Cryptographic Hash Function"
en.wikipedia.org/wiki/Cryptographic_hash_function (Apr. 25, 2006);
the SHA family and MD5. There are a couple of alternatives, but
they have not been tested thoroughly enough to trust them. A
typical hash function is shown below. MD5 is a cryptographic hash
function used to verify data integrity. Rivest, R. (1992), MIT
laboratory for Computer Science and RSA Data security, Inc. April
1992. It was developed by Ronald Rivest in 1991 to replace MD4,
because MD4 proved to have some security weakness. When using MD5,
the message is split into blocks of 512 bits. Answers.com "MD5"
www.answers.com/topic/md5#after_ad1 (online May 25, 2006). The last
block is padded, and includes the length of the message. MD5 has
128-bit hash value that is split into four words of 32 bits, each
with a compression function h' with four rounds. Each round mix the
message block and the state, with a combination of addition, XOR,
AND, OR and rotation operations on 32-bit words. This way each
message word is used four times. After the four rounds of the h'
function, the input state and the result are added together to
produce the output of h'. The structure of operating 32-bits words
is very efficient on 32-bits CPUs.
One of the basic ideas behind hash functions is that it is
collision resistant. As of 2006, there were no known attacks on the
MD5 function, but a collision of the compression function occurred
in 1996. For modern applications, the 128-bit hash size is
insufficient, and it is possible to find real collisions in about
264 evaluations of the hash function. This made security experts to
recommend a replacement. One of them was SHA-1. SHA (Secure Hash
Algorithm, Wikipedia.org "SHA Hash functions"
en.wikipedia.org/wiki/SHA (May 6, 2006)) is a set of cryptographic
hash functions. The first standard was just called SHA, but is now
referred to as SHA-0. It was developed in 1993 by NSA (National
Secure Agency) and published as a US government standard. It was
found a weakness in this function, and NSA developed a fix which
they published as an improved version called SHA-1.
SHA-1 (National Institute of Standards and Technology (1995)
"Secure Hash Standard" www.itl.nist.gov/fipspubs/fip180-1.htm
(online May 25, 2006)) is the successor of SHA-0 (and MD5)
(Wikipedia.org "SHA Hash functions" en.wikipedia.org/wiki/SHA (May
6, 2006)), and was developed in 1995. It is used in a wide area of
security applications, like TLS, SSL, PGP, SSH, S/MIME, and IPSec.
SHA-0 and SHA-1 is based on the same principles as MD4 and MD5, and
produces a 160-bit message digest with a maximum size of 264 bits.
It is, unfortunately, 2-3 times slower than MD5. SHA-1 has a
160-bit state consisting of five 32-bit words. It uses four rounds
that consist of a mixture of 32-bit operations. SHA-1 uses a linear
recurrence to stretch the 16 words of a message block to the 80
words it needs, to ensure that each message bit affects the mixing
function at least a dozen times.
The main problem with SHA-1 is the 160-bit result size. Collisions
can be generated in only 280 steps, but it is reported that it can
be generated in as few as 263 steps. Schneier, B. (2005), "New
Cryptanalytic Results Against SHA-1"
www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html (Aug.
17, 2005).
3TDES has following specification: Three 56-bit DES keys=168
bits+parity bits=192 bits. The effectiveness is counted as only 112
bits because of the exposure to the man-in-the-middle attacks. The
best know attack on the 3TDES requires 232 known plaintexts, 2113
steps, 290 single DES encryptions and 288-bit memory. 3TDES is no
longer considered a very good encryption method. It is being
replaced by its successor, AES with its better security mechanisms.
AES has a larger block size, longer keys, freedom from crypto
analytic attacks, and proves to be up to six times faster than
3TDES.
Advanced Encryption Standard (AES, Wikipedia.org "Advanced
Encryption Standard"
en.wikipedia.org/wiki/Advanced_Encryption_Standard (May 24, 2006)),
also known as Rijndael is a block cipher. In 2000 NIST, National
Institute of Standards and Technology, chose Rijndael as the new
encryption standard for the US government. NIST selected the
Rijndael algorithm in front of 4 other competitors based on the
combination of security, performance, efficiency, ease of
implementation and flexibility. Rijndael is a block cipher and uses
a substitution-linear transformation network with 10, 12 or 14
rounds, depending on the key and block size. The key and block size
can be individually specified to 128, 192 or 256-bits. A data block
to be encrypted by Rijndael is split into an array of bytes, and
each encryption operation is byte-oriented. Only block size of
128-bits is adopted in the AES standard. The AES does not describe
how to handle and distribute keys, and need a secure key management
infrastructure to maintain its high level of security. AES is about
6 times faster than 3DES in software implementations.
AES is a block cipher with a fixed block size of 128 bits and a
variable key size of 128, 192 or 256 bits. The 128-bit message
input block is segmented into 16 bytes. The data structure for
their internal representation is a 4.times.4 matrix. Like the DES
algorithm, AES comprises a plural number of iterations of a basic
unit of transformation: "round". Depending on the size of the key,
AES uses 10, 12 or 14 rounds. A round transformation in AES is
denoted by: Round (State, RoundKey). State is a round-message
matrix, and is treated as both input and output and a length of 128
bits; RoundKey is a round-key and is derived from the input-key via
key schedule. All round-keys are 128-bits, also when the encryption
key is 192 or 256-bits. The key schedule is an algorithm for
computing the sub-keys for each round in a product cipher from the
encryption (or decryption) key. The execution of a round will cause
the elements in of State to change value. For encryption the State
input to the first round is the plaintext message matrix, and the
output from the last round is the cipher text message matrix. For
decryption they are respectively cipher text and plaintext message
matrix. Each round, except the last round, consists of 4 stages: 1.
SubBytes; 2. ShiftRows; 3. MixColumns; and 4. AddRoundKey. All
rounds are identical with the exception of the final round, which
does not include the MixColumns transformation. The round
transformations are invertible for the purpose of decryption.
The SubBytes function provides a non-linear substitution on each
byte of State. In the SubBytes step, each byte in the array is
updated using an 8-bit S-box. A substitution box (or S-box) is a
basic component of symmetric key algorithms, and takes some number
of input bits, m, and transforms them into some number of output
bits, n. This operation provides the non-linearity in the cipher.
The S-box used is derived from the inverse function over GF(28),
known to have good non-linearity properties. Non-linearity is an
important property for a block cipher to prevent differential
cryptanalysis. The ShiftRows step operates on the rows of the
state; it cyclically shifts the bytes in each row by a certain
offset. For AES, the first row is left unchanged. Each byte of the
second row is shifted one to the left. Similarly, the third and
fourth rows are shifted by offsets of two and three respectively.
In this way, each column of the output state of the ShiftRows step
is composed of bytes from each column of the input state. In the
MixColumns step, the four bytes of each column of the state are
combined using an invertible linear transformation. The MixColumns
function takes four bytes as input and outputs four bytes, where
each input byte affects all four output bytes. Each column is
treated as a polynomial over GF(28) and is then multiplied modulo
x4+1 with a fixed polynomial c(x)=3.times.3+.times.2+.times.+2.
ShiftRows and MixColumns are intended to achieve a mixture of the
bytes positioned in different places of a plaintext message block.
In the AddRoundKey step, the subkey is combined with the state. For
each round, a subkey is derived from the main key using the key
schedule; each subkey is the same size as the state. The subkey is
added by combining each byte of the state with the corresponding
byte of the subkey using bitwise XOR. This stage provides necessary
secret randomness to the message distribution. To decrypt, the 4
functions of each round are inverted, and implemented in reverse
order. The AddRoundKey is its own inverse and the same for both
encryption and decryption. Three different key lengths, 128, 192,
and 256 are supported by AES, making it possible to choose stronger
security or better efficiency. All key lengths are secure enough to
be used for most levels of classified information. Only for extreme
security requirements is it required to use 192 or 256-bit key
lengths. The American National Security Agency has conducted a
research on the strength of the AES algorithm (CNSS (2003) "CNSS
Policy No. 15, Fact Sheet No. 1. National Policy on the Use of the
Advanced Encryption Standard (AES) to Protect National Security
Systems and National Security Information") stating: "The design
and strength of all key lengths of the AES algorithm (i.e., 128,
192 and 256) are sufficient to protect classified information up to
the SECRET level. TOP SECRET information will require use of either
the 192 or 256-bit key lengths."
Public Key Infrastructure (PKI) is a policy to establish a secure
method for information exchange. Bishop, M. (2003) Computer
Security Art and Science, Addison-Wesley. It is also a set of
integrated services and administrative tools to create and manage
applications based on public keys. This includes cryptographic
methods, the use of digital certificates, certification
authorities, and the system to manage the process. There are two
key elements in PKI: Public Key Cryptography and Certification
Authorities (CA). Public Key Cryptography is a form of cryptography
and uses a pair of cryptographic keys designed as a private key and
a public key, which are related mathematically. The private key is
kept secret by the user and the public key may be widely
distributed. Generally, if user Bob shall send a message to user
Alice, Bob will contact Alice and ask for her public key. Alice
sends Bob her public key, and Bob uses it to encrypt his message.
Bob will then send Alice the message, encrypted with Alice's public
key, and the only way to decrypt the message is to use Alice's
private key. Borthus, B and Tomas, E. (2005), "Public Key
Infrastructure for Windows Server 2003".
Some examples of public key techniques are: Diffie-Hellmann, DSS,
ElGamal, RSA, and various Elliptic Curve techniques. Wikipedia.org
"Public Key Infrastructure" (May 26, 2006).
A CA is responsible for establishing and vouching for the identity
of certificate holders. A CA also revokes certificates if they are
no longer valid and publishes certificate revocation lists (CRLs)
to be used by certification verifiers. The certificates are issued
by a CA based on information provided in the certification request
and settings contained in a certification template. A certification
template is the set of rules and settings that are applied against
incoming certificate requests. The most common digital certificates
in PKI use the X.509 Digital Certificate format and usually contain
the following: The user's public key; The user's identity, such as
name and e-mail address; The validity period of the certificate;
The digital signature of the issuer, which attest to the validity
of the binding between the user's public key and the user's
identifier information. There are different levels of certificates
based on the need for functions. As a general rule, the higher
level of the certificate, the stricter are the policies for
verifying. PKI supports hashing to keep the integrity of the
data.
Smart cards are pocket sized plastic cards with embedded integrated
circuits. There are 2 broad categories of cards; memory cards and
microprocessor cards. The standardization of smart card systems is
an ongoing process. One of the standards most referred to is the
ISO-7816 standard. A memory card contains non-volatile memory that
can store information and perhaps some specific non-programmable
security logic. An example of a memory card is a prepaid phone
card. They can also be used as a high security alternative to
magnetic stripe cards. Memory cards can only perform fixed
operations. Microprocessor cards contain memory and microprocessor
components. These cards can process data on the card and can used
for a variety of applications. Microprocessor cards can provide
secure access to networks, be used as SIM card in mobile phones and
as electronic wallets. Smart cards are engineered to be tamper
resistant and are very suitable to hold personal digital signatures
that can be used as authentication to grant access to secure
networks. Hong Kong University of Science & Technology (1998)
"Guide to Smart Card Technology".
The definition of VPN is "A virtual private network (VPN) is a
private data network that makes use of the public telecommunication
infrastructure, maintaining privacy through the use of a tunneling
protocol and security procedures". VPN Consortium (2006) "VPN
Technologies: Definitions and Requirements"
www.vpnc.org/vpn-technologies.html. A VPN makes it possible to
share resources in a secure way over an insecure public network
like the Internet. There are 3 important VPN technologies used:
secure, trusted and hybrid VPN. Only secure VPN is relevant to our
scenario. Secure VPN uses an encrypted secure "tunnel" to transport
data over a public network. Tunneling is generally done by
encapsulating the private network data and protocol information
within the public network transmission units so that the private
network protocol information appears to the public network as data.
Tunneling allows the use of the Internet, to convey data on behalf
of a private network in a secure way. There are several secure VPN
protocols, like IPsec, SSL and PPTP. A properly chosen,
implemented, and used secure VPN protocol can provide secure
communications over unsecured networks, and provide protection of
confidentiality and integrity, and sender authentication to ensure
privacy.
Secure authentication is very important when using a VPN solution.
Authentication mechanisms can make use of what you know (pin code,
password), what you have (smart card) or what you are (fingerprint,
retinal scan). Wikipedia.org "Virtual private network"
en.wikipedia.org/wiki/Virtual_Private_Network (May 25, 2006). The
use of one of the above will give weak authentication, but the use
of two will give a much stronger authentication.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a prior art system architecture.
FIG. 2 shows a prior art network architecture.
FIG. 3 shows a schematic diagram of a system according to the
present invention.
DESCRIPTION OF THE INVENTION
The preset invention provides a medical device, which may be an
implantable device, having a low power communication transceiver
with limited communication range. The medical device includes its
own processor configured to establish and communicate through an
encrypted secure channel which tunnels over a network connection.
For example, a virtual private network (VPN) is provided. This VPN
then communicates with a predetermined endpoint through potentially
insecure public channels and infrastructure.
The technology provides, for example, an implantable medical
device, comprising: a self-contained power source (e.g., a battery,
supercapacitor, fuel cell, nuclear cell, energy harvesting system,
etc.); at least one programmable automated electronic processor; a
wireless radio frequency digital communication radio transceiver; a
digital memory; and a physiological interface adapted to at least
one of receive a physiological signal, produce a physiological
stimulation, produce a motion or displacement, infuse a drug, and
acquire a biological sample, wherein the at least one programmable
automated electronic processor is configured to communicate using a
potentially insecure channel with a relay device, and through the
relay device establish a secure communication tunnel to a plurality
of different endpoints on a public network, and being configured to
respond to a request for opening a communication channel with a
respective endpoint based on a received message, the plurality of
different endpoints each being associated with a respective
security certificate to implement a private key infrastructure, the
at least one programmable automated electronic processor being
configured to verify a the respective security certificate against
a certificate revocation list prior to transmitting private data or
accepting receiving data as valid.
Electronic medical device may include cardiac monitors, pacemakers,
defibrillators, neurological stimulators, pain control devices,
artificial or assistive sensory technologies (hearing aids, optic
stimulators to restore vision, etc.), insulin and other drug
infusion pumps, bladder control stimulators, etc.
In one embodiment, the medical device supports an IEEE-802.11x
protocol; however, these tend to be power consuming, and often have
communication bandwidth and capabilities not required for a medical
device. The medical device may have a strictly limited power
budget, making such communications imprudent. However, in certain
circumstances, an 802.11b or 802.11g communications might be
appropriate. Further, in some configurations, external power might
be available during communications.
In another embodiment, a Bluetooth protocol, IEEE 802.15.1 is
employed. Bluetooth employs a 2.4 GHz band (2400-2480 MHz).in a
frequency hopping spread spectrum protocol having 79 channels each
with a bandwidth of 1 MHz. The protocol uses Gaussian
frequency-shift keying (GFSK) modulation (Bluetooth 1.0),
.pi./4-DQPSK and 8DPSK (Bluetooth 2.0+EDR) modulation supporting 1,
2 or 3-Mbits/sec communications. While Bluetooth communications
employ security, this typically is only between paired
communication partners or small subnets.
Other protocols may be employed; however, it is important that the
protocol comprise error detection and correction, tunneling
encryption, and low power. Because implantable medical electronics
may endure for many years, it may be important that the endpoint of
the tunneling encryption be updatable in a secure manner.
Therefore, each implantable medical device has its own digital
certificate, and only through a key exchange process will the
device open a communications channel. Typically, VPN's are locked
to particular endpoints. However, this potentially limits
availability of access to the device in emergencies, and permits a
central point of failure. Meanwhile, providing a special
"administrative access" mode which bypasses the VPN with a lower
security level effectively reduces the net security of the device
to that lower level plus any vulnerabilities in the VPN
implementation. While there are advantages in having a fully
standards-based IP-SEC VPN mode of operation, the purpose of the
encrypted communication is to provide privacy and security, and any
vulnerability leads to a reduction in these.
In an emergency, such as a central point of failure, bankruptcy or
government action to interrupt services, IP filtering, or the like,
it is desirable to provide a secure and private mode of access to
the device which permits both downloading of information from the
device and uploading operational parameters and commands to the
device. An implantable medical device typically has only a
rudimentary local user interface, which may be a magnetic field,
mechanical pressure, or other physical effect, but preferably there
is no required local user interface at all; that is a physician or
other trained and authorized medical service provided can remotely
access the device, receive data from the device, and upload data to
the device, without required user intervention at the device.
As discussed above, a smartphone or other internet or
network-connected device serves as a relay. According to one
premise, these relay devices are not themselves medical devices,
and may include vulnerabilities and therefore should not be
presumed secure in all aspects. For example, requiring the user to
input a personal identification number (PIN) or password through a
smartphone to authorize access to the device might lead to release
of the PIN or password by a keystroke logger or other malicious
software on the phone, or if the phone must further communicate the
PIN or password, it could be intercepted in transmission. It is
possible for the device to authenticate the relay device based on
an authentication protocol, independent of the formation of the VPN
channel to a remote endpoint, but some relay infrastructure, such
as wireless access points, do not support customized apps or such
authentication, and indeed, these may be in fact truly insecure and
security-compromised.
Therefore, the device operates by periodically polling its
environment for available communications relays, and may in fact
operate in a multiprotocol manner. If it finds a suitable partner,
it then selects a "best" partner (or may indeed select multiple
partners), and establishes a communication link. Typically, the
device will seek to establish the lowest power consumption reliable
link available. Various ad hoc networking technologies may be
employed to balance link reliability and power consumption.
After a link is established, the device then communicates through
the link, which acts as a router, to an Internet connected resource
or other resource available through the link. In order to ensure
compatibility, preferably IPv4 and/or IPv6 communications protocols
are employed, generally with TCP. The device seeks to communicate
with a registration server or distributed registration server, in
which the device authenticates the server, and the server
identifies and authenticates the device. Once the handshake
authentication, which may employ a Kerberos-type cryptographic
protocol, is complete, a message stored in the server is processed
by the server, and/or is communicated to the device, representing a
request for communication. That is, for example, a service provider
may have a pending request to download a data file from the device.
That request identifies the service provider and other parameters
of the request. The device then seeks to form a communication
channel, through the link, with the identified service provider
based on the identification. A token may be communicated from the
registration server to the device, which is then used as part of a
protocol to establish the communication channel; however, it is
preferred that the mutual authentication of the device and the
service provider be conducted directly through these two
communication partners. The device seeks to authenticate the
service provider to ensure privacy of the communication, etc. The
service provider, however, seeks to authenticate the device in
order to avoid uploading malicious data that may incur costs and/or
lead to changes in functioning of the device that is party to the
communication, or another device that is being spoofed.
Once the device and service provider establish a communication
link, which will generally be encrypted and secure, e.g., a VPN,
communications, up to and including a full exchange of information,
may be conducted, depending on various security rules and
administrative limits. A certificate exchange protocol is provided
to mutually authenticate the device and service provider. The
device stores a set of certificates for a set of authorized
communications partners. An emergency override is provided only
upon physical access to the device, such as by activating a
magnetic reed switch, or generating a unique pseudo-physiological
signal that can be recognized by an internal controller.
The authorized communications partners may be, for example, the
manufacturer (which itself may serve as a root certificate
authority), the patient's physician, the patient's hospital, an
on-line service which maintains the device, etc. In some cases,
multiple authorized communications partners may be required to
concur on a change to be made to the device operational parameters.
This serves to limit mistakes, and also control system
security.
For example, an implantable pacemaker-defibrillator device
maintains an EKG record for the patient for an extended duration,
e.g., 1 month, as well as various events and determinations. After
some period of time, for example 3 weeks, the device seeks to
download its archive to free storage space and permit medical
monitoring. The implantable device therefore enters a mode where it
seeks suitable communications relays, and may produce a signal
perceptible by the patient for the patient to make a relay
available. The device uses a Bluetooth protocol to find a Bluetooth
compatible device configured to accept the relay communication. For
example, the user has a smartphone that has an application
installed that listens for the device communications (or
proactively communicate with the device). If the device fails to
find a compatible device, over an acceptable period of time, it may
shift to a different protocol, for example Zigbee or 802.11b/g/n.
An 802.11n protocol requires a higher power mode of operation, but
may permit communications over a shorter duration. After finding a
suitable relay, the device handshakes to establish a link, but does
not necessarily require a secure or reliable link. The device then
uses the relay to commence negotiation of a virtual private network
with at least one of its predetermined endpoints. The link is
established based on both an address of the endpoint (i.e., IPv4 or
IPv6 address), and secret information which acts as a cryptographic
key, wherein the secret itself is not communicated between the
partners. The authentication is mutual.
In some cases, after an analysis of the data, a medical
professional or automated device may determine that the parameters
of operation of the device require updating. In that case, both the
treating physician/cardiologist and manufacture (or authorized
service provider) may be required to concur on the proposed
changes. Typically, the dual authorization is ensured by the
device, and the authorization does not rely on one party to offer
proof of authorization by the other. Therefore, the device uploads
the proposed changes to the parameters, and then communicates with
the other authorizing party the proposed changes. This dual
communication paradigm may incur higher energy consumption or
inconvenience, but limits the risk of collusion or breach of
security.
Once the parameters are updated and dual-authorized, the device may
then adopt and use the new parameters.
In some cases, it is the certificates maintained in the device that
require updating. In that case, the device typically uses a public
key infrastructure key hierarchy management system, to manage key
importing, expiration, revocation, and use.
Since the relay device, e.g., smartphone is generally near to the
patient, in some cases, there is significant incentive to trust
that device and therefore increase communications and power
efficiency. One way to achieve trusted operation is for the
smartphone to enter a mode where the existence of malware or
unpatched vulnerabilities are detectable, and therefore that in an
absence of either, the local processor can be permitted access to
private information and/or control over sensitive parameters. For
example, the execution of a program by the smartphone can be
checkpointed and compared against a set of known-good checkpoints
for the same code, or the code interspersed with "generic"
sequences that are also executed remotely on a reference platform,
and the results compared. In this case, the results to be analyzed
are not necessarily the regular output of the program, but memory
pages, executing timing, and other indicia of the nature of the
software environment. If unauthorized software is concurrently
executing, its presence will be made known by changes in timing of
execution, content or hash signatures of memory pages, etc.
The present technology seeks to exploit the known state of the art
in virtual private networks. The following references are therefore
cited and expressly incorporated by reference in their entirety:
Pulkkis, Goran, et al. "Security of Symbian Based Mobile Devices."
Advances in Enterprise Information Technology Security (2007): 31.
Koponen, Pekka, et al. "Interfaces of consumption metering
infrastructures with the energy consumers." VTT Research Notes 2542
(2010). Ross, David Andrew. "Securing IEEE 802.11 wireless LANs."
(2010). Ph.D. Thesis Queensland University (2010). Fischer, Martin.
"Enhancing the ReMoteCare prototype by adding an SNMP proxy and
video surveillance." (2008). University of Techn., Sydney.
Pankakoski, Veikko. "Experimental design for a next generation
residential gateway." (2010). M.S. Thesis Aalto University (2010).
5246008; 6292659; 6643650; 6700535; 6721542; 6744753; 6772331;
6789077; 6789126; 6792466; 6810363; 6813501; 6845097; 6850979;
6862594; 6868447; 6879574; 6885388; 6886095; 6898445; 6898618;
6908391; 6912657; 6916247; 6917976; 6918084; 6922725; 6925562;
6945870; 6947995; 6948066; 6950875; 6950946; 6961541; 6965868;
6968453; 6970869; 6973493; 6975205; 6980660; 6990444; 7010573;
7016966; 7028184; 7031945; 7042988; 7065574; 7065579; 7072967;
7080078; 7082200; 7084736; 7089089; 7089298; 7096137; 7103313;
7110372; 7116661; 7120667; 7121639; 7136927; 7146307; 7152942;
7155518; 7162454; 7165107; 7165824; 7167892; 7167920; 7171323;
7181572; 7181614; 7185199; 7188251; 7188282; 7197565; 7200848;
7203665; 7203753; 7206841; 7206934; 7213047; 7215775; 7216109;
7216231; 7216365; 7222187; 7243356; 7249182; 7251331; 7254608;
7260538; 7260543; 7262709; 7263560; 7263612; 7275102; 7275156;
7278034; 7278697; 7280975; 7283803; 7290132; 7293047; 7295119;
7297062; 7299007; 7302592; 7308496; 7312721; 7318049; 7318086;
7328243; 7339914; 7340214; 7340438; 7340500; 7340770; 7343350;
7346167; 7348895; 7356329; 7366901; 7370091; 7377608; 7379891;
7379913; 7383433; 7386517; 7392375; 7392387; 7395333; 7395536;
7398533; 7399043; 7401152; 7401153; 7409434; 7409569; 7412518;
7415424; 7415439; 7415537; 7418593; 7420956; 7421411; 7424285;
7426271; 7426721; 7433649; 7433773; 7444644; 7454542; 7454619;
7458082; 7461172; 7475244; 7477873; 7484225; 7487509; 7500104;
7509387; 7512649; 7516325; 7522549; 7523111; 7529713; 7533141;
7533161; 7533172; 7536177; 7536723; 7545941; 7546254; 7548946;
7549056; 7562028; 7562051; 7565328; 7565529; 7570943; 7571346;
7573855; 7574523; 7577575; 7577619; 7577620; 7577834; 7581096;
7584360; 7587196; 7590589; 7592829; 7596227; 7597250; 7599305;
7600252; 7606242; 7606570; 7607012; 7613881; 7617159; 7624143;
7630941; 7634230; 7649872; 7657255; 7657597; 7660990; 7660998;
7672662; 7680133; 7684374; 7689508; 7697894; 7698393; 7701912;
7702821; 7703073; 7707415; 7707621; 7708194; 7712111; 7712777;
7715351; 7716492; 7724717; 7730482; 7733804; 7743074; 7747980;
7748618; 7757076; 7760654; 7761863; 7761885; 7761910; 7762470;
7770008; 7774495; 7778927; 7783041; 7783777; 7783886; 7787865;
7788663; 7801058; 7801781; 7804807; 7818519; 7818811; 7822863;
7823772; 7831238; 7831752; 7831827; 7844834; 7848746; 7849140;
7853255; 7853780; 7860922; 7860923; 7864673; 7869601; 7870097;
7881667; 7886962; 7899187; 7899915; 7904074; 7907935; 7916861;
7920518; 7920534; 7920851; 7937089; 7944577; 7945959; 7950047;
7953818; 7962164; 7970894; 7974234; 7974296; 7975002; 7975051;
7978062; 7979692; 7983615; 7983835; 7986704; 7987491; 7990947;
7991764; 8000314; 8001232; 8005476; 8009608; 8013732; 8014722;
8019352; 8023425; 8028329; 8031650; 8032939; 8036195; 8037202;
8038239; 8046328; 8046504; 8050405; 8064412; 8064879; 8064926;
8068831; 8073839; 8082491; 8090399; 8103691; 8103718; 8108455;
8116734; 8117547; 8127039; 8130146; 8131645; 8135796; 8136149;
8139588; 8144725; 8145219; 8149848; 8150312; 8150372; 8150416;
8151336; 8156337; 8159985; 8160077; 8161172; 8165142; 8166296;
8166551; 8171136; 8171292; 8175528; 8179911; 8182340; 8185119;
8193930; 8195233; 8195934; 8200195; 8200700; 8204522; 8204992;
8212667; 8213907; 8214228; 8214645; 8223010; 8224893; 8225094;
8225380; 8226474; 8228861; 8229785; 8229812; 8229813; 8229888;
8233471; 8234387; 8245315; 8249028; 8249559; 8250207; 8250628;
8260274; 8260320; 8261338; 8266212; 8266438; 8266676; 8270310;
8270952; 8271800; 8271802; 8275395; 8275672; 8279067; 8280359;
8281169; 8284748; 8289886; 8290498; 8296825; 8301784; 8302167;
8305935; 8305936; 8305980; 8311214; 8311939; 8316091; 8316438;
8320879; 8321330; 8321526; 8321534; 8322607; 8326958; 8327131;
8331901; 8335222; 8335304; 8341141; 8341291; 8341292; 8345881;
8346248; 8347088; 8347093; 8351898; 8352342; 8352636; 8353052;
8355337; 8359016; 8359397; 8364961; 8369830; 8370236; 8373556;
8375202; 8379564; 8380982; 8381262; 8385240; 8385916; 8386394;
8392289; 8395498; 8396458; RE42725; RE42871; 20020069278;
20020072975; 20020075844; 20020133534; 20020143655; 20020143855;
20020143944; 20020147771; 20020147810; 20020152299; 20020161476;
20020184310; 20020184311; 20020184357; 20020184358; 20020188657;
20030002521; 20030041141; 20030065525; 20030087629; 20030093691;
20030100369; 20030100370; 20030100371; 20030100372; 20030229900;
20040019807; 20040030743; 20040030794; 20040031038; 20040031058;
20040044727; 20040064512; 20040064568; 20040064693; 20040073795;
20040088347; 20040088348; 20040088369; 20040088646; 20040098447;
20040133640; 20040148326; 20040162871; 20040198220; 20050086300;
20050109841; 20050129240; 20050141706; 20050144437; 20050233811;
20050259611; 20050261970; 20050273850; 20060002331; 20060010251;
20060010485; 20060040248; 20060041445; 20060041446; 20060041460;
20060041891; 20060062206; 20060092043; 20060095199; 20060156054;
20060167784; 20060174017; 20060208066; 20060219776; 20060234678;
20060282662; 20060291455; 20070004436; 20070022474; 20070022479;
20070025245; 20070025265; 20070060099; 20070060109; 20070060114;
20070060129; 20070060136; 20070060173; 20070061197; 20070061198;
20070061211; 20070061229; 20070061242; 20070061243; 20070061244;
20070061245; 20070061246; 20070061247; 20070061300; 20070061301;
20070061302; 20070061303; 20070061317; 20070061328; 20070061331;
20070061332; 20070061333; 20070061334; 20070061335; 20070061336;
20070061363; 20070073717; 20070073718; 20070073719; 20070073722;
20070073723; 20070087756; 20070094042; 20070097885; 20070100650;
20070100651; 20070100652; 20070100653; 20070100805; 20070100806;
20070118533; 20070136817; 20070143629; 20070143827; 20070143851;
20070156895; 20070168354; 20070169184; 20070171885; 20070192294;
20070192318; 20070198432; 20070198485; 20070239724; 20070260635;
20070263783; 20070288427; 20070293323; 20080009268; 20080032801;
20080033869; 20080041937; 20080052769; 20080063201; 20080076572;
20080092181; 20080095180; 20080097858; 20080098212; 20080109879;
20080141360; 20080167954; 20080183853; 20080222715; 20080229402;
20080234047; 20080242279; 20080252485; 20080256618; 20090013380;
20090016529; 20090036111; 20090046591; 20090046598; 20090046644;
20090046676; 20090046861; 20090047930; 20090047966; 20090049158;
20090060201; 20090073943; 20090088133; 20090119741; 20090119776;
20090168990; 20090199009; 20090204805; 20090204964; 20090254572;
20090254646; 20090275403; 20090281872; 20090319672; 20090320073;
20090322510; 20090327729; 20100057801; 20100076845; 20100082430;
20100082431; 20100094981; 20100095077; 20100099396; 20100100930;
20100115606; 20100121705; 20100131618; 20100131619; 20100131622;
20100131652; 20100132040; 20100138293; 20100138296; 20100138908;
20100138926; 20100142410; 20100145804; 20100146146; 20100150170;
20100153208; 20100153211; 20100169179; 20100186078; 20100188975;
20100188990; 20100188991; 20100188992; 20100188993; 20100188994;
20100188995; 20100190470; 20100191575; 20100191576; 20100191604;
20100191612; 20100191613; 20100191846; 20100191847; 20100192120;
20100192170; 20100192207; 20100192212; 20100192220; 20100197266;
20100197268; 20100198681; 20100211458; 20100211645; 20100217662;
20100217663; 20100235285; 20100235879; 20100250497; 20100269146;
20100275250; 20100281364; 20100293051; 20100293221; 20100299522;
20100299763; 20100304737; 20100317420; 20110004513; 20110015993;
20110015994; 20110019627; 20110029378; 20110029387; 20110047062;
20110106614; 20110145076; 20110159902; 20110167474; 20110194698;
20110202874; 20110216674; 20110217966; 20110219234; 20110219419;
20110230268; 20110231936; 20110246766; 20110258046; 20110273568;
20110275393; 20110276673; 20110277028; 20110289308; 20110289314;
20110302408; 20110307710; 20110312310; 20110313862; 20110320264;
20110320265; 20110320266; 20110320267; 20110320268; 20110320269;
20110320270; 20110320271; 20110320279; 20110320280; 20110320281;
20110320282; 20110321127; 20120004984; 20120004985; 20120004986;
20120004987; 20120004988; 20120004989; 20120004990; 20120004991;
20120004992; 20120004993; 20120004994; 20120004995; 20120004996;
20120004997; 20120004998; 20120004999; 20120005000; 20120005001;
20120005002; 20120005003; 20120005004; 20120005005; 20120005006;
20120005007; 20120005008; 20120005009; 20120005010; 20120005011;
20120005012; 20120005013; 20120005014; 20120005020; 20120005077;
20120005078; 20120005079; 20120005080; 20120005081; 20120005082;
20120005083; 20120005084; 20120005085; 20120005086; 20120005087;
20120005088; 20120005089; 20120005090; 20120005091; 20120005092;
20120005725; 20120005726; 20120010945; 20120010946; 20120010947;
20120010948; 20120010949; 20120010950; 20120010951; 20120010952;
20120010953; 20120010954; 20120010955; 20120010956; 20120010957;
20120010958; 20120010959; 20120010960; 20120010961; 20120010962;
20120010963; 20120010964; 20120010965; 20120010966; 20120010967;
20120010968; 20120010969; 20120010970; 20120010971; 20120010972;
20120010973; 20120010974; 20120010975; 20120010976; 20120010977;
20120010978; 20120010979; 20120011058; 20120015644; 20120016925;
20120027001; 20120030470; 20120032945; 20120036010; 20120036220;
20120036245; 20120036440; 20120036442; 20120036552; 20120041819;
20120054848; 20120059711; 20120059718; 20120066057; 20120066065;
20120066198; 20120066199; 20120069131; 20120084544; 20120084545;
20120084562; 20120084566; 20120084838; 20120086345; 20120087319;
20120088470; 20120089699; 20120089845; 20120094769; 20120096513;
20120101831; 20120101832; 20120101833; 20120101834; 20120101835;
20120101836; 20120102143; 20120105199; 20120105201; 20120105214;
20120109667; 20120109668; 20120109669; 20120109670; 20120109671;
20120109672; 20120109673; 20120109674; 20120109851; 20120110602;
20120116790; 20120116959; 20120118947; 20120122528; 20120122529;
20120122558; 20120129503; 20120130811; 20120130812; 20120131685;
20120134291; 20120150629; 20120158607; 20120159438; 20120159578;
20120185390; 20120190386; 20120191860; 20120192249; 20120195206;
20120195222; 20120195223; 20120196565; 20120197709; 20120197724;
20120197792; 20120201133; 20120203677; 20120204245; 20120208496;
20120209750; 20120210130; 20120210391; 20120210401; 20120214441;
20120215831; 20120216225; 20120222123; 20120232945; 20120232970;
20120238255; 20120240183; 20120240196; 20120240236; 20120254474;
20120259981; 20120284416; 20120294195; 20120297464; 20120323717;
20120323786; 20120324067; 20120324242; 20120324562; 20120330829;
20130003613; 20130005299; 20130005322; 20130006729; 20130006780;
20130007837; 20130010945; 20130012178; 20130014263; 20130016636;
20130024254; 20130024257; 20130024262; 20130024267; 20130024364;
20130024371; 20130034230; 20130040703; 20130045710; 20130054820;
20130054962; 20130055315; 20130055347; 20130061264; 20130061273;
20130065551; 20130066723; 20130067023; and 20130067526.
If several different applications or data need to be secured
between the devices, it often makes sense to apply a suitable VPN
(Virtual Private Network) technology. VPN can protect the data
communication interfaces from malicious attacks by dropping all
inadequate data traffic, and also provides the secure tunneling for
insecure protocols and data to traverse securely over various
networks. A useful information and comparison of various VPN
protocols is available e.g. in NIST SP 800-77 "Guide to IPSec
VPNs", Chapter 5.
Transport Layer Security (TLS)--IETF RFC5246 can cryptographically
protect the information that the OSI transport layer 4 delivers. It
can provide adequate security with: Payload data authentication,
integrity verification and encryption; Replay protection; and
Public key certificate based mutual authentication of the peers.
The strength of the algorithms and key lengths are negotiated in
the beginning of a secure TLS session, using a special handshake
protocol. The handshakes can utilize public key certificates and
cryptography (e.g. DSS, RSA) also for mutual authentication
(server+client certificates), when necessary. The cryptographic key
and policy negotiation messaging is rather well secured in TLS
specification and most implementations. Also, the strength of the
strongest user data "Cipher-Suites" are very good (AES, 3DES, etc.
are supported with long keys). Also, the Datagram Transport Layer
Security (DTLS)--IETF RFC4347 is a protocol that travels within the
transport layer PDU. So, both TLS and DTLS can traverse NATs and
provide easy and secure device data exchanges without securing the
transport layer or lower layers. This allows for example any
client/server applications to communicate in straightforward way.
DTLS over the Datagram Congestion Control Protocol (DCCP)--IETF
RFC5238 is also one possible protocol to be considered.
Security Architecture for the Internet Protocol--IPSec (IETF
RFC4301-4309) is a family of protocols (of which AH and ESP are
implemented at TCP/IP stack's network layer, or at least under
transport layer). IPSec can provide adequate security in flexible
ways using: IP header and payload data authentication, integrity
verification and encryption (only ESP); Replay protection; and
Public key certificate or shared secrets based mutual
authentication of the peers. The IPsec architecture consists of a
number of specifications: Security Architecture for the Internet
Protocol (IETF RFC4301); IP Authentication Header (AH) (IETF
RFC4302); IP Encapsulating Security Payload (ESP) (IETF RFC4303);
Internet Key Exchange (IKEv2) Protocol (IETF RFC4306);
Cryptographic Algorithms for Use in the Internet Key Exchange
Version 2 (IKEv2) (IETF RFC4307); Cryptographic Suites for IPsec
(IETF RFC4308); Using Advanced Encryption Standard (AES) CCM Mode
with IPsec Encapsulating Security Payload (ESP) (IETF RFC4309);
Cryptographic Algorithm Implementation Requirements for ESP and AH
(IETF RFC4835). The tunnel mode ESP (and IKE) are used in the
construction of IPSec based Virtual Private Networks (VPNs).
However, IKE is a rather resource consuming protocol for secure
connection establishment with its complex ISAKMP message exchanges,
but it is a scalable way to establish the secure connections
between different parties of the infrastructure.
An alternative approach is to utilize even stronger, lower-layer
security protocol to provide the security services for SNMP. For
example, RFC5590 defines an extension which allows an "external"
security protocol to be used with SNMP engines. Potential external
protocols include TLS and SSH (RFC4251).
A transport layer Stream Control Transmission Protocol (SCTP)--IETF
RFC4960 is quite a recent, reliable protocol providing for
independent message streams: May use TLS/SSL or run over IPsec;
Congestion avoidance behavior; Protection against flooding attacks
(lightweight mutual authentication). Delivery mechanisms include:
Sequential non-duplicated delivery of messages for each independent
stream and Immediate delivery (bypassing the sequential
delivery).
The Secure Real-time Transport Protocol (SRTP)--IETF RFC3711
defines a RTP (Real-time Transport Protocol) profile which provides
for unicast and multicast RTP data security to be used as a stream
cipher: Segmented Integer Counter Mode: AES with 128-bit key as
default; f8-mode: AES with 128-bit key as default; Authentication,
integrity and replay protection: HMAC-SHA1 as truncated to 80 or
32-bits size; Hashing over the payload and the header including
sequence number. There are several possible choices that can be
used for the negotiation and derivation of cryptographic keys that
SRTP will need. Alternatives include: MIKEY (RFC3830: Multimedia
Internet KEYing); SDES (RFC4568: Session Description Protocol (SDP)
Security Descriptions for Media Streams); ZRTP (IETF Draft: Media
Path Key Agreement for Secure RTP).
Bluetooth provides a secure way to connect and exchange information
between devices such as faxes, mobile phones, telephones, laptops,
personal computers, printers, Global Positioning System (GPS)
receivers, digital cameras, and video game consoles. It was
principally designed as a low-bandwidth technology.
A master Bluetooth device can communicate with a maximum of seven
devices in a piconet (an ad-hoc computer network using Bluetooth
technology), though not all devices reach this maximum. The devices
can switch roles, by agreement, and the slave can become the master
(for example, a headset initiating a connection to a phone will
necessarily begin as master, as initiator of the connection; but
may subsequently prefer to be slave).
The Bluetooth Core Specification provides for the connection of two
or more piconets to form a scatternet, in which certain devices
simultaneously play the master role in one piconet and the slave
role in another. At any given time, data can be transferred between
the master and one other device (except for the little-used
broadcast mode). The master chooses which slave device to address;
typically, it switches rapidly from one device to another in a
round-robin fashion. Since it is the master that chooses which
slave to address, whereas a slave is (in theory) supposed to listen
in each receive slot, being a master is a lighter burden than being
a slave. Being a master of seven slaves is possible; being a slave
of more than one master is difficult. The specification is vague as
to required behavior in scatternets.
The effective range varies due to propagation conditions, material
coverage, production sample variations, antenna configurations and
battery conditions. In most cases the effective range of Class 2
devices is extended if they connect to a Class 1 transceiver,
compared to a pure Class 2 network. This is accomplished by the
higher sensitivity and transmission power of Class 1 devices.
To use Bluetooth wireless technology, a device has to be able to
interpret certain Bluetooth profiles, which are definitions of
possible applications and specify general behaviors that Bluetooth
enabled devices use to communicate with other Bluetooth devices.
These profiles include settings to parametrize and to control the
communication from start. Adherence to profiles saves the time for
transmitting the parameters anew before the bi-directional link
becomes effective. There are a wide range of Bluetooth profiles
that describe many different types of applications or use cases for
devices.
Bluetooth and Wi-Fi (the brand name for products using IEEE 802.11
standards) have some similar applications: setting up networks,
printing, or transferring files. Wi-Fi is intended as a replacement
for cabling for general local area network access in work areas.
This category of applications is sometimes called wireless local
area networks (WLAN). Bluetooth was intended for portable equipment
and its applications. The category of applications is outlined as
the wireless personal area network (WPAN). Bluetooth is a
replacement for cabling in a variety of personally carried
applications in any setting and also works for fixed location
applications such as smart energy functionality in the home
(thermostats, etc.).
Wi-Fi is a wireless version of a common wired Ethernet network, and
requires configuration to set up shared resources, transmit files,
and to set up audio links (for example, headsets and hands-free
devices). Wi-Fi uses the same radio frequencies as Bluetooth, but
with higher power, resulting in higher bit rates and better range
from the base station. The nearest equivalents in Bluetooth are the
DUN profile, which allows devices to act as modem interfaces, and
the PAN profile, which allows for ad-hoc networking. Bluetooth
v2.1+EDR has a data rate of about 3 Mbit/s, although the practical
data transfer rate is 2.1 Mbit/s. EDR uses a combination of GFSK
and Phase Shift Keying modulation (PSK) with two variants,
.pi./4-DQPSK and 8DPSK. EDR can provide a lower power consumption
through a reduced duty cycle. Bluetooth v3.0+HS provides
theoretical data transfer speeds of up to 24 Mbit/s, though not
over the Bluetooth link itself. Instead, the Bluetooth link is used
for negotiation and establishment, and the high data rate traffic
is carried over a collocated 802.11 link. The main new feature is
AMP (Alternate MAC/PHY), the addition of 802.11 as a high speed
transport. Bluetooth Core Specification version 4.0 includes
Classic Bluetooth, Bluetooth high speed and Bluetooth low energy
protocols. Bluetooth high speed is based on Wi-Fi, and Classic
Bluetooth consists of legacy Bluetooth protocols. Bluetooth low
energy (BLE), previously known as WiBree, is a subset to Bluetooth
v4.0 with an entirely new protocol stack for rapid build-up of
simple links. As an alternative to the Bluetooth standard protocols
that were introduced in Bluetooth v1.0 to v3.0, it is aimed at very
low power applications running off a coin cell. Chip designs allow
for two types of implementation, dual-mode, single-mode and
enhanced past versions. The provisional names Wibree and Bluetooth
ULP (Ultra Low Power) were abandoned and the BLE name was used for
a while. In late 2011, new logos "Bluetooth Smart Ready" for hosts
and "Bluetooth Smart" for sensors were introduced as the
general-public face of BLE. General improvements in version 4.0
include the changes necessary to facilitate BLE modes, as well the
Generic Attribute Profile (GATT) and Security Manager (SM) services
with AES Encryption.
Many of the services offered over Bluetooth can expose private data
or allow the connecting party to control the Bluetooth device. For
security reasons it is necessary to be able to recognize specific
devices and thus enable control over which devices are allowed to
connect to a given Bluetooth device. At the same time, it is useful
for Bluetooth devices to be able to establish a connection without
user intervention (for example, as soon as they are in range).
To resolve this conflict, Bluetooth uses a process called bonding,
and a bond is created through a process called pairing. The pairing
process is triggered either by a specific request from a user to
create a bond (for example, the user explicitly requests to "Add a
Bluetooth device"), or it is triggered automatically when
connecting to a service where (for the first time) the identity of
a device is required for security purposes. These two cases are
referred to as dedicated bonding and general bonding respectively.
Pairing often involves some level of user interaction; this user
interaction is the basis for confirming the identity of the
devices. Once pairing successfully completes, a bond will have been
formed between the two devices, enabling those two devices to
connect to each other in the future without requiring the pairing
process in order to confirm the identity of the devices. When
desired, the bonding relationship can later be removed by the
user.
During the pairing process, the two devices involved establish a
relationship by creating a shared secret known as a link key. If a
link key is stored by both devices, they are said to be paired or
bonded. A device that wants to communicate only with a bonded
device can cryptographically authenticate the identity of the other
device, and so be sure that it is the same device it previously
paired with. Once a link key has been generated, an authenticated
Asynchronous Connection-Less (ACL) link between the devices may be
encrypted so that the data that they exchange over the airwaves is
protected against eavesdropping. Link keys can be deleted at any
time by either device. If done by either device this will
implicitly remove the bonding between the devices; so it is
possible for one of the devices to have a link key stored but not
be aware that it is no longer bonded to the device associated with
the given link key. Bluetooth services generally require either
encryption or authentication, and as such require pairing before
they allow a remote device to use the given service. Some services,
such as the Object Push Profile, elect not to explicitly require
authentication or encryption so that pairing does not interfere
with the user experience associated with the service use-cases.
Pairing mechanisms have changed significantly with the introduction
of Secure Simple Pairing in Bluetooth v2.1.
Bluetooth implements confidentiality, authentication and key
derivation with custom algorithms based on the SAFER+ block cipher.
Bluetooth key generation is generally based on a Bluetooth PIN,
which must be entered into both devices. This procedure might be
modified if one of the devices has a fixed PIN (e.g., for headsets
or similar devices with a restricted user interface). During
pairing, an initialization key or master key is generated, using
the E22 algorithm. The E0 stream cipher is used for encrypting
packets, granting confidentiality, and is based on a shared
cryptographic secret, namely a previously generated link key or
master key. Those keys, used for subsequent encryption of data sent
via the air interface, rely on the Bluetooth PIN, which has been
entered into one or both devices.
Bluetooth is susceptible to denial-of-service attacks,
eavesdropping, man-in-the-middle attacks, message modification, and
resource misappropriation. The present technology addresses these
security limitations (except for denial-of-service attacks) by
providing a security layer which tunnels through the Bluetooth
link, and therefore does not rely on the Bluetooth security
protocols.
Bluetooth uses the microwave radio frequency spectrum in the 2.402
GHz to 2.480 GHz range. Maximum power output from a Bluetooth radio
is 100 mW for class 1, 2.5 mW for class 2, and 1 mW for class 3
devices. Even the maximum power output of class 1 is a lower level
than the lowest powered mobile phones.
See:
"Bluetooth.org". Bluetooth.org.
www.bluetooth.org/About/bluetooth_sig.htm.
"Bluetooth Radio Interface, Modulation & Channels".
Radio-Electronics.com.
www.radio-electronics.com/info/wireless/bluetooth/radio-interface-modulat-
ion.php.
"How Bluetooth Technology Works". Bluetooth SIG. Archived from the
original on 17 Jan. 2008.
"Specification Documents". Bluetooth.com. 30 Jun. 2010.
www.bluetooth.com/Specification%20Documents/AssignedNumbersServiceDiscove-
ry.pdf
"IEEE Std 802.15.1-2002--IEEE Standard for Information
technology--Telecommunications and information exchange between
systems--Local and metropolitan area networks--Specific
requirements Part 15.1: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Wireless Personal Area
Networks (WPANs)".
ieeexplore.ieee.org. doi:10.1109/IEEESTD0.2002.93621.
ieeexplore.ieee.org/servlet/opac?punumber=7932.
"IEEE Std 802.15.1-2005--IEEE Standard for Information
technology--Telecommunications and information exchange between
systems--Local and metropolitan area networks--Specific
requirements Part 15.1: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Wireless Personal Area
Networks (W Pans)".
ieeexplore.ieee.org. doi:10.1109/IEEESTD.2005.96290.
ieeexplore.ieee.org/servlet/opac?punumber=9980.
"Specification Documents". Bluetooth SIG. www.bluetooth.org.
"Bluetooth Core Version 3.0+HS specification".
www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=40560.
"Bluetooth Core Specification Addendum (CSA) 1".
www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=119993.
D. Chomienne, M. Eftimakis (20 Oct. 2010). "Bluetooth Tutorial"
(PDF). www.newlogic.com/products/Bluetooth-Tutorial-2001.pdf.
Juha T. Vainio (25 May 2000). "Bluetooth Security". Helsinki
University of Technology. www.iki.fi/jiitv/bluesec.pdf.
Andreas Becker (16 Aug. 2007) (PDF). Bluetooth Security &
Hacks. Ruhr-Universitat Bochum.
gsyc.es/.about.anto/ubicuosa2/bluetooth_security_and_hacks.pdf.
Scarfone, K., and Padgette, J. (September 2008) (PDF). Guide to
Bluetooth Security. National Institute of Standards and Technology.
csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf.
"Security Weaknesses in Bluetooth". RSA Security
Conf.--Cryptographer's Track. CiteSeerX: 10.1.1.23.7357.
Ford-Long Wong, Frank Stajano, Jolyon Clulow (2005-04) (PDF).
Repairing the Bluetooth pairing protocol. University of Cambridge
Computer Laboratory. Archived from the original on 16 Jun. 2007.
web.archive.org/web/20070616082657/www.cl.cam.ac.uk/.about.fw242/publicat-
ions/2005-WongStaClu-bluetooth.pdf.
VPN Connectivity Overview (See Wikipedia)
A virtual private network (VPN) extends a private network and the
resources contained in the network across public networks like the
Internet. It enables a host computer to send and receive data
across shared or public networks as if it were a private network
with all the functionality, security and management policies of the
private network. This is done by establishing a virtual
point-to-point connection through the use of dedicated connections,
encryption, or a combination of the two. The VPN connection across
the Internet is technically a wide area network (WAN) link between
the sites but appears to the user as a private network link--hence
the name "virtual private network".
VPNs can be either remote-access (connecting an individual computer
to a network) or site-to-site (connecting two networks together).
In a corporate setting, remote-access VPNs allow employees to
access their company's intranet from home or while traveling
outside the office, and site-to-site VPNs allow employees in
geographically separated offices to share one cohesive virtual
network. A VPN can also be used to interconnect two similar
networks over a dissimilar middle network; for example, two IPv6
networks over an IPv4 network.
VPNs typically require remote access to be authenticated and make
use of encryption techniques to prevent disclosure of private
information. VPNs provide security through tunneling protocols and
security procedures such as encryption. Their security model
provides: Confidentiality such that even if traffic is sniffed, an
attacker would only see encrypted data which they cannot
understand; (see Packet analyzer and Deep packet inspection);
Allowing Sender authentication to prevent unauthorized users from
accessing the VPN; Message integrity to detect any instances of
transmitted messages having been tampered with.
Secure VPN protocols include the following:
IPSec (Internet Protocol Security) was developed by the Internet
Engineering Task Force (IETF), and was initially developed for
IPv6, which requires it. This standards-based security protocol is
also widely used with IPv4. Layer 2 Tunneling Protocol frequently
runs over IPSec. Its design meets most security goals:
authentication, integrity, and confidentiality. IPSec functions
through encrypting and encapsulating an IP packet inside an IPSec
packet. De-encapsulation happens at the end of the tunnel, where
the original IP packet is decrypted and forwarded to its intended
destination.
Transport Layer Security (SSL/TLS) can tunnel an entire network's
traffic, as it does in the OpenVPN project, or secure an individual
connection. A number of vendors provide remote access VPN
capabilities through SSL. An SSL VPN can connect from locations
where IPsec runs into trouble with Network Address Translation and
firewall rules.
Datagram Transport Layer Security (DTLS), is used in Cisco
AnyConnect VPN or OpenConnect VPN, to solve the issues SSL/TLS has
with tunneling over UDP.
Microsoft Point-to-Point Encryption (MPPE) works with the
Point-to-Point Tunneling Protocol and in several compatible
implementations on other platforms.
Microsoft's Secure Socket Tunneling Protocol (SSTP), introduced in
Windows Server 2008 and in Windows Vista Service Pack 1. SSTP
tunnels Point-to-Point Protocol (PPP) or
Layer 2 Tunneling Protocol traffic through an SSL 3.0 channel.
MPVPN (Multi Path Virtual Private Network).
Secure Shell (SSH) VPN--OpenSSH offers VPN tunneling (distinct from
port forwarding) to secure remote connections to a network or
inter-network links. OpenSSH server provides a limited number of
concurrent tunnels and the VPN feature itself does not support
personal authentication. "ssh(1)--OpenBSD manual pages".
man.openbsd.org; c @cb.vu, Colin Barschel. "Unix Toolbox". cb.vu;
"SSH_VPN--Community Help Wiki". help.ubuntu.com.
Tunnel endpoints must authenticate before secure VPN tunnels can be
established. User-created remote access VPNs may use passwords,
biometrics, two-factor authentication or other cryptographic
methods. Network-to-network tunnels often use passwords or digital
certificates, as they permanently store the key to allow the tunnel
to establish automatically and without intervention from the
user.
The following steps illustrate the principles of a VPN
client-server interaction in simple terms. Assume a remote host
with public IP address 1.2.3.4 wishes to connect to a server found
inside a company network. The server has internal address
192.168.1.10 and is not reachable publicly. Before the client can
reach this server, it needs to go through a VPN server/firewall
device that has public IP address 5.6.7.8 and an internal address
of 192.168.1.1. All data between the client and the server will
need to be kept confidential, hence a secure VPN is used. The VPN
client connects to a VPN server via an external network interface.
The VPN server assigns an IP address to the VPN client from the VPN
server's subnet. The client gets internal IP address 192.168.1.50,
for example, and creates a virtual network interface through which
it will send encrypted packets to the other tunnel endpoint (the
device at the other end of the tunnel). (This interface also gets
the address 192.168.1.50.) When the VPN client wishes to
communicate with the company server, it prepares a packet addressed
to 192.168.1.10, encrypts it and encapsulates it in an outer VPN
packet, say an IPSec packet. This packet is then sent to the VPN
server at IP address 5.6.7.8 over the public Internet. The inner
packet is encrypted so that even if someone intercepts the packet
over the Internet, they cannot get any information from it. They
can see that the remote host is communicating with a
server/firewall, but none of the contents of the communication. The
inner encrypted packet has source address 192.168.1.50 and
destination address 192.168.1.10. The outer packet has source
address 1.2.3.4 and destination address 5.6.7.8. When the packet
reaches the VPN server from the Internet, the VPN server
decapsulates the inner packet, decrypts it, finds the destination
address to be 192.168.1.10, and forwards it to the intended server
at 192.168.1.10. After some time, the VPN server receives a reply
packet from 192.168.1.10, intended for 192.168.1.50. The VPN server
consults its routing table, and sees this packet is intended for a
remote host that must go through VPN. The VPN server encrypts this
reply packet, encapsulates it in a VPN packet and sends it out over
the Internet. The inner encrypted packet has source address
192.168.1.10 and destination address 192.168.1.50. The outer VPN
packet has source address 5.6.7.8 and destination address 1.2.3.4.
The remote host receives the packet. The VPN client decapsulates
the inner packet, decrypts it, and passes it to the appropriate
software at upper layers. Overall, it is as if the remote computer
and company server are on the same 192.168.1.0/24 network.
Tunneling protocols can operate in a point-to-point network
topology that would theoretically not be considered a VPN, because
a VPN by definition is expected to support arbitrary and changing
sets of network nodes. But since most router implementations
support a software-defined tunnel interface, customer-provisioned
VPNs often are simply defined tunnels running conventional routing
protocols. According to the present technology, support for
arbitrary and changing sets of network nodes is preferably, but not
mandatorily, provided.
Depending on whether the PPVPN (Provider Provisioned VPN) runs in
layer 2 or layer 3, the building blocks described below may be L2
only, L3 only, or combine them both. Multiprotocol label switching
(MPLS) functionality blurs the L2-L3 identity. RFC 4026 generalized
the following terms to cover L2 and L3 VPNs, but they were
introduced in RFC 2547.
Mobile VPNs are used in a setting where an endpoint of the VPN is
not fixed to a single IP address, but instead roams across various
networks such as data networks from cellular carriers or between
multiple Wi-Fi access points. Mobile VPNs have been widely used in
public safety, where they give law enforcement officers access to
mission-critical applications, such as computer-assisted dispatch
and criminal databases, while they travel between different subnets
of a mobile network. They are also used in field service management
and by healthcare organizations, among other industries.
Increasingly, mobile VPNs are being adopted by mobile professionals
who need reliable connections. They are used for roaming seamlessly
across networks and in and out of wireless-coverage areas without
losing application sessions or dropping the secure VPN session. A
conventional VPN cannot survive such events because the network
tunnel is disrupted, causing applications to disconnect, time out,
or fail, or even cause the computing device itself to crash.
Instead of logically tying the endpoint of the network tunnel to
the physical IP address, each tunnel is bound to a permanently
associated IP address at the device. The mobile VPN software
handles the necessary network authentication and maintains the
network sessions in a manner transparent to the application and the
user. The Host Identity Protocol (HIP), under study by the Internet
Engineering Task Force, is designed to support mobility of hosts by
separating the role of IP addresses for host identification from
their locator functionality in an IP network. With HIP a mobile
host maintains its logical connections established via the host
identity identifier while associating with different IP addresses
when roaming between access networks.
OpenBSD ssh manual page, VPN section
Unix Toolbox section on SSH VPN
E. Rosen & Y. Rekhter (March 1999). "RFC 2547 BGP/MPLS VPNs".
Internet Engineering Task Forc (IETF).
www.ietf.org/rfc/rfc2547.txt.
Secure Shell (SSH) is a cryptographic network protocol for secure
data communication, remote shell services or command execution and
other secure network services between two networked computers that
connects, via a secure channel over an insecure network, a server
and a client (running SSH server and SSH client programs,
respectively). The protocol specification distinguishes between two
major versions that are referred to as SSH-1 and SSH-2. SSH uses
public-key cryptography to authenticate the remote computer and
allow it to authenticate the user, if necessary. Anyone can produce
a matching pair of different keys (public and private). The public
key is placed on all computers that must allow access to the owner
of the matching private key (the owner keeps the private key
secret). While authentication is based on the private key, the key
itself is never transferred through the network during
authentication. SSH only verifies whether the same person offering
the public key also owns the matching private key. Hence, in all
versions of SSH it is important to verify unknown public keys, i.e.
associate the public keys with identities, before accepting them as
valid. Accepting an attacker's public key without validation will
authorize an unauthorized attacker as a valid user.
SSH also supports password-based authentication that is encrypted
by automatically generated keys. In this case the attacker could
imitate the legitimate side, ask for the password and obtain it
(man-in-the-middle attack). However, this is only possible if the
two sides have never authenticated before, as SSH remembers the key
that the remote side once used. Password authentication can be
disabled. SSH is important in cloud computing to solve connectivity
problems, avoiding the security issues of exposing a cloud-based
virtual machine directly on the Internet. An SSH tunnel can provide
a secure path over the Internet, through a firewall to a virtual
machine.
The following RFC publications by the IETF "secsh" working group
document SSH-2 as a proposed Internet standard.
RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers; RFC
4251, The Secure Shell (SSH) Protocol Architecture; RFC 4252, The
Secure Shell (SSH) Authentication Protocol; RFC 4253, The Secure
Shell (SSH) Transport Layer Protocol; RFC 4254, The Secure Shell
(SSH) Connection Protocol; RFC 4255, Using DNS to Securely Publish
Secure Shell (SSH) Key Fingerprints; RFC 4256, Generic Message
Exchange Authentication for the Secure Shell Protocol (SSH); RFC
4335, The Secure Shell (SSH) Session Channel Break Extension; RFC
4344, The Secure Shell (SSH) Transport Layer Encryption Modes; RFC
4345, Improved Arcfour Modes for the Secure Shell (SSH) Transport
Layer Protocol; RFC 4419, Diffie-Hellman Group Exchange for the
Secure Shell (SSH) Transport Layer Protocol (March 2006); RFC 4432,
RSA Key Exchange for the Secure Shell (SSH) Transport Layer
Protocol (March 2006); RFC 4462, Generic Security Service
Application Program Interface (GSS-API) Authentication and Key
Exchange for the Secure Shell (SSH) Protocol (May 2006); RFC 4716,
The Secure Shell (SSH) Public Key File Format (November 2006); RFC
5656, Elliptic Curve Algorithm Integration in the Secure Shell
Transport Layer (December 2009).
The SSH-2 protocol has an internal architecture (defined in RFC
4251) with well-separated layers. These are:
The transport layer (RFC 4253). This layer handles initial key
exchange as well as server authentication, and sets up encryption,
compression and integrity verification. It exposes to the upper
layer an interface for sending and receiving plaintext packets with
sizes of up to 32,768 bytes each (more can be allowed by the
implementation). The transport layer also arranges for key
re-exchange, usually after 1 GB of data has been transferred or
after 1 hour has passed, whichever is sooner.
The user authentication layer (RFC 4252). This layer handles client
authentication and provides a number of authentication methods.
Authentication is client-driven: when one is prompted for a
password, it may be the SSH client prompting, not the server. The
server merely responds to the client's authentication requests.
Widely used user authentication methods include the following:
password: a method for straightforward password authentication,
including a facility allowing a password to be changed. This method
is not implemented by all programs.
publickey: a method for public key-based authentication, usually
supporting at least DSA or RSA keypairs, with other implementations
also supporting X.509 certificates.
keyboard-interactive (RFC 4256): a versatile method where the
server sends one or more prompts to enter information and the
client displays them and sends back responses keyed-in by the user.
Used to provide one-time password authentication such as S/Key or
SecurID. Used by some OpenSSH configurations when PAM is the
underlying host authentication provider to effectively provide
password authentication, sometimes leading to inability to log in
with a client that supports just the plain password authentication
method.
GSSAPI authentication methods which provide an extensible scheme to
perform SSH authentication using external mechanisms such as
Kerberos 5 or NTLM, providing single sign on capability to SSH
sessions. These methods are usually implemented by commercial SSH
implementations for use in organizations, though OpenSSH does have
a working GSSAPI implementation.
The connection layer (RFC 4254). This layer defines the concept of
channels, channel requests and global requests using which SSH
services are provided. A single SSH connection can host multiple
channels simultaneously, each transferring data in both directions.
Channel requests are used to relay out-of-band channel specific
data, such as the changed size of a terminal window or the exit
code of a server-side process. The SSH client requests a
server-side port to be forwarded using a global request.
The SSHFP DNS record (RFC 4255) provides the public host key
fingerprints in order to aid in verifying the authenticity of the
host.
This open architecture provides considerable flexibility, allowing
SSH to be used for a variety of purposes beyond a secure shell. The
functionality of the transport layer alone is comparable to
Transport Layer Security (TLS); the user authentication layer is
highly extensible with custom authentication methods; and the
connection layer provides the ability to multiplex many secondary
sessions into a single SSH connection, a feature comparable to BEEP
and not available in TLS.
These are intended for performance enhancements of SSH
products:
SSH-over-SCTP: support for SCTP rather than TCP as the connection
oriented transport layer protocol.
ECDSA: support for elliptic curve DSA rather than DSA or RSA for
signing.
ECDH: support for elliptic curve Diffie-Hellman rather than plain
Diffie-Hellman for encryption key exchange.
UMAC: support for UMAC rather than HMAC for MAC/integrity.
FIG. 3 shows a schematic diagram of an implantable medical device 6
according to the present invention. An implantable medical device 6
is implanted into a patient 1, having a wireless radio frequency
digital communication radio transceiver 4; a physiological
interface 2 adapted to at least one of receive a physiological
signal 22, produce a physiological stimulation 21, produce a motion
or displacement 23, infuse a drug 24, and acquire a biological
sample 25. The implantable medical device 6 is controlled by at
least one programmable automated electronic processor 3, having a
memory 5, configured to:
(a) communicate through the wireless radio frequency digital
communication radio transceiver 4 over an insecure physical channel
7 with a relay device, which may be smartphone 20, and through the
smartphone 20 to establish a cryptographically secure tunneling
protocol communication with each of a plurality of different
endpoints 11, 12 on a public network, e.g., medical information
servers, the plurality of different endpoints each having a
respective associated endpoint security certificate 13, 14, to
implement a public key infrastructure,
(b) respond to a request initiated from a respective one of the
plurality of different endpoints 11, 12, to open a
cryptographically secure tunneling protocol communication session
8, 9 according to the public key infrastructure with the respective
one of the plurality of different endpoints 11, 12, the request
being conveyed in at least one message received through the
insecure physical channel 7 by the wireless radio frequency digital
communication radio transceiver 4, and
(c) verify the respective associated endpoint security certificate
13, 14 of the respective one of the plurality of different
endpoints 11, 12, with respect to at least a certificate revocation
list 16 (downloaded from a certificate server 15), prior to
transmitting private medical data or accepting received medical
data as valid. The smartphone communicates through a cellular
network 10, which may interface to the Internet (not shown). The
insecure physical channel 7 may comprise a radio frequency
communication within at least one of an 870 MHz, 915 MHz, and 2.4
GHz communication band, and preferably the 2.4 MHz band. The
smartphone 20 may be configured to execute a smartphone app to
provide a local user interface with the at least one programmable
automated electronic processor 3.
The at least one programmable automated electronic processor 3 may
initiate a request to a respective one of the plurality of
different endpoints 11, 12, to open a cryptographically secure
tunneling protocol communication session 8, 8' according to the
public key infrastructure, by sending a message over the insecure
physical channel 7, which may be, e.g., a short range communication
protocol such as Bluetooth.RTM.. The at least one programmable
automated electronic processor 3 may encrypt information according
to the Advanced Encryption Standard (AES). The at least one
programmable automated electronic processor 3 may request the
certificate revocation list 16 from a certificate server 15 at a
certification authority through the insecure physical channel 7
with the relay device, and through the relay device (smartphone 20)
to the certification server 15 through cellular communication
channel 7' and communication network channel 7'' according to a
public key infrastructure hierarchy management system. The
cryptographically secure tunneling protocol communication 8, 8' may
be a virtual private network (VPN).
The implantable medical device may include a power supply 30 and a
rewritable memory 5 storing computer readable instructions for
controlling the at least one programmable automated electronic
processor to implement the public key infrastructure stored in the
rewritable memory, which are securely updatable through the
insecure physical channel.
The at least one programmable automated electronic processor 3 may
validate the smartphone 20 with respect to at least one of an
execution checkpoint, a hash of memory contents, and an execution
timing.
The figures and text herein describe methods and systems according
to various aspects of the invention. It will be understood that
each step described herein can be implemented by computer program
instructions. These computer program instructions may be loaded
onto a computer or other programmable apparatus to produce a
machine, such that the instructions which execute on the computer
or other programmable apparatus create means or devices for
implementing the described functions or step(s). These computer
program instructions may also be stored in a computer-readable
memory that can direct a computer or other programmable apparatus
to function in a particular manner, such that the instructions
stored in the computer-readable memory produce an article of
manufacture, including instruction means or devices which implement
the specified functions or step(s). The computer program
instructions may also be loaded onto a computer or other
programmable apparatus to cause a series of operational steps to be
performed on the computer or other programmable apparatus to
produce a computer implemented process such that the instructions
which execute on the computer or other programmable apparatus
provide steps for implementing the specified functions or
step(s).
It will also be understood that each step or combinations of steps
described herein can be implemented by special purpose
hardware-based computer systems which perform the specified
functions or steps, or combinations of special purpose hardware and
computer instructions.
The foregoing has described systems and methods for monitoring a
patient's heart. While specific embodiments of the present
invention have been described, it will be apparent to those skilled
in the art that various modifications thereto can be made without
departing from the spirit and scope of the invention. Accordingly,
the foregoing description of the preferred embodiment of the
invention and the best mode for practicing the invention are
provided for the purpose of illustration only and not for the
purpose of limitation, the invention being defined by the
claims.
* * * * *
References