Note: Descriptions are shown in the official language in which they were submitted.
SECURE MOBILE INTERNET-OF-THINGS (I0T) DEVICE
REGISTRY MANAGEMENT
TECHNICAL FIELD
[0001] The present disclosure relates to networked loT devices and in
particular to secure mobile Internet-of-things (loT) device registry
management.
BACKGROUND
[0002] The 'Internet-of-Things' (loT) has been defined as a system of
interrelated loT devices, mechanical and digital machines, objects, sensors or
devices that are provided with unique identifiers and the ability to transfer
data over
a network without requiring human-to-human or human-to-computer interaction.
The prevalence of loT devices has rapidly expanded with network enabled loT
devices and advanced wireless networks. These devices can leverage cloud
computing to provide communication between devices, service providers and
owners and the collection and processing of data. However, typical loT devices
are
hardcoded to connect to a specific cloud (or application) service provider
presenting
new management challenges for these devices. For example, if a city is
deploying
loT enabled devices, such as parking meters, the deployment would require each
device to be configured to operate with a selected mobile network operator
(MNO)
and an cloud service providers. If the city changes the cloud service provider
for the
smart parking meter they have to touch every smart parking unit, or any loT
devices,
to report back to a new cloud service provider (CSP), or more drastically,
change all
the smart parking meters to those of the new CSP, however, owners of large loT
device deployments are locked in with a specific vendor due to the complexity
and
high cost of change.
[0003] The deployment of new pervasive wireless technologies such as 5G
wireless technology for digital cellular networks will increase the deployment
of loT
devices and sensors throughout public networks and increase the possible cyber-
security attack surface. As loT devices can be directly accessible via the
mobile
network or public Internet making them vulnerable to attack. Existing
technologies
attempt to secure organizations that deploy loT devices that were themselves
built
- 1 -
Date Recue/Date Received 2020-06-02
without adequate security, however new approaches to provide management
flexibility while secure the loT devices are also required.
[0004]
Accordingly, systems and methods that enable flexible and secure
networked loT device management remains highly desirable.
- 2 -
Date Recue/Date Received 2020-06-02
SUMMARY
[0005] A system of one or more computers can be configured to perform
particular operations or actions by virtue of having software, firmware,
hardware, or
a combination of them installed on the system that in operation causes or
cause the
system to perform the actions. One or more computer programs can be configured
to perform particular operations or actions by virtue of including
instructions that,
when executed by data processing apparatus, cause the apparatus to perform the
actions. One general aspect includes a method of a networked Internet-of-
Things
(loT) device management at a registry server. The method also includes
receiving
through a mobile network a device identifier (ID) and a public encryption
certificate
(CERT) associated for a networked loT device from a cloud service provider
(CSP);
generating an encrypted applet using the public encryption cert associated
with the
networked loT device, the encrypted applet containing public and private
encryption
cert for the networked loT device, a registry public cert and CSP network
connection
information for association with an eSim of the networked loT device; sending
the
encrypted applet to a mobile network operator (MNO) of the mobile network;
receiving a request from the networked loT device via the mobile network to
provide
a registry cert; sending the registry cert to the networked loT device;
receiving a
request from the networked loT device to provide an associated record for the
networked loT device; sending the networked loT device CERT to the networked
loT device; receiving a request from the CSP to provide the associated record
for
the networked loT device; and sending networked IOT device CERT to the CSP.
Other embodiments of this aspect include corresponding computer systems,
apparatus, and computer programs recorded on one or more computer storage
devices, each configured to perform the actions of the methods.
[0006] One general aspect includes a non-transitory computer readable
memory containing instructions which when executed by a processor perform the
method of:. The non-transitory computer readable memory also includes
receiving
through a mobile network a device identifier (ID) and a public encryption
certificate
(CERT) associated for a networked loT device from a cloud service provider
(CSP);
generating an encrypted applet using the public encryption cert associated
with the
networked loT device, the encrypted applet containing public and private
encryption
- 3 -
Date Recue/Date Received 2020-06-02
cert for the networked loT device, a registry public cert the CSP network
connection
information; sending the encrypted applet to a mobile network operator (MNO)
of the
mobile network; receiving a request from the networked loT device via the
mobile
network to provide a registry certificate; sending the associated registry
cert to the
networked loT device; receiving a request from the networked loT device to
provide
an associated record for the networked loT device; sending the associated
networked loT device CERT to the networked loT device; receiving a request
from
the CSP to provide the associated record for the networked loT device; and
sending
a CERT for networked loT device to the CSP. Other embodiments of this aspect
include corresponding computer systems, apparatus, and computer programs
recorded on one or more computer storage devices, each configured to perform
the
actions of the methods.
[0007] One general aspect includes a method of managing a networked
loT
device. The method also includes receiving a security applet from a registry
system
coupled to a computer network for associating the networked loT device with an
application service provide (CSP) associated with an owner of the networked
loT
device; decrypting security applet containing public and private encryption
keys
associated with the networked loT device, and CSP connection information for
association with an eSim of the networked loT device; sending a first query
for a first
certificate associated with the registry; verifying the first certificate
received from the
registry; installing cloud service provider profile on an eSim of loT device
when the
first certificate is verified; sending a second query for a second certificate
associated
with the networked loT device; and verifying the second certificate received
from the
registry. Other embodiments of this aspect include corresponding computer
systems, apparatus, and computer programs recorded on one or more computer
storage devices, each configured to perform the actions of the methods.
[0008] The disclosed system and method enables generic loT devices
manufacturer and vendors independent loT cloud service providers to
interoperate
and enable any loT device to connect work between cloud service providers. By
utilizing a secure registry man-in-the-middle attacks can be mitigated by
securely
enabling the transmission of encrypted cloud application credentials
- 4 -
Date Recue/Date Received 2020-06-02
(certificate/keys) from the loT Registry to loT devices, with 'proof' of
destruction of
private keys. The registry system provides a new root of trust, simplify the
validation
of cloud service providers certificates and individual loT device keys by
using the
cryptographically enabled public domain name system (DNS) infrastructure. The
system and method leverage the Domain Name System Security Extensions
(DNSSEC) feature and extend the functionality to networked loT devices. DNSSEC
is a suite of Internet Engineering Task Force (IETF) specifications for
securing
certain kinds of information provided by the Domain Name System (DNS) as used
on Internet Protocol (IP) networks.
- 5 -
Date Recue/Date Received 2020-06-02
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Further features and advantages of the present disclosure will
become
apparent from the following detailed description, taken in combination with
the
appended drawings, in which:
FIG. 1 shows a system for secure mobile internet-of-things (loT) device
management;
FIG. 2 shows a message flow for networked loT device registration with a first
cloud
service provider;
FIG. 3 shows a message flow for securing networked loT device public
certificate;
FIG. 4 shows a message flow for networked loT device registration transfer to
a
second cloud service provider;
FIG. 5 shows a method for networked loT device registration with a registry
with a
first cloud service provider; and
FIG. 6 shows a method of registering a networked loT device.
[0010] It will be noted that throughout the appended drawings, like
features
are identified by like reference numerals.
- 6 -
Date Recue/Date Received 2020-06-02
DETAILED DESCRIPTION
[0011] Embodiments are described below, by way of example only, with
reference to Figs. 1-6.
[0012] There is also provided a system and method for providing a networked
Internet-of-Things (loT) device management utilizing a registry server. The
registry
server associates a device identifier (ID) and a public encryption certificate
(CERT)
associated for a networked loT device from a cloud service provider (CSP) to
generate an applet for configuring the network loT device. An encrypted applet
is
sent to the network loT device via the network operator. The applet is
generated
using the public encryption CERT associated with the networked loT device, the
encrypted applet containing public and private encryption CERT for the
networked
loT device, a registry public CERT and CSP network connection information for
association with an eSIM of the networked loT device. Confirmation queries are
received from the networked loT device to confirm identify of the registry and
verify
the loT device CERT is consistent. The CSP can also request confirmation of
the
networked loT device from the registry. The queries from the networked loT
device
and the CSP are generated using Domain Name System Security Extensions
(DNSSEC) for authentication and data integrity utilizing Domain Name System
(DNS) public infrastructure.
[0013] The secure loT registry and associated provisioning method
simplifies
the loT cloud provider operations with respect to managing mobile loT eSIM
credential provisioning/certificate key management. The loT cloud provider
simply
does not have to worry about that aspect. The secure loT Registry enables the
Mobile Network Operator (MNO) to understand and map the loT device ownership
in relationship to cloud providers to facilitate business functions like
charge back
mechanisms. The secure loT registry integrates a next generation DNSSEC based
Certificate Authority (CA) system enabling trusted and simpler mechanisms to
validate certificates and their state.
[0014] FIG. 1 shows a system for mobile/networked Internet-of-Things (loT)
device management. The described system provides a secure loT registry
- 7 -
Date Recue/Date Received 2020-06-02
framework that bridges the gap between the MNO 124, the Cloud Service
Providers
(CSP) 140/150, the loT device manufacturers 180 and the mobile loT devices
182/184/186 and device owner 110. The core feature of the loT registry 130 is
the
enablement of connectivity for generic loT devices 182/184/196 to connect to
any
CSP 140/150 from any MNO 124 securely. The secure loT registry 130 provides a
vendor agnostic system that can scale to include all types of loT devices
(e.g.
sensors, smart city, critical infrastructure, home security, industrial
devices, medical
devices, etc.). The described system enables the zero touch provisioning of
thousands of (one) embedded subscriber identify module (eSIM) enabled generic
smart devices 182/184/186 for a device owner. The MNO 124 has commercial
relationship with the registry operator 130 as a certified MNO 124. The owner
110,
owns and operate a smart devices 182/184/186, such as for example parking
meters, however any network capable smart device can utilize the secure loT
registry 130. The loT device manufacturer 180, for example mobile loT smart
parking meter manufacturer, has commercial relationship with the owner 110,
such
as a municipality. On acquisition the loT device manufacturer 180 provides the
owner 110 the list of device identifiers such as Universal Integrated Circuit
Card
Identifiers (UICCIDs) and associated public keys. The loT device manufacturer
180
has commercial relationship with MNO 124. Cloud service provider 1 (CSP1 140),
an loT ASP1 140 specializing in parking management in smart city context. CSP1
140 has an active commercial relationship with the owner 110 and is the
current
provider of service for the loT device manufacturer 180 and a commercial
relationship with the Secure loT registry 130 as a certified cloud service
provider.
CSP1 140 provides the service connection information requirements (domain
name,
port number, protocol). Although the term mobile network operator is utilized
in the
accompanying description, the loT devices may also be alternatively associated
with
a wired network operator or infrastructure.
[0015] The owner 110 can establish a new commercial relationship
requiring
all loT devices 182/184/186 to connect to CSP2 150 at a given date and time.
In
traditional configuration each loT device 182/184/186 would have to be
manually
reconfigured to be operable with CSP2 150. However, the use of the registry
130
enables the loT devices 182/184/186 to be securely transferred between CSP's,
for
- 8 -
Date Recue/Date Received 2020-06-02
example from CSP1 140 to CSP2 150, without requiring the time consuming manual
reconfiguration processes.
[0016] The registry 130 provides device management services to enable
authorization and authentication of cloud service providers and devices. The
registry 130 comprises a processor 132 coupled to a memory 133 providing a
certificate authority 135. The certificate authority 135 provides
encryption/decryption
keys via a public certificate keys 136 and a private certificate keys 137 in a
CSP CA
certificate. The registry 130 also provides DNSSEC 138 functionality and
device
management 139. The network 134 interface couples the registry 130 to the
Internet 120 or one or more intermediary networks. A database 131 contains loT
device 182/184/186 identifiers such as eUICCID/eID, public keys, ownership
information, certificates, encryption keys, and cloud service provider
association in
addition to authorization codes to facilitate ownership transfer. The database
can
also provide an authoritative DNS for storing and providing DNSSEC signed CERT
records for respective loT devices 182/184/186.
[0017] Each of the loT devices 182/184/186 has a processor 190
coupled to a
memory 192. The memory stores the Security Applet 193, and an associated
public
certificate keys 194 and private certificate keys 195. In addition the memory
provides eSim 197 functionality associated with eUICCID/eID. A public
certificate
key 198 and private certificate key 199 are each associated with the eSim 197
for
network authentication and access. The network interface 196 provides a
wireless
networking transceiver to provide wireless network access 122. The wireless
network 122 can provide wireless personal area network (PAN), wireless local
area
network (LAN), wireless metropolitan area network (MAN), cellular, or
satellite
based networks. The cellular network may provide access based upon cellular
standards such as 3GPP wireless standards such as GSM, UMTS, LTE, 5G NR,
and 5G.
[0018] FIG. 2 shows a message flow for mobile loT device registration
with a
first cloud service provider (CSP1). The secure loT registry 130 is utilized
to secure
the connectivity between mobile loT devices 182/184/186 and their respective
cloud
service providers, CSP1 140 and CSP2 150 by securely sending the encrypted
- 9 -
Date Recue/Date Received 2020-06-02
application credential (cert/keys) on the loT device eSIM profile via the
mobile
network operator. The cert/keys and their status can be validated over the
network
via simple DNS/DNSSEC queries for individual loT devices and their CSP. The
registry 130 enables an owner of the devices to securely register and migrate
devices between CSPs without requiring physical reconfiguration of the devices
182/184/186.
[0019] In
the process of deploying devices 182/184/186, an loT device
manufacturer 180 installs an initial configuration on each of the loT devices
182/184/186 (202) which is associated with the owner 110. Each device has a
unique device identifier (devicelD) and an associated public encryption key,
the
public keys can be generated by the manufacturing and installed on the device
182/184/186 before delivery. The owner 110 installs the loT devices
182/184/186
and powers them on, activating the network connection to the wireless network
122
which are registered with the MNO 124. The MNO 124 registers the device
identifiers as active with the secure loT registry 130, and the device ID and
public
keys are provided or confirmed with the owner 110 (204). The owner 110 can
then
activates the devices 182/184/186 with the desired cloud service provider
(CSP)
which will provide the back-end services for the owner 110, such as CSP1 140,
by
providing device IDs and public keys (206). CSP1 140 then registers the
devices
182/184/186 with the registry 130 (208). The registry 130 associates the
devicelD
with an identifier associated with the CSP.
[0020] The
secure loT registry 130 generates unique authorization codes
(authcodes) for each loT device which are utilized as a unique identifier of
ownership to enable registry management for controlling CSP association (210)
and
safeguard against unauthorized transfers of the device between ASPs. The
authcodes can be a randomly generated complex code by the registry 130 which
may contain numbers, letters and special characters.
Once the devicelDs
182/184/186 are active with both the MNO 124 and the CSP1 140, the secure loT
registry 130 creates unique credential (public, private key pair) for each of
the loT
devices and encrypts the credentials and signs the CSP connection information
with
the initial loT device 'manufacturing' public key 198 (212). This information
- 10 -
Date Recue/Date Received 2020-06-02
constitutes the content of the loT security applet containing keys and CSP1
140
connection information such as IP Address, URL, port number and the CSP CA
Certificate (CERT) to validate the CSP certificate if not using TLSA. It's
important to
note that the private keys are destroyed immediately after being encrypted in
a non-
accessible container within the registry 130. The registry 130 will then send
the
MNO 124 the encrypted applet for each loT device 182/184/186 (214). The MNO in
turn sends the encrypted applet information to the appropriate loT device
182/184/186 (216).
[0021] Upon receiving the applet, the device 182/184/186 decrypts the
received profile and may reboot if required. The devices 182/184/186 need to
ensure its configuration information has not been tampered, for example it
would
check to see if it's public key is authentic and matches the information in
the registry
(218). The loT device 182/184/186 performs a DNSSEC enabled DNS query to
ensure the public key registered for the loT device devicelD (such as UCCID)
match
using a CERT DNS query as for example defined in rfc4398
[https://tools.ietf.org/html/rfc4398] (220) The registry 130 returns the
registry CERT
record for the identified registry (222). The device 182/184/186 can then
verify the
certificate to confirm the registry identity and also verify the signature of
the received
profile (224) based upon the registry 130 public key. If the keys don't match
then
the device could be compromised. Confident with the identification of the
registry
130, the device 182/184/186 reads the encrypted content of the loT security
applet
and sends it to the eSIM to be decrypted with the corresponding unique private
key
and network configuration to be installed (226). Once the profile is
installed, the
device 182/184/188 then performs a DNSSEC enabled DNS query for the
associated device CERT record to ensure that the credential certificate public
keys
are genuine and not tampered with (228). The registry 130 provides a response
with the loT device CERT record (230). The device 182/184/186 can then perform
a
hash of the credential certificate public keys for the loT device 182/184/186
to
determine if the public keys match (232). If the key hashes do not match then
the
device could be compromised.
-11 -
Date Recue/Date Received 2020-06-02
[0022] Confident the credentials and connection information are
authentic, the
device 182/184/186 then needs to establish a transport layer security or
datagram
transport layer security (TLS/DTLS) connection to CSP1 140 (234). CSP1 140
verifies the authenticity of the loT device 182/184/186 certificate by
requesting loT
device CERT record from the registry 130 by a DNSSEC DNS query (236). The
registry 130 provide the loT device CERT record (238) which the CSP1 140 can
then verify the certificate contained therein (240). If the certificate don't
match then
the device could be compromised. The loT device 182/184/186 can then
optionally
perform a DNSSEC query for the Transport Layer Security (TLSA) protocol record
[http://tools.iettorg/html/rfc6698] record for _443._TCP.ASP 1.XXX matches the
key
presented by CSP l's loT service endpoint (242). The registry 130 provides the
TLSA (244) which can then be confirmed by the device 182/184/186 (246) The
TLS/DTLS connection is then completed (248) and a confirmation can be provided
to the owner 110 from CSP1 140 (250).
[0023] FIG. 3 shows a message flow for securing networked loT device public
certificate. The public CERT 194 is generated by the loT device 182/184/186
and
sent to the registry 130 (302) via MNO 124 or Internet 120. The registry 130
can
then sign (304) the public CERT 194 and return the signed public CERT 194 to
the
loT device (182/184/186) via MNO (124) or Internet 120.
[0024] FIG. 4 shows a message flow for networked computing loT device
registration transfer to a second cloud service provider (CSP2) after initial
registration of the loT device 182/184/186. A transfer between ASPs, ASP1 140
to
ASP2 150, can occur for example when a service contract for ASP1 140 has
expired
and the owner selected ASP2 150 as the new smart city parking meter cloud
solution provider. Since the loT device devices 182/184/186 are already
registered
and in use, the owner 110 has to prove ownership of the loT devices
182/184/186 to
initiate the transfer by providing the authcodes (authorization codes) that
were
previously generated. The owner 110 sets up the cloud services with the ASP2
150
and creates an account and import the loT device(s) 182/184/186 and provides
the
eUICCID/eID, public keys and authcodes from the loT device 192/184/186 (402).
CSP2 150 sends a registration update request (404) to the registry 130. The
- 12 -
Date Recue/Date Received 2020-06-02
provided authcodes are verified (406) against expected codes. If the codes
match
an updated loT device profile is generated by the Secure loT registry 130 by
creating unique credential (public, private key pair and cert) for each of the
loT
device, and encrypts the credentials and sign the CSP connection information,
for
CSP2 150, with the loT device public key (408). The registry associates the
devicelD with a CSP identifier. This information constitutes the content of
the loT
security applet containing keys and ASP2 150 connection information. In
addition
the Registry 130 regenerates the authcode for the loT device 182/184/186 so
the
old authcode is no longer valid. The loT Registry 130 also publishes in its
authoritative DNS a DNSSEC signed CERT record for that loT device. It is
important to note that the private keys associated with the devices are
destroyed
immediately after being encrypted in a non-accessible container within the
registry
130. The registry 130 will then send the MNO 124 the encrypted applet for each
loT
device 182/184/186 (410). The MNO then sends the encrypted applet information
to
the appropriate loT device (412).
[0025] Upon receiving the applet, the device 182/184/186 decrypts the
received profile and reboots. The devices 182/184/186 needs to ensure its
configuration information has not been tampered, for example it would check to
see
if it's public key is authentic and matches the information in the registry
(414). The
loT device 182/184/186 performs a DNSSEC enabled DNS query to ensure the
public key registered for the loT device UCCID match using a CERT DNS query as
for example defined in rfc4398 [https://tools.iettorg/html/rfc4398] (416) The
registry
130 returns the registry CERT record for the identified registry (418). The
device
182/184/186 can then verify the certificate to confirm the registry identity
and also
verify the signature of the received profile (420) based upon the registry 130
public
key. If the certificate don't match then the device could be compromised.
Confident
with the identification of the registry 130, the device 182/184/186 reads the
encrypted content of the loT security applet which sends it to the eSIM to be
decrypted with the corresponding unique private key to be installed (422).
Once the
profile is installed, the device 182/184/188 then performs a DNSSEC enabled
DNS
query for the associated device CERT record to ensure that the credential
certificates are genuine and not tampered with (424). The registry 130
provides a
- 13 -
Date Recue/Date Received 2020-06-02
response with the loT device CERT record (426). The device 182/184/186 can
then
perform a hash of the credential certificate public keys for the loT device to
determine if the public keys match (428). If the key hashes do not match then
the
device could be compromised, otherwise a confirmation is returned from the
registry
130. Now confident the credentials and connection information are authentic,
the
device then needs to establish a transport layer security or datagram
transport layer
security (TLS/DTLS) connection to ASP2 150 (430). ASP2 150 verifies the
authenticity of the loT device 182/184/186 keys by requesting loT device CERT
record from the registry 130 by a DNSSEC DNS query (432). The registry 130
provide the loT device CERT record (434) which the ASP2 150 can then verify
the
public keys contained therein (436). If the keys don't match then the device
could
be compromised. The loT device can then optionally perform a DNSSEC for the
Transport Layer Security (TLSA) protocol record
[http://tools.iettorg/html/rfc6698]
record for _443._TCP.ASP 1.XXX matches the key presented by ASP2's loT service
endpoint (438). The registry 130 provides the TLSA (440) which can then be
confirmed by the device (442) The TLS/DTLS connection is then completed (444)
and a confirmation can be provided to the owner 110 from ASP2 150 (446).
[0026] FIG. 5 shows a method for networked loT device registration
with a
secure registry with a first cloud service provider. The registry receives a
registration request from a CSP (502) to associate device(s) for the owner. If
the
device is not currently associated with the CSP (No at 504) authcodes are
generated (506) to associate with the devices and provided to the CSP and
owner of
the networked loT devices. If the device is already associated with a CSP (Yes
at
504) authcodes that were provided by the CSP are verified (532). If the
authcodes
are verified, i.e. match stored codes, (Yes at 532) an loT device profile is
generated
with MNO information and is encrypted (508) into a security applet and sent to
the
MNO (510). The loT Registry 130 publishes in its authoritative DNS a DNSSEC
signed CERT record for that loT device (512). If the authcodes are not
verified (No
at 532) the CSP change is denied (534). After the device(s) have been provided
with the security applet (510) the private keys that were generated are
destroyed
(514). A DNSSEC DNS query is received from the devices at the registry to
verify
the CERT record of the registry (516). The registry sends the registry CERT
record
- 14 -
Date Recue/Date Received 2020-06-02
(518) to each of the requesting devices. The registry then receives a DNSSEC
query the loT device CERT record from the loT device (520). The CERT record
for
the loT device is provided (522). As the device and CSP initiate a TLS/DTLS
connection the registry receives a DNSSEC query using CERT DNS from CSP for
the loT device CERT record (524). The loT device CERT record is provided to
the
CSP (526). Optionally the registry may receive a DNSSEC query from the
device(s)
to verify TLSA record (528) which is provided to the loT device (530) for
verification.
The device(s) are then successfully associated with the CSP when the TLS/DTLS
connection is successful. As noted above, if TLSA is not utilized the CA
certificate
may be provided for the verification process.
[0027] FIG. 6 shows a method of registering a mobile loT device. On
initial
power up the device will access the mobile network and send devicelD and
associated public keys to the MNO which is forwarded to the registry and to
the
device owner. The public keys may have been provided by the manufacturer. Upon
initial configuration, or when a CSP change is performed, a security applet is
received from the registry 130 (602) to configure the device for communication
with
an CSP associated with the owner. The applet is decrypted (604) and a DNSSEC
query for the registry CERT record is sent to the registry (606). A received
CERT
record can then be verified at the device. If the signature is verified (Yes
at 608) the
profile is installed (610). If the signature of a received device CERT record
cannot
be verified (No at 608) the device can revert to a default mode (626). Once
the
profile is installed the device (610), the device sends a DNSSEC query using
for the
device CERT (612). If a received device certificate is verified (Yes at 614) a
TLS/DTLS connection can be initiated with the CSP (616). If the TLS/DTLS
connection is successfully established (Yes at 622) the connection is
confirmed
(624). If the TLS/DTLS connection is not successfully establish (No at 622)
the
device can revert to a default state (626).
[0028] Optionally, as part of the TLS/DTLS connection, the device can
send a
request for confirmation for the TLSA record to the registry (618). If the
registry
verifies the TLSA record (Yes at 622) the connection is confirmed (624),
otherwise
(No at 622) the device can revert to a default state (626).
- 15 -
Date Recue/Date Received 2020-06-02
[0029] Each element in the embodiments of the present disclosure may
be
implemented as hardware, software/program, or any combination thereof.
Software
codes, either in its entirety or a part thereof, may be stored in a computer
readable
medium or memory (e.g., as a ROM, for example a non-volatile or non-transitory
memory such as flash memory, CD ROM, DVD ROM, Blu-rayTM, a semiconductor
ROM, USB, or a magnetic recording medium, for example a hard disk). The
program may be in the form of source code, object code, a code intermediate
source and object code such as partially compiled form, or in any other form.
[0030] It would be appreciated by one of ordinary skill in the art
that the
system and components shown in Figures 1-6 may include components not shown
in the drawings. For simplicity and clarity of the illustration, elements in
the figures
are non-limiting of the elements structures. It will be apparent to persons
skilled in
the art that a number of variations and modifications can be made without
departing
from the scope of the invention as defined in the claims.
- 16 -
Date Recue/Date Received 2020-06-02
