Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
  • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
  • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/80—Wireless
  • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

• This invention relates to addressable radio devices.
• a number of short-range radio communication protocols are known in which a master device communicates with a peripheral or slave device, e.g. to control the peripheral device and/or to receive data from it or to send data to it.
• Such protocols include Bluetooth, Bluetooth Low Energy, ANT and Zigbee.
• Such a radio device is typically an addressable device; i.e. it has an associated device address and is configured to respond (e.g. by performing an action or by transmitting a return message) to radio messages addressed to that device address (e.g. radio messages which contain the device address as part of the message). It will typically ignore at least some radio messages addressed to other devices in a system.
• a slave device might, for instance, be a wireless heart-rate monitor, which could be controlled by a user's mobile telephone, acting as a master device.
• the mobile telephone could collect heart-rate information from the monitor and display it for the user.
• Such radio devices typically have associated device addresses which are included in transmitted data packets in order to determine the sender and/or intended recipient of the data.
• a device address may be included in every data frame, or only at the beginning of an exchange, e.g. in an advertising message (after which some form of session or channel identifier may be used instead).
• FIG. 1 shows the structure of such a resolvable private address 1 .
• the address consists of a randomly generated 24-bit random number, prand, which is concatenated with a hash value, hash.
• prand a randomly generated 24-bit random number
• hash a hash value
• the two most-significant bits of prand always equal ⁇ ' and '1 ' as shown; the remaining bits are random and must not all equal ⁇ ' nor all equal T.
• hash is the 24 least-significant bits of the result of encrypting prand (zero-padded to 128 bits) using the Advanced Encryption Standard (AES) encryption algorithm with a device-specific 128-bit "Identity Resolving Key” (IRK).
• AES Advanced Encryption Standard
• IRS Identity Resolving Key
• the device can change its private address at regular intervals by generating a new value of prand and calculating a corresponding new hash value.
• the private address appears to be random data (with the exception of the two most-significant bits), such that the device cannot be consistently identified or tracked after each new change of address.
• the private address can still be used to determine the identity of the device by any other device with which the first device has previously shared its Identity Resolving Key (IRK).
• IRK Identity Resolving Key
• the second device On receiving a resolvable private address, the second device tries to decrypt the hash component using the IRK of each device known to it, in turn.
• a particular IRK results in a decrypted value that matches the prand component of the address, this reveals the identity of the first device, because the address must belong to the device whose IRK was successfully used.
• a slave device e.g. a heart-rate monitor
• an eavesdropper should be unable to identify or track the slave device (and the person carrying it) for any longer than the interval between address changes.
• a master device e.g. a mobile telephone
• an eavesdropper should be unable to identify or track the master device (and the person carrying it) for any longer than the interval between address changes.
• the invention provides an addressable radio device having an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device.
• a device uses an address based on a counter, which allows a new device address to be generated by incrementing the counter. Significantly, this allows old addresses to be readily distinguished from current and future addresses.
• a second, peered device on receiving an address of the first device, can check that the address is fresh by checking that the value in the address is derived from a higher value of the counter than was the case for an address used by the first device in an earlier communication with the second device.
• Such a check (or similar) can be used to reduce the opportunity for a privacy attack on the second device in which an attacker masquerades as the known, first device by transmitting a message containing a device address of the first device, acquired through prior
• the second device determines that the device address presented by the attacker is an old address, it can decide not to respond, thereby thwarting any attempt at identification or tracking.
• the invention can be viewed from various aspects.
• the invention provides a method of generating an address for an addressable radio device, the method comprising:
• the method preferably further comprises incrementing the counter.
• the invention provides a method of operating an addressable radio device, the method comprising the device transmitting by radio an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device.
• the address may be included in an advertising message.
• the invention provides a method of operating an addressable radio device, wherein the radio device has an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the device, the method comprising the device receiving and processing a radio transmission that includes the address of the radio device.
• the invention provides a method of operating a radio device, the method comprising the device receiving and processing a radio transmission, wherein the radio transmission includes an address of a second, sending radio device, and wherein the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the sending device.
• the first radio device may be addressable; i.e. it may be associated with a first device address and may be configured to respond to a radio message addressed to that device address (e.g. containing the address).
• Said radio transmission may also include an address of the first, receiving radio device, although this is not essential (e.g. the transmission may instead be an undirected advertising event).
• the device address may be contained in an advertising protocol data unit (PDU), scanning PDU or initiating PDU, substantially as defined in the Bluetooth Low Energy specifications (except for using the novel address format).
• the radio device preferably comprises means for calculating or generating the address, such as hardware logic and/or a microcontroller running software.
• the device is preferably configured to derive said value from the counter.
• the counter may be remote from the device, but the device preferably comprises the counter.
• the counter may be located in a common housing with radio transmitting and/or receiving means or logic of the device.
• the counter may comprise hardware and/or software configured to maintain and increment a count value. It may, for instance, comprise a number of flip-flops, or it may be
• the counter is preferably configured to store or maintain a current count value across multiple radio transmissions or sessions, which may include when other circuitry in the device is powered down or in a sleep state.
• the device may store a current count value in non-volatile memory, or it may be configured to maintain power to a counter memory while other circuitry in the device is powered down or asleep.
• a reset mechanism for the counter may be provided.
• the counter may count in any appropriate way. In preferred embodiments, it is a counter that increments through successive integer values.
• the value derived from the counter may simply be the current value of the counter. However, it may be some function of the value of the counter, such as a multiple of the output of the counter. In one preferred set of embodiments, the value is the output of the counter, with two appended bits: a "1 " in the next-to-most-significant bit position and a "0" in the most-significant bit position.
• the total length of the value may be 24 bits. Such a format can provide compatibility with existing Bluetooth Low Energy devices.
• the device is preferably configured to increment the counter. It may be configured to do this at regular intervals, or when a particular condition is met. This is explained in more detail below.
• the counter is preferably initiated to a starting value (e.g. zero) when the device is commissioned.
• the device may be configured to reset the counter to a starting value when a reset condition is met.
• the counter is preferably of sufficient capacity that, in normal usage, it will not roll over during the expected lifetime of the device.
• it may be a counter having at least 2 10 unique values, preferably at least 2 20 unique values. In a preferred set of embodiments, it is a 22-bit counter.
• the hash may take any suitable form.
• the device is preferably configured to apply a hash algorithm to the value and the identity-resolving key.
• the hash algorithm preferably acts on the value and the identity-resolving key to generate an output in such a way that it is infeasible or impossible to determine the key from the output.
• the hash is preferably such that it is infeasible or impossible, for a given output, to determine a value and key that would cause the function to generate this output.
• the hash preferably uses the Advanced Encryption Standard (AES) algorithm; preferably using the identity-resolving key as the encryption key (preferably a 128- bit key); and preferably to encrypt the value derived from the counter (which may be padded to an appropriate length as necessary, e.g. with zero bits).
• AES Advanced Encryption Standard
• the hash may be the truncated output of an encryption operations.
• the hash is a function of the output of an AES operation, such as comprising the 24 least- significant bits of the output. This can reduce the size of the total address, leading to more efficient transmission. It can also provide compatibility with existing
• the hash is preferably calculated as the "Random Address Hash function ah" in a Bluetooth Core Specification (e.g. version 4.0), where r is the value derived from the counter.
• the identity-resolving key may be a 128-bit number. It is preferably specific to the device. It may be stored in a memory of the device. Knowledge of the key by another device preferably allows that other device to determine the identity of the first device from the address.
• the nature and use of the identity-resolving key by devices embodying the present invention may be substantially as described for the identity-resolving keys in a Bluetooth Core Specification (e.g. version 4.0).
• the device is preferably configured to generate the address from the value derived from a counter.
• the address is preferably the value concatenated with the hash.
• a least significant octet of the hash may become the least significant octet of the address, while a most significant octet of the value may become the most significant octet of the address.
• the device may comprise a memory and may store the address in the memory.
• the device may have multiple addresses, but in at least some embodiments the device has only the one address.
• the device is preferably configured to operate substantially as a Bluetooth Low Energy device; i.e. as defined in a Bluetooth Core Specification (e.g. version 4.0).
• the device may be configured to transmit a radio message containing, e.g.
• Such a device may be configured to act as a slave device, e.g. substantially in accordance with a Bluetooth Low Energy slave role as defined in a Bluetooth Core Specification (e.g. version 4.0).
• the address may be encoded in any suitable way.
• the device may be configured to change its address at intervals by incrementing the counter; and preferably at regular intervals, e.g. about every 15 minutes.
• the device may be configured to act as a master device, e.g. substantially in accordance with a Bluetooth Low Energy master role as defined in a Bluetooth Core Specification (e.g. version 4.0). It may be configured to transmit a scanning or connection radio message that includes its address.
• Such a device may be configured to change its address by incrementing the counter after completing a connection establishment with a slave device.
• the device may also be configured to receive a radio message from a second device that includes an address of the second device, wherein the received address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the second device.
• the device may store one or more peer identity-resolving keys, associated with other radio devices. It may calculate a hash of the value in the received address using one of the peer identity-resolving keys, and may be configured to determine whether the calculated hash matches the hash in the received address. It may try each stored peer identity-resolving key until a match is found, thereby identifying the second device, or until all the keys have been tried without a match (if the device is unknown).
• the first device preferably stores a local count value associated with each peer device or identity-resolving key. After identifying the second device, the first device preferably uses the local count value to determine whether the value in the received address satisfies a predetermined freshness condition.
• the freshness condition may include that the received value is derived from a counter that is greater than the local count value. This can be used to ensure that an attacker is not mimicking the known device by replaying a captured address used previously by the device.
• the condition may also include that the received value is derived from a counter that is not more than a freshness threshold amount greater than the local count value. This freshness threshold can effectively set a limit on how long the second device can be out of communication with the first device and still satisfy the freshness condition.
• the freshness threshold may be around 35,000, which would correspond to about a year. It may, however, be much less than this, e.g. around 100 or 1 ,000, or it may be more, e.g. around 100,000 or more. Applying such a freshness threshold can limit the opportunity for an attacker to capture an address transmitted by the second device after its last communication with the first device and to use such an address to masquerade as the first device. If the freshness condition is not met, the device preferably rejects the radio transmission. If it is met, the local count value is preferably updated to correspond to the counter from which the value in the received address was derived, and further communication between the devices may proceed.
• the first device may increment a local count value at regular intervals, e.g. every 15 minutes; this may allow the local count value stored by a master device to remain approximately synchronised with a counter used by a second, slave device, which could further limit an attacker's opportunity to masquerade as the second device by allowing a smaller freshness threshold to be acceptable.
• the counter and/or a local count value may be stored using finite precision, e.g. 22 bits. It may be subject to modulo-arithmetic roll-over.
• a first value being "greater" than a second value may be given any appropriate definition in such contexts; e.g. the first value may be understood as being greater than the second if it is ahead of the second value by up to half, or some other suitable fraction, of the modulus.
• the invention provides a radio device configured to:
• a radio transmission that includes an address of a sending radio device, wherein the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the sending device;
• a radio device may itself have an address that comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity- resolving key for the device, but this is not essential. It may implement any of the optional features described above concerning freshness conditions.
• the invention provides a communication system comprising a first radio device and a second radio device, wherein the first radio device is configured to:
• the address comprises (i) a value derived from a counter and (ii) a hash of a combination of said value and an identity-resolving key for the first device,
• the second radio device is configured to:
• a radio device is preferably configured to send its identity-resolving key to another device and/or to receive an identity- resolving key from another radio device.
• Such a key transmission or exchange preferably occurs substantially as described in a Bluetooth Core Specification (e.g. version 4.0).
• a radio device preferably comprises a radio transmitter and/or radio receiver. It preferably comprises processing means for carrying out steps described herein.
• processing means may comprise any one or more of: a CPU, a microcontroller, a microprocessor, an ASIC and an FPGA.
• the invention extends to software (e.g. firmware) comprising instructions which, when executed on a radio device comprising processing means, causes the processing means to carry out any of the methods described herein.
• the value derived from a counter in the device address may be, or may comprise, an encrypted value derived from a counter (e.g. an encrypted count value). It may be encrypted with a device-specific key, such as the identity-resolving key.
• the value may be encrypted using the Advanced Encryption Standard (AES) encryption algorithm (e.g. occupying 128 bits in the device address), or some other algorithm (e.g. an encryption algorithm that outputs a 24-bit encrypted value).
• a receiving radio device may use a corresponding decryption key to decrypt the received encrypted value.
• the use of such encryption may further reduce the potential for an attacker to track a device, by making the value part of the address appear random and unpredictable to anyone without possession of an appropriate key.
• the value derived from a counter being, or comprising, a hash of a value derived from a counter (e.g. a 24-bit hash of a count value).
• the hash is preferably calculated using a key such as the identity-resolving key, for instance using the same hash algorithm as previously described. Since a receiving device cannot necessarily reconstruct, from a received hash, the original value derived from the counter (because hash functions are typically one-way functions), the receiving device may be configured to generate a set of allowable hash values based on successive local count values, and check that the received hash matches one of the set of allowable hash values.
• the set may contain a freshness threshold number of different hash values, based on incremental local count values starting from a stored local count value as described previously.
• the value derived from a counter may be derived from a linear feedback shift register (LFSR) or other pseudo-random number generator, with each successive LFSR or pseudo-random output corresponding to a counter increment.
• LFSR linear feedback shift register
• a receiving device may be configured to compare a received value against a sequence of locally-generated LFSR or pseudo-random values, which may be seeded from a local count associated with the sending device, and which may contain a freshness threshold number of member values.
• Figure 1 is a figurative representation of a radio device address known from the prior art
• FIG 2 is a figurative representation of a radio device address according to the invention
• Figure 3 is a schematic diagram of two radio devices embodying the invention and a malicious device
• FIG. 4 is a flow diagram of steps carried out by a master radio device embodying the invention.
• FIG. 5 is a flow diagram of steps carried out by a slave radio device embodying the invention.
• Figure 2 shows an address of a radio device embodying the invention. It has a 24- bit count portion, count, which consists of a numerical count value from a counter, concatenated with the bits "1 " and "0". It also has a 24-bit hash portion, hash, which is the 24 least-significant bits of the result of encrypting count (zero-padded to 128 bits) using the Advanced Encryption Standard (AES) encryption algorithm with a device-specific 128-bit key (referred to as an identity-resolving key or IRK).
• Figure 3 shows a first radio device 3, which may be a master Bluetooth Low Energy device, substantially as defined in the Bluetooth Core Specification 4.0. It has radio circuitry 4 and a microcontroller 5, as well as a radio antenna 6.
• a second radio device 7 which may be a slave Bluetooth Low Energy device. It too has radio circuitry 8, a microcontroller 9 and an antenna 10.
• the second device 7 is assumed to be peered (paired) with the first radio device 3.
• the first and second radio devices 3, 7 will have each other's identity-resolving key (IRK) accessibly to their respective microcontrollers 5, 9.
• a third radio device 1 1 is also shown, which is assumed to be under the control of a malicious attacker. The attacker desires to determine when the first radio device 3 is in the vicinity of the third device 1 1 , e.g. for the purposes of tracking the movements of the owner of the first radio device 3.
• the Bluetooth Core Specification 4.0 provides a mechanism of resolvable private addresses (RPA) to thwart this.
• RPA resolvable private addresses
• an attacker can circumvent this by eavesdropping on communication by the second radio device 7, such as an advertising message; noting the device address of the second device 7 contained in the message; and subsequently transmitting its own advertising messages containing this address (i.e. impersonating the second radio 7), so as to elicit a response from the first device 3. If it receives such a response from the first device 3, it can use this to determine that the first device 3 is in the vicinity of the third device 1 1 .
• the first and second radio devices 3, 7 embody the present invention, such an attack can be detected by the first device 3 with high probability.
• the second radio device 7 uses an address such as that shown in Figure 2, and updates the count value at regular intervals.
• the attacker can only cause the third device 1 1 to replay an address that it has heard from the second device 7; it cannot generate future addresses because it does not know the IRK for calculating the hash portion of the address.
• the first device 3 can identify if it receives an expired address in an advertising message from the third device 1 1 and choose not to respond, thereby thwarting the attack.
• Figure 4 shows steps taken by a radio device embodying the invention and acting in a master role, in respect of a peered slave device, substantially as defined in the Bluetooth Core Specification 4.0.
• the master device knows the IRK of the slave device from a pairing operation (not shown), and maintains a local variable
• RemoteCounter for the slave device which it updates with the latest-resolved address of the slave device after successful receipt and validation of an advertising message from that slave device. It also stores a 22-bit variable LocalCounter which it uses to generate its own master-device address having the format shown in Figure 2. The value count in the master-device address is given by the current value of LocalCounter concatenated with a "1 " bit and "0" bit as shown in Figure 2. These variables are initiated to zero when first created.
• the master device When the master device receives a directed or undirected advertisement message which includes a resolvable private address of a slave device according to an embodiment of the invention (e.g. in an AdvA field), it first tries to identify the slave device. It does this by applying each slave IRK known to master device to the count value of the received slave address it in turn, using the AES-based hash algorithm described above, until it finds one that generates an output that is identical to the hash value in the received address. If none is found, the
• CountPrivacy may be set equal to 35,000, which corresponds to approximate a year of regular slave counter increments. Other values may, of course, be used.
• the arithmetic is carried out using always-positive values, modulo 2 22 .
• the 22-bit counter will roll over approximately every 120 years with 15-minute slave-counter increments.
• the master device stores the received slave address (or updates a previously-stored version) for use in any response message. It also updates its own address using the current value of LocalCounter. It then increments the value of LocalCounter and sets RemoteCounter equal to
• ReceivedCounter It also continues with any required response to the slave device, such as establishing a connection with it.
• a master device receives an advertisement packet with a resolvable private address (RPA) having a ReceivedCounter value of 1 ,000, and has set the CountPrivacy to 10,000.
• RPA resolvable private address
• the master device's RemoteCounter is currently set to 4,194,000, Then the ReceivedCounter value minus RemoteCounter value, modulo 2 22 (4,194,304), is 1 ,304, which is less than CountPrivacy.
• a connect request packet may thus be sent and connection establishment initiated.
• the RemoteCounter is then set to the ReceivedCounter value.
• FIG. 5 shows steps taken by a radio device embodying the invention and acting in a slave role, in respect of a peered master device, substantially as defined in the Bluetooth Core Specification 4.0.
• the slave device knows the IRK of the master device from a pairing operation (not shown), and maintains a local variable
• RemoteCounter for the master device which it updates with the latest-resolved address of the master device after successful receipt and validation of a connection message from the master device (e.g. taken from an InitA field). It also stores a 22- bit variable LocalCounter which it uses to generate its own slave-device address having the format shown in Figure 2. The value count in the slave-device address is given by the current value of LocalCounter concatenated with a "1 " bit and "0" bit as shown in Figure 2. These variables are initiated to zero when first created.
• the slave device After initialisation, the slave device sets its own address using the current value of LocalCounter. It also generates and stores the master device address using the master-device IRK (known to the slave from the pairing operation) based on the current value of RemoteCounter.
• master-device IRK known to the slave from the pairing operation
• the slave device Whenever the slave device is not responding to a connection request, it increments LocalCounter every 15 minutes. Of course, other increment intervals are also possible.
• the slave device When the slave device receives a connection message which includes a resolvable private address of a master device according to an embodiment of the invention, it first verifies the identity of the master device. It does this by applying the master IRK to the count value of the received master address, using the AES-based hash algorithm described above, and checking that the output is identical to the hash value in the received address. If it does not match, the connection message is discarded. If it matches, the slave device then checks whether the received count satisfies validity criteria. If not, the connection message is discarded. A value Received Counter is extracted from count by stripping the two most-significant bits. The validity criteria are that ReceivedCounter is greater than RemoteCounter, and that ReceivedCounter minus RemoteCounter is less than a freshness threshold. In some embodiments, this threshold is 1 ,000, which is expected to give reasonable protection from attackers while maintaining acceptable usability. Other values may, of course, be used. The arithmetic is carried out using always-positive values, modulo 2 22
• the slave device increments the value of LocalCounter and sets RemoteCounter equal to ReceivedCounter. It updates the stored master address and its own address using the new values. It also continues with any required response to the master device, such as establishing a connection with it. In this way, both a master device 3 and a slave device 7 can reduce the potential for an attacker to identify and track them. For a master device 3 to be maximally protected, it should require that all the slave devices it is peered with use counter- based addresses according to the present invention. However, some protection may be obtained even if this is not the case, since some slave devices may only communicate with the master device relatively infrequently, or out of range of an attacker.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Power Engineering (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephonic Communication Services (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=49253318

Family Applications (1)

Country Status (4)

Cited By (3)

Families Citing this family (6)

Citations (2)

Family Cites Families (3)

• 2013
  • 2013-09-27 CN CN201380052695.1A patent/CN104704771A/zh active Pending
  • 2013-09-27 JP JP2015536059A patent/JP6328123B2/ja not_active Expired - Fee Related
  • 2013-09-27 KR KR1020157012340A patent/KR20150068471A/ko not_active Withdrawn
  • 2013-09-27 WO PCT/EP2013/070285 patent/WO2014056744A1/en not_active Ceased

Patent Citations (2)

Also Published As

Similar Documents

Legal Events