Toward a Safe and Secure Medical Internet of Things
To operate using RTI’ s built-in security plugins, each DDS Domain Participant 1 requires 1) a public / private key pair, with the public key signed by a trusted certificate authority( referred to as the identity CA) forming an identity certificate, 2) permissions file signed by a trusted certificate authority( referred to as the permissions CA), 3) a DDS domain governance file, signed by the permissions CA, 4) an Identity certificate of the Identity CA, and 5) an Identity certificate of the Permissions CA. Figure 4 shows a possible deployment of DDS Security with two participants, P1 and P2. In an ICE setting, they could be an Oximeter and an ICE supervisor respectively.
The domain governance document is written in XML( eXtensible Markup Language), and specifies which DDS domains shall be protected, along with the details of the protection. The domain governance document is signed by the permissions CA and configures the following security aspects of the DDS domain: whether the discovery information should be protected and the kind of protection( MAC or ENCRYPT _ THEN _ MAC); whether liveliness messages should be protected; whether a discovered participant that cannot authenticate or fails authentication should be allowed to join the domain and see any data configured as unprotected; whether metadata( e. g., sequence numbers, heartbeats) should be protected and how; whether the payload should be protected and how; and whether read / write access to the topics should be open to all or restricted to the participants with proper permissions.
The XML permissions document contains the permissions of the domain participant, including which DDS domains it can join, what topics it can read or write, and what tags are associated with it.
4.4 Security Attacks on ICE When Run on Secure Transports
We implemented effective attacks against ICE when the Network Controller uses secure transports such as TLS or DTLS. Our attacks are based on ICE Infusion Safety App, which utilizes closed loop control of medical devices for safe delivery of patient controlled analgesia( PCA). The application controls the administration of IV medication and is programmed to stop the pump if it detects that the patient is in a non-normal state. Patient state is inferred from the readings of devices such as oximeters and capnographs. Figure 7 demonstrates a simplified ICE infusion safety application scenario, with topics published to or subscribed by various ICE components( see OpenICE Infusion Safety App Architecture [ 26 ] for further details).
1 A DDS domain is a concept used to bind individual applications together for communication. To communicate with
each other, DataWriters and DataReaders must have the same Topic of the same data type and be members of the same domain. Applications in one domain cannot subscribe to data published in a different domain. DomainParticipant objects enable an application to exchange messages within domains. DomainParticipants are used to create and use Topics, Publishers, DataWriters, Subscribers, and DataReaders in the corresponding domain.
- 14- June 2016