WO2017053048A1 - Authentification et autorisation de domaine basé sur l'iot - Google Patents

Authentification et autorisation de domaine basé sur l'iot Download PDF

Info

Publication number
WO2017053048A1
WO2017053048A1 PCT/US2016/050150 US2016050150W WO2017053048A1 WO 2017053048 A1 WO2017053048 A1 WO 2017053048A1 US 2016050150 W US2016050150 W US 2016050150W WO 2017053048 A1 WO2017053048 A1 WO 2017053048A1
Authority
WO
WIPO (PCT)
Prior art keywords
iot
access
domain
ticket
iot devices
Prior art date
Application number
PCT/US2016/050150
Other languages
English (en)
Inventor
Christian M. GEHRMANN
Original Assignee
Pcms Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pcms Holdings, Inc. filed Critical Pcms Holdings, Inc.
Publication of WO2017053048A1 publication Critical patent/WO2017053048A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • Machine to Machine (M2M) and/or Internet of Things (IoT) may be an Internet paradigm that may be used to remotely configure and control a large amount of electronic equipment (e.g., M2M and/or IoT units or devices).
  • M2M and/or IoT systems may open up possibilities with respect to services such as automotive, industry control, traffic management and building automation, may reduce cost for maintenance, surveillance, production, transport and communications, and/or the like.
  • end-user devices such as computers, smart phones, vehicles, smart watches, and/or the like may want to access such IoT systems, networks, and/or units in a domain.
  • an authorization server may receive, e.g., from a device management server (DMS), credentials (e.g., keys) associated with an IoT domain (e.g., with a plurality of IoT devices in the IoT domain).
  • the credentials may be associated with an authorization time period.
  • the authorization time period may provide when the credentials can be used to access the IoT domain.
  • the AS may receive, from a client device (e.g., a mobile device), a request for access authorization to the IoT devices/resources in the IoT domain.
  • the request may comprise information regarding (e.g., associated with) the requested IoT devices/resources in the IoT domain (e.g., the type of services desired by the client from the IoT devices).
  • the request may include an access request time period during which the IoT devices/resources may be used.
  • the AS may determine whether the IoT devices/resources in the IoT domain are available during the access request time period. If the IoT devices/resources are available, the AS may send (e.g., issue), to the client device, a ticket (e.g., an IoT domain access ticket) for accessing the plurality of IoT devices/resources.
  • a ticket e.g., an IoT domain access ticket
  • the ticket (e.g., the IoT domain access ticket) may be generated based upon the credentials associated with the IoT domain (e.g., with a plurality of IoT devices in the IoT domain) that are received from the DMS and/or the authorization time period associated with the credentials.
  • the ticket issued by the AS may have a validity time period.
  • the authorization time period, access request time period (e.g., received from the client with the information regarding the requested IoT resources from the IoT domain), and the validity time period may overlap with each other.
  • the authorization time period may cover and extend beyond the access request time period.
  • the access request time period and the validity time period may be the same.
  • the ticket (e.g., the IoT domain access ticket) may be sent from the client to an IoT device associated with the IoT domain to obtain access to the requested IoT resource.
  • the access may be provided by the IoT device based on authentication of the client, e.g., based on the access ticket and/or the credentials associated with the IoT domain, where the credentials may be received by the IoT device from the DMS.
  • An additional IoT domain access ticket may be configured to be sent to the client and may be used to access the IoT device and/or another IoT device and/or another service or resource in the IoT domain provided thereby. For example, a second access ticket may be provided when a first access ticket does not cover the entire access request time period.
  • the additional IoT domain access ticket may be sent responsive to a determination that the requested IoT resource from the IoT domain may be available during the access request time period.
  • a client device may receive address information associated with an authorization server (AS).
  • AS authorization server
  • the client device may send, to the AS, information regarding requested IoT devices and/or services in an IoT domain and a timeframe during which the services may be used.
  • the client device may receive, from the AS, an access ticket.
  • the access ticket may be generated based upon credentials associated with the IoT domain and/or an authorization time period.
  • the access ticket may have a validity time period.
  • the authorization time period, the validity time period, and the timeframe during which the services may be used may overlap.
  • the client device may access at least one IoT device using the access ticket received from the AS, wherein the access ticket may be configured to be sent from the client to the at least one IoT device associated with the IoT domain to obtain access to the requested IoT resource.
  • the AS may be configured to send the access ticket responsive to a determination that the requested services may be available during the timeframe.
  • the access may be configured to be provided to the at least one IoT device based on authentication of the client (e.g., based on the access ticket and the credentials associated with the IoT domain).
  • an additional access ticket may be received to access the at least one IoT device and/or another IoT device in the IoT domain and/or the service or another service (e.g. or resource) in the IoT domain provided thereby.
  • a device management server may send to an authorization server (AS) (e.g., that may be a third party service) a credential or key associated with an IoT domain and a ticket generation secret (e.g., independent of the credential or key).
  • AS authorization server
  • the ticket generation secret may be configured to be used to generate an integrity protection key that may be used to calculate a first
  • a ticket e.g., an access ticket
  • the integrity protection key may be configured to generate a first message authentication code (MAC) in response to the ticket being generated.
  • the first MAC may be included in a portion of the ticket (e.g., to integrity protect the ticket or for use to determine whether access should be granted and/or continued to be granted using the ticket).
  • the DMS may receive, from a first IoT device associated with the IoT domain, access information including integrity values and the first MAC from the ticket.
  • the DMS may generate an integrity protection key candidate from the integrity values and a second MAC based on the integrity protection key candidate.
  • the DMS may determine whether the first MAC in the access information matches the second MAC generated from the integrity protection key candidate calculated from the integrity values and, in an example, responsive to a determination that the first and second MACs do not match, may send an alert or waming that may indicate the ticket may not be valid and/or access should not be granted or continued using the ticket.
  • the access information may be entered into a log in the IoT unit and sent to the DMS, for example, responsive to a client device presenting the ticket to first IoT device associated with the IoT domain to obtain access to the requested services.
  • the log may be sent to the DMS for verification of the first and second MACs (e.g., to check whether the MACs match using the first MAC and integrity values or values from the access information other than the first MAC to determine whether the ticket may be valid).
  • the IoT unit may be further configured to send the log or information in the log to one or more other IoT units in the IoT domain.
  • the DMS may receive the log or information in the log from the IoT unit and/or the one or more IoT units for verification of the first and second MACs.
  • the first IoT device may be configured to authenticate a client device based on the access ticket received by the first IoT device from the DMS.
  • the access information may comprise one or more of the following: identity information related to the first IoT device associated with the IoT domain, access time information, and IoT domain access ticket information comprising ticket index information.
  • the AS may be configured to receive a request from a client device for access to an IoT resource in the IoT domain and send the ticket to the client device to grant access to the IoT resource.
  • the DMS may send, to the AS, an authorization time period where the ticket may be further generated based on the authorization time period.
  • the AS may be configured to generate the integrity protection key that may include the first MAC or MAC protection key using the ticket generation secret that may comprise a general secret (e.g., Kg) received from the DMS and the ticket and/or the index.
  • Kg general secret
  • the alert or warning may include a system warning
  • the system warning may include one or more of the following: a time of issue of the ticket, a credential or key associated with an IoT domain (e.g., a domain key) that may have been used to issue or verify the ticket, a ticket index, a ticket validity period, an access type granted, an IoT unit that may have received the ticket and/or a client device that may have sent the ticket, for example, once the ticket may be determined to be an invalid or false access ticket based on the MACs not matching (e.g., the MAC in the ticket being false).
  • an IoT domain e.g., a domain key
  • an authorization server may receive, from a device management server (DMS), a first public credential or key associated with an IoT domain and a first authorization time period.
  • the AS may also receive, from a client device, a request for access to the IoT resources in the IoT domain.
  • the request may comprise information regarding the requested IoT resources in the IoT domain and a first access request time period during which the IoT resources may be used.
  • the AS may send, to the client, public-key based authentication information to enable temporary access by the client device to the IoT resources.
  • the public-key based authentication information may include a certificate associated with the first authorization time period, a root certificate associated with the IoT domain, assertion information regarding access rights granted to the client device, and/or access address information associated with the access rights granted.
  • the public key based information may be sent over a channel secured using a client certificate that may be received.
  • the first authorization time period and the first access request time period received from the client may overlap.
  • the client device may be configured to present the certification and the root certification to one or more IoT devices associated with the access address information to obtain access to the IoT resources.
  • the one or more IoT devices may be configured to authenticate the client device based on at least the certificate, root certification, and/or additional information that may be received by the one or more devices from the DMS.
  • FIG. 1 illustrates an example IoT network that may be used to enable an end-user device to connect to IoT units or devices in a domain according to one or more examples herein.
  • FIG. 2 illustrates an example of an authorization, authentication, and/or key exchange and/or protocol according to one or more of the examples herein.
  • FIGs. 3-5 illustrate example message exchange flows according to one or more examples herein.
  • FIG. 6 illustrates an example message flow and/or protocol according to one or more examples herein.
  • FIG. 7 illustrates an example associated with providing or enabling access to one or more IoT units or devices in a domain as described in examples herein.
  • FIG. 8 illustrates an example associated with generating a domain key as described in examples herein.
  • FIG. 9 illustrates an example associated with updating a key as described in examples herein.
  • FIGs. 10-12 illustrate examples associated with providing or enabling access to one or more IoT units or devices in a domain as described in examples herein.
  • FIG. 13 illustrates an example of a system in which one or more examples described herein may be used and/or implemented.
  • FIG. 14 illustrates an example system for logging IoT access activities according to one or more examples herein.
  • FIG. 15 illustrates additional or alternative example message flows according to one or more examples herein.
  • FIG. 16 illustrates example secure domain key transfer according to one or more examples herein.
  • FIG. 17 illustrates an example flow diagram of ticket integrity protection according to one or more examples herein.
  • FIG. 18 illustrates an example flow diagram of IoT access logging according to one or more examples herein.
  • FIG. 19 illustrates an example system in which one or more examples described herein may be used and/or implemented.
  • FIG. 20 illustrates an example authorization model according to one or more examples herein.
  • FIG. 21 illustrates an example mechanism for signing on to web applications.
  • FIG. 22 illustrates an example flow diagram for granting temporary access to an IoT resource according to one or more examples herein.
  • FIG. 23 illustrates example message flows that may occur during the sending of access ticket information according to one or more examples herein.
  • FIG. 24 illustrates additional or alternative example message flows that may occur during the sending of access ticket information according to one or more examples herein.
  • FIG. 25 illustrates example checks that may be performed by an IoT device according to one or more examples herein.
  • FIG. 26A depicts a diagram of an example communications system in which one or more disclosed examples may be implemented and/or may be used with one or more of the examples described herein.
  • FIG. 26B depicts a system diagram of an example device such as a wireless transmit/receive unit (WTRU), server, database, and/or the like that may be used within the communications system illustrated in FIG. 26 A.
  • WTRU wireless transmit/receive unit
  • FIG. 26C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 26A.
  • FIG. 26D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 26A.
  • FIG. 26E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 26A.
  • Systems, methods and/or instrumentalities may be provided for authorization and/or authentication of end-user devices towards IoT units belonging to a domain such as a single administrative domain.
  • the systems and/or methods may allow or enable temporary authentication (e.g., symmetric key based) of resource constrained IoT units (e.g., without issuing IoT unit specific credentials to connecting clients). Connecting clients may use the same credentials to access one or more IoT units (e.g., each IoT unit) within the domain.
  • the example systems and/or methods may provide generation and system wide dissemination of symmetric keys to support the system security solution.
  • IoT units e.g., or IoT devices
  • IoT devices may be becoming connected.
  • This may provide additional opportunities for new services and an enhanced user experience.
  • One such area with large commercial potential may be fast and convenient authorization/authentication of end-users that may have temporary access to services provided by IoT units in a particular network domain.
  • Authentication for such scenario may be applicable for a wide variety of services such as property rental, IT infrastructure service for visitors, maintenance operations of IoT infrastructures from third parties, and/or the like.
  • the IoT infrastructure provider may want to have the possibility to outsource the actually authorization decision to a general authorization server such that the device management system itself may not need to handle issuing of short term credentials/tickets to the temporary user of the domain (e.g., as that may involve payment, end-user authentication, and/or the like).
  • this authorization service may be part of a more general third party service offering and the infrastructure owner may give such third party access (e.g., full access) to long term credentials for management of the IoT infrastructure.
  • authentication may be typically performed "per service,” and not generally for a complete network domain or to each of or a sub-set of the services available in this domain, authentication may typically be done with the help of a central AAA server that may not allow IoT units themselves to directly perform authentication and/or authorization decision for temporary user access requests, and/or lack of an authentication and authorization technique that may be compatible with other proposed authorization/authentication models for resource constrained environments (e.g., models that may be standardized).
  • a user may want to utilize (e.g., temporarily utilize) services provided through several IoT units within one administrative/network domain.
  • IoT units within one such domain may be under the control of a single Device Management Server (DMS).
  • DMS Device Management Server
  • the end-user may access these IoT services remotely (e.g., through general internet/intranet access) or locally (e.g., through direct interacting with the IoT units over a local interface towards the IoT units).
  • the latter may apply, for example, if the user temporarily moves (e.g., physically) into the IoT service domain and want to interact directly with the IoT units over short range communication interfaces (e.g., if the IoT unit offers this capability), as depicted in FIG. 1.
  • FIG. 1 illustrates an example IoT network that may be used to enable an end-user device to connect to IoT units or devices in a domain according to one or more examples herein.
  • such a system or network may include distributed units such as IoT units
  • M2M and/or IoT units may be referred to as IoT units or devices (e.g., which may include M2M units or devices, IoT units or devices, and/or other similar devices or units).
  • An IoT unit may include components such as those described with respect to the devices or WTRUs 102a-d in FIGs. 26A-26E. As shown in FIG. 1, the IoT units
  • the IoT units 202a-h may be a set of wireless battery driven devices.
  • the IoT units 202a-h may have one or more resource constraint with respect to computing capabilities, volatile and non-volatile memory capabilities, and/or the like.
  • the IoT units 202a-h may be communicated and/or controlled (e.g., directly) by a device or back-end server (e.g., which may include any suitable computer, device, server, database, node, and/or the like) such as one or more Device Management Servers (DMSs) 208a-c.
  • the DMSs 208 may belong to an owner organization (e.g., that may deploy and/or control the IoT units).
  • one or more IoT units 202a-h may belong to a network domain (e.g., network domain A-C as shown respectively) that may have one or more of the respective DMSs 208a-c.
  • IoT units 202a-b and DMS 208c may belong to network domain C
  • IoT units 202c-d and DMS 208b may belong to network domain B
  • IoT units 202e-h and DMS 208a may belong to network domain A.
  • the IoT units 202a-h may be connected to respective DMSs 208 via one or more network technologies.
  • the IoT units 202a-h and/or the DMS 208a-c may have general Internet connectivity (e.g., to the Internet 205), but the access to each DMSa-c may be of different types including, but not limited to, cellular access, WLAN access, fixed broadband access or corporate network access, and/or the like.
  • the access to each DMSa-c may be of different types including, but not limited to, cellular access, WLAN access, fixed broadband access or corporate network access, and/or the like.
  • the IoT units 202a-b and/or DMS 208c may be connected to a cellular network 209 such as 3G, 4G, 5G, LTE, E-UTRAN, and/or the like (e.g., that may described with respect to FIGs. 26A-26E below) that may provide access to the Internet 205 and/or to each other.
  • the IoT units 202c-202d and/or 202g-h may be connected to a LAN and/or a WAN 206, 212 that may provide access to the Internet 205 and/or to each other.
  • the IoT units 202e-202f and/or the DMS 208b may be connected to and/or included in an IoT wireless domain 212.
  • the IoT wireless domain 212 may provide Internet connectivity to the IoT devices 202e-f and/or provide communication to the back-end system such as DMS 208a (e.g., using the LANAVLAN 212).
  • the DMSs 208a-c may be connected to the Internet 205, across the domains, and/or within the respective domains via the IoT wireless domain, cellular network, a private network and/or other network technologies.
  • the DMSs 208a-c may control the IoT units 202a-h and/or may facilitate connection of the IoT units 202a-h to other devices such as end user devices 214a-b (e.g., that may be a smart phone, tablet, PC, and/or the like or a WTRU as described herein) operated by end users 213a-b as described herein.
  • end user devices 214a-b e.g., that may be a smart phone, tablet, PC, and/or the like or a WTRU as described herein
  • the IoT units 202a-h and/or DMSs 208a-c may be connected to an authorization server 207 (e.g., that may be or include a server, computer, database, and/or the like) using the network technologies described herein to enable the end-user devices 214a-b to access (e.g., temporarily access) the IoT units 202a-h as described herein.
  • an authorization server 207 e.g., that may be or include a server, computer, database, and/or the like
  • the owners of the IoT infrastructure may provide authentication of temporary users (e.g., users 213a-b via end user devices 214a-b) that may have access to all or a subset of the services provided by the IoT infrastructure (e.g., the IoT network 200).
  • the IoT infrastructure owner may utilize an Authorization Server (AS) (e.g., which may be independent from the IoT infrastructure owner) such as the authorization server 207.
  • AS Authorization Server
  • the AS may handle authorization decisions or determinations for access to the different IoT domains (e.g., A-C and/or IoT devices within the domains) on behalf of the domain owner.
  • the AS may issue short time authorization tokens (e.g., tickets) to end-user devices such as 214a-b that may want (e.g., the users 213a-b thereof may want) access to the IoT services or IoT units (e.g., 202a-h) in a domain.
  • End-users e.g., 213a-b
  • each or a subset of the IoT services provided in such domain may contact the AS that may issue authorization tokens (e.g., tickets) for the requested domains.
  • authorization tokens e.g., tickets
  • the example systems and/or methods herein may provide efficient authentication and/or authorization handling at the IoT side (e.g., 202a-h and/or DMSa-c) for resource constrained devices compatible with international standards (e.g., Internet Engineering Task Force (IETF) Delegated CoAP Authentication and Authorization Framework (DCAF)).
  • the example systems and/or methods may provide an efficient and secure principle for managing credential sharing between the network domains (e.g., A-C) and the AS domain (e.g., 207).
  • a Kerberos protocol may be used for providing
  • a ticket and Key Distribution Centre (KDC) based authentication protocol that may be used for authorization may be the Kerberos protocol.
  • the Kerberos protocol may be based on the Needham and Schroeder key authentication protocol.
  • an E(K,M) message M encrypted under the key K and by SKA-B (e.g., a shared secret between entity A and B) may be provided.
  • Kerberos v5 message exchanges (e.g., of E(K,M)) that may be used or provided between a KDC 307 (e.g., that may include an authorization server and/or may be similar to AS 207), servers 208a-n (e.g., that may be similar to DMSs 208a-c), and/or an end user client 314 (e.g., that may be similar to 214a-b) in an example. Kerberos may follow a push model for the authorization and service authentication.
  • KDC 307 e.g., that may include an authorization server and/or may be similar to AS 207
  • servers 208a-n e.g., that may be similar to DMSs 208a-c
  • end user client 314 e.g., that may be similar to 214a-b
  • Kerberos may follow a push model for the authorization and service authentication.
  • ACE Internet Engineering Task Force
  • IEFT Internet Engineering Task Force
  • CoAP Constrained Application Protocol
  • different authorization models may be provided into one or more broad categories: a push model, a pull model, and/or an agent model.
  • FIGs. 3-5 illustrate message exchange flows 400-600 between an end-user client 414 (e.g., that may be similar to 214a-b), Authorization Server (AS) 407 (e.g., that may be similar to 207) and an IoT resource 402, 408 (e.g., that may be similar to 202a-h and/or 208a-c) according to these models.
  • AS Authorization Server
  • IoT resource 402, 408 e.g., that may be similar to 202a-h and/or 208a-c
  • Another example push/confirm model may be used or provided. This model may combine the push and agent models.
  • the IoT unit may not directly verify the access ticket it gets from the client, but may make the accept/deny decision for the access request in collaboration with the authorization server (e.g., through an online connection with this sever).
  • One or more of the different models may be provided in a general Authentication, Authorization, and Accounting (AAA) setting.
  • AAA Authentic
  • the systems and/or methods for a domain based IoT unit authorization/authentication as described herein may be provided without using a real-time connection between an IoT resource (e.g., the units 202a-h and/or DMSs 208a-c) and the authorization server (e.g., AS 207).
  • IoT resource e.g., the units 202a-h and/or DMSs 208a-c
  • the authorization server e.g., AS 207
  • Such example systems and/or methods herein may use a push model and/or a hybrid pull/push model.
  • the examples herein e.g., the systems and/or methods
  • the DCAF framework may use Datagram Transport Layer Security (DTLS) with pre- shared keys as the authentication protocol between the end-user client and IoT resource.
  • DTLS Datagram Transport Layer Security
  • a client may get access to the DTLS pre-shared key material which it may request from the AS through an intermediate node (e.g., such as an Authorization Manager (AM)) that may have a pre-configured secure channel connection to the AS.
  • An example message flow 700 that may be used according to DCAF may be depicted in FIG. 6. As shown in FIG.
  • an AM 515 may make an access decision depending on the resource domain security policies while an AS 507 (e.g., that may be similar to AS 207) may issue a ticket that may be used by an end-user client 514 (e.g., that may be similar to the end user clients 214a-b) to get access to a resource 502, 508 (e.g., that may be similar to 202a-h and/or 208a-c).
  • AS 507 e.g., that may be similar to AS 207
  • an end-user client 514 e.g., that may be similar to the end user clients 214a-b
  • 508 e.g., that may be similar to 202a-h and/or 208a-c.
  • the ticket content according to DCAF may include one or more of the following: AM authorization information (e.g., client access permissions), a time stamp generated by the AM, a lifetime or validity period of the ticket (e.g., that may be optional), a DTLS pre-shared key, and/or the like.
  • AM authorization information e.g., client access permissions
  • time stamp generated by the AM
  • lifetime or validity period of the ticket e.g., that may be optional
  • a DTLS pre-shared key e.g., if correctly authorized
  • the DTLS pre-shared key may enable or allow the client to establish a secure DTLS channel with the IoT resources (e.g., at 7 in FIG. 6).
  • a number of IoT units within an administrative domain may have, in examples, a common need to efficiently authenticate an end-user device such as computer, smart phone, vehicle, watch, NFC ring, and/or the like (e.g., 214a-b) that may have temporary access to a IoT resource (e.g., 202a-h) within the domain (e.g., A-C).
  • an end-user device such as computer, smart phone, vehicle, watch, NFC ring, and/or the like (e.g., 214a-b) that may have temporary access to a IoT resource (e.g., 202a-h) within the domain (e.g., A-C).
  • AS Authorization Server
  • this may be attractive from a security point of view as it may enable or allow higher privacy since the end user may not use detailed information of individual IoT unit identities, and/or the like.
  • the AS may be hosted within or outside the subject IoT domain without
  • the system may include resource constrained IoT units.
  • the security framework and protocols described herein may provide authorization and authentication to a complete IoT domain that may include a number of heterogonous IoT units (e.g., rather than just for single entities that connect to single IoT peers). For example, a user friendly and efficient mechanism may be provided for an end-user to request a single or a few authorization ticket(s) for the access to the whole IoT domain over a limited time period.
  • the examples herein may address issues, e.g., as discussed herein, and may provide security principles and protocols.
  • FIG. 7 illustrates an example flow 800 associated with providing or enabling access to one or more IoT units or devices in a domain, e.g., to grant temporary access to an end user device (214a-b) to an IoT resource (e.g., 202a-h of FIG. 1 and7or214e-h in FIG. 7).
  • the AM and/or AS e.g., 507 and/or 515 in FIG. 6
  • the AS 207 may be provided outside the resource domain that may be controlled by a DMS (e.g., 208a-c in FIG. 1 for domains A-C respectively or 208a as shown in FIG. 7).
  • the DMS may perform one or more of the following.
  • the DMS may have a pre- configured long-term security relationship with the IoT units within the resource domain.
  • the examples herein may not be limited to a particular way for establishing these security relations but could, for example, be created, maintained, and/or made when the IoT units may have been installed in the IoT domain using a pairing component such as Bluetooth pairing, Secure Remote Password pairing as used in the Apple HomeKit protocol, and/or the like.
  • the IoT device credentials may be stored and kept in the DMS for future use.
  • the DMS may issue in a suitable pre-defined time interval, relatively short-lived (e.g., valid for a limited period of time) domain wide credentials. These credentials may be securely transferred to the AS. They may be sent or provided (e.g., made available) to the IoT units within the resource domain. The examples herein may provide one or more ways of how this may be done.
  • the credentials may be multicasted (e.g., periodically) by the DMS to the IoT units.
  • the IoT units may request (e.g., periodically) domain wide credentials (e.g., new domain wide credentials) from the DMS.
  • the credentials may be available at the DMS and AS (e.g., supplied to an end-user from the AS) such that IoT units may request the DMS to verify authentication requests associated with client device(s), e.g., an IoT device may receive an access request from an end-user that comprises a credential and the IoT device may request that the DMS verify the credential.
  • Example 800 may be used (e.g., at the end-user client side) to request access to an
  • IoT resource domain For example, in 800, an end user may want to get temporary access to services provided by IoT units within a particular IoT resource domain.
  • the user may receive or get knowledge of an availability of such a domain through a service advertisement, through a direct interaction with the owner of the service domain, and/or through any other suitable techniques.
  • a channel e.g., a secure channel
  • the user e.g., the end-user client
  • an end-user may use the end-user client or device 214a-b to contact the responsible AS 207 and request access to the subject IoT resource domain.
  • This request may include information (e.g., detailed information) such as, for example, what type of services within the domain the user may be interested to obtain access for and/or the requested time period for such access.
  • the end-user client may send information regarding the IoT resource (e.g., or service) in the IoT domain the end-use client may want to access and an access request time during which the IoT resource may be used or access may be desired.
  • the IoT resource e.g., or service
  • the AS 207 may examine or evaluate the access request (e.g., may determine whether the request may have the necessary information) and/or may request additional information from the end-user connected to the requested service such as payment information, end-user authentication information, and/or the like. The AS 207 may determine whether the requested
  • IoT resources e.g., or services
  • IoT resources e.g., or services
  • the AS 207 may use a temporary credential or credentials it received from the DMS 208a to issue one or more access tickets (e.g., IoT domain access tickets) to the requesting device.
  • access tickets e.g., IoT domain access tickets
  • One or more tickets that may be provided or used may depend on a requested time period.
  • the temporary domain credentials the AS 207 may have received (e.g., periodically) from the DMS may span a part of the requested access period (e.g., may extend beyond the entirety of the requested access period).
  • An IoT domain access ticket may be generated based upon a credential associated with the IoT domain that may be received from the DMS and an authorization time period for the credential (e.g., which may provide the duration for which the credential is valid).
  • the authorization time period and access request time period that may be received from the client may overlap.
  • the AS 207 may return or send the requested access ticket(s) to the end-user client 214a-b.
  • the end-user client 214a-b may use an access ticket to request access (e.g., secure access) to an IoT unit 202e-h within the resource domain.
  • the request may be authorized/authenticated, e.g., based on the access ticket the end-user device received from the AS 207 at 2.
  • the client may present the access ticket (e.g., for the entire domain or for one or more IoT devices in the domain) to one or more IoT devices associated with the IoT domain to obtain access to the requested device or resource.
  • the IoT device(s) may authenticate the client based on the access ticket and the credential associated with the ticket, e.g., by comparing the credential associated with the ticket to a credential in the IoT domain (e.g., the one or more IoT devices in the IoT domain) received from the DMS.
  • a credential in the IoT domain e.g., the one or more IoT devices in the IoT domain
  • the examples herein may enable or allow an end- user client, through an (e.g., a single) authorization request, to get one or more ticket(s) that may enable or allow the client to access a set of IoT units (e.g., get authorization for access and authenticate the client to the set of IoT units).
  • the set of IoT units may be associated with (e.g., part of) a specific resource domain (e.g., that includes resource constrained IoT units).
  • the access may be obtained by the end-user client over remote or local interfaces towards the IoT units within the domain.
  • the access tickets may be valid for each of the resources at the specific domain (e.g., not be specific to a particular IoT resource).
  • the tickets e.g., temporary domain credentials
  • the tickets may be used for mutual authentication towards the service or resources or units.
  • Examples herein may enable or allow the resource domain owner to delegate ticket issuing to a third party, e.g., an AS and/or AS owner and/or operator, that may not need to be fully trusted.
  • Relatively short lived credentials may be shared with the AS.
  • the IoT resource owner may stop issuing short lived domain credentials to the old AS such that the old AS may not have an access right to the IoT resource domain once a certain time period elapses.
  • IoT unit identity details for the IoT domain may be hidden to the temporary user or the end-user device (e.g., which may give enhanced privacy).
  • the examples herein may be compatible with other models and/or protocols, such as the pushed base authorization model and protocols in the IETF Authentication and Authorization for Constrained Environments (ACE) (e.g., the DCAF protocol described herein).
  • ACE Authentication and Authorization for Constrained Environments
  • the domain based IoT authentication described herein may be performed over a local interface between the end-user client and an IoT resource (e.g., each IoT resource) within the resource domain.
  • the authentication may be performed in real-time and/or without a connection between the IoT unit and a central system (e.g., to provide faster and more robust authentication even if the IoT unit may have limited network connectivity).
  • the authentication may save power for the IoT unit (e.g., which may be a battery driven device).
  • the systems and/or methods may include one or more of the following: IoT domain credential provisioning and end-user client authorization, credential provisioning, or IoT authentication/authorization in one or more examples.
  • IoT unit may be denoted by u
  • an end-user client may be denoted by c
  • an IoT resource domain may be denoted by d
  • ⁇ Od may denote a unique identifier for domain d
  • a set of IoT units in domain d may be denoted by Ud.
  • a domain key with index i generated by DMS may be denoted as K
  • an expiry time of Ki may be denoted by
  • a global clock that the DMS may have or hold may be denoted by t
  • a local clock at unit u may be denoted by t u .
  • IoT domain credential provisioning may be provided and or used in the systems, instrumentalities, and/or methods herein.
  • the systems, instrumentalities, and/or methods herein may provide an ability for the IoT units to verify end-user client authorizations and to authenticate the connecting unit.
  • symmetric key based credentials may be available to the IoT units.
  • Long-term individual IoT credentials and relative short term domain based credentials may be distinguished and/or provided.
  • the individual IoT credentials may be of any type (e.g., public key or symmetric key based) and may be used by the DMS to authenticate the IoT units in the system and/or to set up secure communication links towards the
  • each IoT unit may be configured with domain information, d, that may be used to determine the specific resource domain that an IoT unit may be part of or belongs to.
  • an IoT unit may belong to multipe domains as well.
  • the configuration may be provided via one or more implementations, e.g., one or more of the following may be provided or performed.
  • IoT unit may, at installation for example, use a mobile device and/or a positioning service (e.g., such as a GPS), a cellular ID, a network ID or other suitable source to obtain location parameters and may send (e.g., from the mobile device) these parameters to the IoT unit over a suitable local interface.
  • a positioning service e.g., such as a GPS
  • a cellular ID e.g., a cellular ID
  • network ID e.g., a network ID or other suitable source
  • u may send this information to the DMS.
  • DMS may use a suitable algorithm to map the location parameters to a zone ID, ID ⁇ , that that may be used to determine the IoT domain in return to the IoT unit.
  • An authorized person at deployment may use a mobile device and a local connection interface to obtain, e.g., from the
  • IoT unit long term or short term IoT unit identity information. This information may be sent
  • the DMS may use a suitable algorithm that may map the location parameters to a domain ID, ID ⁇ , that may be used to uniquely determine the IoT resource domain.
  • the DMS may send the individual credentials and/or the domain ID information to u.
  • An authorized person during IoT unit installation may use a mobile device and a positioning service such as GPS, cellular ID, network
  • the location parameters may be stored (e.g., directly stored) in non-volatile memory for future use.
  • the DMS may periodically issue relatively short lived symmetric key domain credentials in the system.
  • Each such symmetric key may have a limited lifetime.
  • a sequence of domain keys that may be generated by the DMS may be denoted by Ko, Ki, ... , K n .
  • the end time of validity for key Ki may be .
  • These short lived keys may be, according to the examples herein, disseminated or sent to the IoT units in the domain and to the AS responsible for issuing access ticket(s).
  • DMS key generation may be provided and/or used in the systems, instrumentalities, and/or methods herein.
  • the DMS may use a key generation mechanism to regularly update the IoT units in the system with fresh domain keys (e.g., as the domain keys may expire).
  • the DMS may distribute key, K, and the corresponding key expire time, , to each IoT unit in the domain.
  • the DMS may generate these keys according to an example 900 shown in FIG. 8.
  • a DMS e.g., 208a-c
  • PRF Pseudo Random Function
  • y may be an index used to determine the number of keys generated so far (e.g., j may point to the index of the key to be generated next (e.g., as domain keys may expire and may be regenerated as described herein)).
  • the DMS may determine whether tn is greater than ⁇ as shown.
  • the DMS may use a suitable PRF to generate a new domain key, Kj.
  • 5 may be repeated. For example, 5 may be repeated until the time condition described herein is satisfied (e.g., 5 may be repeated while tn may be less than or equal to ⁇ , e.g., until tn is greater than ⁇ ) and/or after 6d may be performed as shown (e.g., the counter may be incremented, whether the time condition is satisfied may be determined, etc.).
  • IoT domain key distribution may be provided and/or used in the systems, instrumentalities, and/or methods herein. Key distribution may be protected through individual security associations that the DMS may store or keep with each IoT unit in the domain.
  • the examples herein may not be limited to a particular secure distribution mechanism, but according to examples, may be made using one or more of the following: a pull based principle and/or a push based principle, e.g., as described herein.
  • a key may be updated or distributed using a pull-based example 1000 for a unit u E U d as shown in FIG. 9. As shown in FIG. 9, at
  • u e.g., 202a-h
  • u may set the current valid key set to empty set, 0 and at 2
  • u may contact (e.g., may send a request or message to) a DMS (e.g., 208a-c) over a secure channel to request the first domain key and/or the current global time, t.
  • the DMS may send or return ⁇ Ko, to ⁇ and/or t.
  • u may synchronize its local clock t u with t.
  • u may use a random source to get a random key update time parameter, ⁇ , where ⁇ ⁇ ⁇ ⁇ ⁇ - a, and where ⁇ may be a suitable time constant significantly larger than 0, and where a may be another time constant close to 0 but not equal to
  • these time constants may determine a time interface less than ⁇ where the different IoT units may request the new domain key before the old one may expire. By choosing the exact time randomly, simultaneous requests towards the DMS may be avoided.
  • a determination (e.g., at 8) may be made by u whether t u may be greater than - ⁇ .
  • u may contact (e.g., send a message or request to) the DMS over a secure channel to request a next domain key and/or expiry time ⁇ Ki+ifi+i ⁇ , u may synchronize its local clock t u with t, u may set the current valid key set to ⁇ Ki, K+i ⁇ , and the example 1000 may continue to 10.
  • 8 may be repeated.
  • 8 may be repeated until the time condition described herein may be satisfied (e.g., 8 may be repeated while t u may be less than or equal to - ⁇ , i.e.
  • a determination may be made at u as to whether may be greater than .
  • i may indicate the "current valid key", e.g., the key index of the key that may be valid for the moment and i may be incremented for each key or new key generated.
  • 10 may be repeated.
  • 10 may be repeated until the time condition described herein may be satisfied (e.g., 10 may be repeated while may be less than or equal to , i.e. until may be greater than , at which point the example may continue as shown).
  • ⁇ may be a suitable time constant less than ⁇ . This may include a time value less than ⁇ but greater than zero.
  • ⁇ may be selected or chosen such that the DMS may be able to perform the key update before the key may expire (e.g., which may depend on the delays in the network, and/or the like).
  • FIGs. 10-11 illustrate pushed-based examples 1100 and 1200 for distributing or updating a key at a DMS (e.g., 208a-c) and at an IoT unit u (e.g., 202a-h), respectively.
  • the DMS may contact (e.g., send a message, and/or the like to) each unit u E U d to synchronize the local clock, t u , that may be maintained by u with t.
  • the DMS may use the individual security association that it shares with each u E U d to securely distribute ⁇ Ko,to ⁇ to each u.
  • ⁇ Ko,to ⁇ For example, at 2 in FIGs.
  • the DMS may send the keys to the u and the u may receive the keys.
  • each unit u E U d may set the current valid key to ⁇ Ko ⁇ .
  • i may be used to keep track of the current valid key, e.g., the index of the key that may be valid for the moment or currently valid.
  • a determination may be made as to whether t may be greater than - ⁇ .
  • the DMS may, at 5a as shown in FIG.
  • the message may be protected by the current domain key (e.g., encrypted with a key derived from the domain key, Ki).
  • the message may include the index and expiry time for the new key, e.g., the message may include the parameters ⁇ K i, U, t) .
  • a determination may be made at 5 about whether a new message (e.g., a new broadcast message) has been received from the DMS. If the determination by a unit is that the key message has been received before, the unit may discard (e.g., silently discard) the message and may wait for another or the next key update message.
  • the unit may perform one or more of the following.
  • the unit u may synchronize its local clock, t u , with the received global clock t (e.g., if the unit has not received the message before).
  • the received key, Ki may be added to the valid key set: ⁇ Ki-i, K ⁇ and the examples 1 100 and 1200 may continue to 7. 5 may be repeated. 5 may be repeated until the time condition described herein may be satisfied.
  • 5 may be repeated while t is less than or equal to - ⁇ (e.g., until t is greater than U - ⁇ ), at which point the example may continue as shown in FIG. 10.
  • a new broadcast message may be received (e.g., after 7a in FIG. 10 and/or 7b in FIG. 1 1).
  • a determination (e.g., at 7) may be made at the DMS and/or the unit u about whether t may be greater than or whether t u may be greater than , respectively.
  • the unit u may set the current valid key to ⁇ K-i ⁇ .
  • the examples 1 100 and 1200 may continue to 5. 7 may be repeated. For example, 7 may be repeated until the time condition described herein may be satisfied. For example, 7 may be repeated while t may be less than or equal to or while may be less than or equal to (e.g., until t may be greater than or may be greater than ), at which the example may continue as shown in FIGs. 10 and 1 1 respectively.
  • a domain key may be transferred from a DMS (e.g., 208a-c) to the AS (e.g., 207).
  • the DMS may select or choose to distribute a set of keys to the AS.
  • the DMS may put in the AS.
  • the DMS can use several different strategies for the key transfer.
  • the DMS may make sure it has pre-distributed a sequence of domain keys ⁇ K, ⁇ , ⁇ K+i,ti+i ⁇ , ... , (e.g., assuming the current valid index at the DMS may be i) and that their expiry time may be far enough in advance before they may be "consumed” (e.g., used, issued, etc.) by the AS (e.g., in the form of issued end-user client tickets).
  • the DMS may send a time "normalization constant," tc, that may define the UTC time for the first period for the "global" clock that the DMS may use.
  • the AS may map UTC time to the "global" time used by the resource domain.
  • the exact number of keys to distribute in advance may depend on the validity time for each key and depending on the particular use case (e.g., whether or not the AS may need to issue access tickets far in advance before they may be consumed).
  • the DMS may send the domain keys over a secure and/or protected secure channel to not compromise the confidentiality of the domain keys.
  • end-user client authorization, provisioning and/or authentication may be provided and/or used.
  • end-user client credential provisioning described with respect to FIG. 7 and associated with the DCAF protocol may be provided.
  • How the end- user client may find out the address of the devices in the requested resource domain as well the address of the AS serving the domain may vary.
  • An example may include using the Service Authorization Manager principle when trying to access the resource in accordance with the DCAF.
  • How the AS may determine if it should allow issuing of an authorization ticket to the end-user client may vary.
  • One or more of the mechanisms described herein may be used. As shown in FIG.
  • the end user client may issue, at 1, an "access request" message towards the AS (e.g., 207), e.g., over an authenticated and secure channel such as Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS).
  • This message may include one or more of the following parameters: a unique identifier of the resource domain that the client may want to access, specification on the actions that the client may want to perform on the devices in this domain, UTC time parameters specifying the time period for which the end-user client may request the access to the requested resources in, such as th, t2 c (e.g., from th until t2 c ), and/or the like.
  • the AS may evaluate the access request received at 1 and/or whether the client may be authorized to access the requested domain and actions, and if so, issue access ticket(s) to the client. If the access request passes the evaluation, the AS may perform one or more of the following. The AS may evaluate the ticket start time, th, and end time, t2 c , for the request access period and may calculate th - tc and t2 c - tc to map the requested UTC period to
  • the requested time period may correspond to time slots , ... , ⁇ Kk,tk ⁇ , where / may be equal to k (e.g., when the requested time period maps to a single domain key slot).
  • the AS may generate a secret key, KC-R, that the client and an arbitrary IoT resource may use to mutually authenticate each other (e.g., using the DTLS PSK protocol).
  • the AS may generate multiple secret keys, one per ticket, e.g., instead of a single key.
  • the AS may send or return a Ticket
  • TGM Grant Message
  • the number of tickets may be equal to k - 1 +1.
  • Ticket may include one or more of the following parameters: KC-R, which may be intended for use by the end user-client, end user client authorization information or All that may inform the end-user client the exact access privileges for the end-user client in the resource domain, a ticket part intended for the IoT unit when access is requested (e.g., which may be referred to as a face).
  • the face may include one or more of the following: a domain key index, k +i, which may be integrity protected under the domain key Kk+i (e.g., directly protected by a Message Authentication Code calculated using Kk+i or through a integrity protection key derived from .&+/), authorization information or A ll that may be integrity protected under the domain key Kk+i, a ticket validity period in resource domain global time
  • Kk Kc-R that may be encrypted under the domain key Kk+i (e.g., directly encrypted using Kk+i as encryption key or by an encryption key derived from Kk and/or the like.
  • the client e.g., 214a-b
  • u may perform one or more of the following.
  • the client e.g., 214a-b
  • the client may send the face part of the ticket T; to u (e.g.,
  • the face may be sent as psk identity in the DLTS client key-exchange message.
  • u may check the domain key index, k+i, of the received ticket and determine whether the index corresponds to a current valid domain key. If the index corresponds to an expired domain key, u may send or return a failure message to the end-user client indicating "expired key in ticket.” Otherwise, u may continue to verify the ticket validity of the face (e.g., using the local clock as described herein).
  • the resource u may check the integrity of the received face using key Kk If the integrity fails, u may abort the activities with an
  • the resource u may further check the authorization information, A U, of the received face using key Kk+t. If the check fails, u may abort the activities with an "authorization failure" message to the end-user client. In an example, u may verify the ticket validity of the received face using the local clock, t u . If the check fails, u may abort the activities with a "ticket expired" message to the end-user client. If the check succeeds, u may decrypt the key KC-R using the domain key Kk The resource u may proceed with the authentication/secure channel set-up using the key KC-R for both the authentication and secure channel set-up. This may be done by completing a DTLS handshake using KC-R as PSK.
  • the DMS may keep the generated domain keys centrally at the DMS (e.g., not distributing the periodic keys to each IoT unit in the domain using examples described herein).
  • an IoTdevice may contact the DMS to verify the ticket it received from the connected client.
  • the DMS may not need to distribute the domain keys, and a compromised IoT unit may not issue its own false tickets.
  • the communication burden on the IoT units may increase.
  • a fast real-time connection to the DMS may be used for the authentication of the end-user clients (e.g., which may be a limitation in situations when local authentication over a short range wireless interface may be made).
  • This example implementation may be shown in FIG. 12. For example, at 3, when a client device wants to get secure access to an arbitrary IoT resource u (e.g, within a certain domain), the client device may send the face part of the ticket T; to u.
  • the face may be sent as psk identity in the DLTS client key-exchange message.
  • u may forward the face part of the ticket, e.g., via a protected channel (e.g., that may be protected using the individual IoT unit to DMS secure credentials), to the DMS that may perform the following.
  • the DMS may check the domain key index, k+i, of the received ticket and determine whether it corresponds to a current valid domain key.
  • the index may send or return a failure message to u indicating "expired key in ticket.”
  • the DMS may check the integrity of the received face using key Kk+ If the integrity check fails, the DMS may abort the procedure 1300 with an "authentication failure" message to u.
  • the DMS may check the authorization information, A U, of the received face using key Kk+u If the check fails, the DMS may abort the procedure 1300 with an "authorization failure” message to u.
  • the DMS may verify the ticket validity of the received face using the clock t. If the check fails, the DMS may abort the procedure 1300 with a "ticket expired” message to u.
  • the DMS may decrypt the key KC-R using the domain key Kk and may send KC-R over the protected channel to u.
  • this may be done by completing a DTLS handshake using the key KC-R for the authentication and secure channel set-up. According to one example, this may be done by completing a DTLS handshake using
  • FIG. 13 illustrates an example of a system 1400 in which one or more examples described herein may be used and/or implemented.
  • the system 1400 may include remote and direct control of an IoT infrastructure of a property.
  • the property may be, for example, a property for rental on daily, weekly or monthly basis.
  • the property have an advanced supporting IoT infrastructure that may include, for example, remote/internet control of heating and temperature sensing, remote/internet control of network video surveillance equipment, remote/internet based control of an entrance gate, garage and house door locks, smart phone based wireless control of an in-house entertainment system, building control system, and/or the like.
  • the examples herein may assist an end-user and property owner to offer the end-user the desired temporary access to the property IoT infrastructure without compromising the long- term security of the system, e.g., 1400.
  • the property owner may have outsourced to a third party service provider the online contract signing for property rental and/or the authorization/access control of the IoT infrastructure of the property (e.g., the third party provider may run the AS function according to the examples described herein).
  • an end-user may be looking online at 1 (e.g., via a client 214a-b) for a property to rent for one week. After some searching, the user may find a suitable property for the desired period with start date and time wi and end date and time W2. The end-user may agree and sign online a contract, and may pay a party for the rental service for the desired property and time-period.
  • the AS e.g., 207) may receive and translate the requested time period wi -W2 to the "global" time maintained by the subject DMS (e.g., one of 208a-c in an example), w 'i - w '2.
  • the end-user may receive or get from the serving AS one or more of the following downloaded to his mobile unit (e.g., 214a-b).
  • the end-user may receive two accesses tickets, T a i and T a 2, generated as described herein for access to the video cameras covering the property inside and outside, as well as temperature sensors and heating control in the property.
  • Corresponding domain keys in the property may span two access time periods (e.g., each key covers a particular time period). The two domain keys may be denoted by Ki and K2 respectively.
  • Ticket T a i may include a secret symmetric key Kai and ticket T a 2 may include a secret symmetric key Ka2.
  • the validity time for T a i may start, in an example, three hours before w ⁇ and ends at time ti.
  • the validity time for Ta2 may start at ti and may end at time w '2.
  • the end user may receive two access tickets, Tbi and Tb2, generated as described herein for access to the electronic gates and/or doors on the property as well as for access to the in-house entertainment system and building control system.
  • the domain keys associated with the property may span two key periods.
  • Ticket Tbi may include a secret symmetric key KM and ticket Tb2 may include a secret symmetric key Kb2. These keys may be included in encrypted form in the face part of the tickets intended for the IoT resource (e.g., encrypted using Ki and K2 respectively).
  • the validity time for Tbi may start at time w ⁇ and may end at time ti.
  • the validity time for Tb2 may start at ti and may end at time w '2.
  • the end user may receive or get URLs to the video and temperature units in the property, e.g., in addition to or as part of the tickets.
  • the end-user may want to check that everything looks as expected at the property.
  • the end-user may use his mobile unit (e.g., 214a-b) and the URLs received at 1 to access the video cameras mounted in the property.
  • the video cameras may use DTLS protected authentication and secure channel for access.
  • the end-user device may present or send a ticket when connecting to a video camera at the property such that they are able to perform mutual authentication and/or a secure channel set-up based the ticket, e.g., T a i (e.g., with key K a i), for example using the methods described herein.
  • the end-user may want to check the temperature in the different rooms of the property and may (e.g., directly) connect to temperature sensors inside the property and adjust temperature by connecting to heating control units inside the house. These connections may be DTLS protected. Authentication may be performed using ticket Tai (e.g., with key Kai).At 3, the end-user may arrive by car to the entrance gate of the rented property. The end-user may use his mobile device (e.g., 214a-b) to request a gate opening over a short-range wireless protocol such as Bluetooth. The electronic gate may use DLTS PSK based authentication. The end-user device may present the ticket Tbi and may use KM for mutual authentication with the gate control. Automatic opening of the gate may be achieved.
  • ticket Tai e.g., with key Kai
  • At 3 the end-user may arrive by car to the entrance gate of the rented property.
  • the end-user may use his mobile device (e.g., 214a-b) to request a gate opening over a short-range
  • the end-user may arrive at the rented house at 4.
  • the end-user may use
  • the end-user may want to play his favorite HiFi music using his mobile device (e.g., 214a-b) through the house entertainment system.
  • the end-user device may find the entertainment system service on the local WLAN that may be connected to an open network. The finding may be performed using a suitable discovery protocol.
  • a secure DTLS session may be set up with the controlling unit.
  • the end-user device may send or present ticket Tbi but may receive a "time expiry" failure message back (e.g., the end-user device may start with the oldest ticket, but such ticket may have expired).
  • the end-user device may present ticket Tb2 and may be able to, for example, use this ticket and key Rb2 to set up a secure connection with the HiFi control system and play his favorite music.
  • the keys may be used for the rental time period and may expire upon the rental time period end.
  • the examples herein may provide efficient and/or flexible authentication and key exchange for secure connections between end-user device and an IoT infrastructure given that this end-user device may have temporary access rights.
  • the domain key based examples herein may enable or allow efficient authentication towards a large number of IoT units and/or local authentication (e.g., without using a real-time connection between the IoT units and a central key service or a key distribution center).
  • the example techniques may be used in combination with other examples such as Kerberos and the DCAF protocol for resource constrained devices, and/or the like.
  • the examples herein may use a domain key distribution scheme that may enable or allow authorization for an IoT service domain in a single authorization request. From a security point of view, a compromised IoT unit may be used as vehicle to compromise the system.
  • an IoT unit e.g., each IoT unit
  • the example methods, instrumentalities, and/or systems may provide a fair trade-off between security and user friendly and efficient authentication and key exchange.
  • Public key cryptography may be used.
  • secure clock accuracy may be desirable.
  • Clock synchronization may be a part of the examples described herein.
  • Systems, instrumentalities, and/or methods may be provided for fraud detection during authorization and authentication of end-user devices of IoT units within a single domain (e.g., a single administrative domain).
  • the systems, instrumentalities, and/or methods may provide one or more actions that may help prevent an attack (e.g., if a single and/or more IoT units may be compromised such that a IoT domain wide key may be obtained by the attacker that may use an end-user device connected to or granted access to the domain) such that the attacker may not be able to issue valid access tickets for the domain.
  • the examples herein may provide access ticket integrity and secure logging.
  • the IoT domain owner may be able to detect the fraud and perform or take one or more proper counter measures such as identifying the compromised IoT unit or units in the system.
  • one or more of the IoT units may have weak protection of long term or short term keys used to secure the system.
  • the IoT units e.g., with the weak protection
  • the security of the system e.g., system
  • the system may benefit from a method that at least detects the occurrence of the compromise (e.g., when an attacker may compromise an IoT unit in order to get access to the services provided within the domain), for example as described herein.
  • FIG. 14 illustrates an example of log protection according to one or more examples herein.
  • one or more examples herein e.g., the example shown in FIG. 1 and/or the example of FIG. 7, which may be modified
  • examples herein may use a robust and efficient system for protection of security logs for distributed IoT units (e.g., 202e-h as shown and/or 202a-d in FIG. 1).
  • an IoT unit e.g., each IoT unit within a single distributed domain (e.g., Domain A) may store log information (e.g., new log information) in its own local storage and/or may use protected (e.g., confidentiality and integrity protected) broadcast to transport this information to the other IoT units within the domain.
  • log information e.g., new log information
  • protected e.g., confidentiality and integrity protected
  • one or more of the other units e.g., after secure verification of the broadcasted log
  • the other units may store the same log information in their local storage.
  • loss of a single log entry or several log entries in a single or a limited number of units may not imply a risk that security critical log information may be lost.
  • keys may be distributed among the IoT units (e.g., 202e-h) within a domain.
  • the keys e.g., group master secrets
  • the group master secrets may be shared among the IoT units using a secret sharing scheme. This may enable or allow stronger protection of these group master keys, e.g., without the use of special key protection hardware.
  • a domain wide key may be kept in volatile memory, thus making it harder for an attacker with physical access to the device to get ahold of this key.
  • the group master keys may be used to derive domain wide shared keys for one or more units (e.g., for all units) within a domain to protect the broadcasted log messages. Together with an IoT unit individual integrity protection key (e.g., a secret index or vi), the GM may be used to protect individual log entries from other IoT units (e.g., all of the IoT units).
  • the individual integrity protection key may be stored in non-volatile memory and updated using a hash chain. This may provide and/or mean that keys that may be used for the integrity protection of individual logs may not be stored in potentially vulnerable local persistent storage and instead should be stored on volatile memory on the devices.
  • the examples herein may provide and/or be used to securely generate log protection keys and/or to protect the actual log information in the domains.
  • One or more of the following may be applied: log protection key distribution and configuration; secure log generation and distributed storage and key update procedures; protected log collection, verification and memory clean up; log protection key recovery at system power loss or reboot; and/or the like.
  • systems, instrumentalities, and/or methods for authorizing and authenticating end-user devices for temporary access to an IoT domain may be provided and/or used.
  • the examples herein may be based on the generation of time limited IoT domain keys that in turn may be used for authenticating end-user devices in the whole domain.
  • an authorization server e.g., AS 207
  • AS 207 may be responsible for the generation of a session key and corresponding authorization ticket that end-user devices may use to get access to and/or set-up secure connection with the IoT domain.
  • This mechanism may provide an improved security level and may protect the IoT domain owner from misuse by the authorization server domain, e.g., as that domain may not have access to long term domain keys and instead may have access to time limited keys.
  • IoT unit may be compromised such that the time limited IoT domain wide key or set of keys may be leaked to an attacker.
  • the attacker may use this key or keys to generate false but still "valid" access tickets (e.g., that may provide and/or enable access to services in the domain and/or to access the IoT units therein) to non-legitimate end-user units.
  • An IoT unit may be compromised such that the long term secret used to authenticate the unit and/or to set up secure connection with the IoT domain key generation system may be compromised and the attacker may be able to get all key -updates and then may be able to get hold of all IoT domain keys issued by the key generation system in the IoT domain. This in turn may allow the attacker to issue arbitrary false but still "valid" access tickets (e.g., that may provide and/or enable access to services in the domain and/or to access the IoT units therein) to non-legitimate end-user units.
  • arbitrary false but still "valid" access tickets e.g., that may provide and/or enable access to services in the domain and/or to access the IoT units therein
  • these attacks may be possible, for example, if there may be a weakness in the IoT unit security implementation (e.g., rather than a system weakness of the design described herein).
  • a weakness in the IoT unit security implementation (e.g., rather than a system weakness of the design described herein).
  • it may be costly to implement high protection in resource constrained IoT units.
  • the authorization/authentication system may benefit from detecting this type of fraud (e.g., by an attacker as described above) and making the overall solution more robust. Examples herein may provide such a detection and improve such robustness.
  • the DMS (e.g., 208a-c as described herein), which may be in the resource domain, may generate an "integrity key generation secret" or K g (e.g., in addition to the periodic transfer of time limited domain credentials), which may be securely transferred to the AS (e.g., 207).
  • K g e.g., in addition to the periodic transfer of time limited domain credentials
  • This secret may be used by the AS to generate ticket unique integrity keys that in turn can be used to calculate ticket integrity protection codes.
  • the ticket integrity protection may, together with a secure log or secure log mechanisms, be used by the DMS to distinguish legitimate access tickets generated by the AS from potential fraudulent tickets generated by, for example, compromised IoT resources (e.g., resources that have access to the domain wide secrets that potentially can be used to issue false access tickets).
  • compromised IoT resources e.g., resources that have access to the domain wide secrets that potentially can be used to issue false access tickets.
  • FIG. 15 illustrates an example 1500 for detecting fraud in a domain according to one or more examples herein.
  • a method, system, or process 1500 may include one or more of the following.
  • the DMS e.g., 208 as shown in Domain A
  • the DMS may generate a new integrity key generation secret (e.g., a ticket generation key), Kg.
  • the DMS may securely transfer K g to the AS (e.g., 207).
  • the DMS may further send a credential or key and/or an access time or authorization time period during which the credential or key may be valid for an IoT domain and may be used to generate an access ticket in examples (e.g., as shown).
  • the AS When the AS generates new access tickets
  • a ticket unique integrity protection key IK m ⁇ KF(K g ,ai,i), where PRF may be a suitable Pseudo Random Function (PRF).
  • PRF Pseudo Random Function
  • This key may be used to integrity protect an access ticket (e.g., which may be generated using the key or credential associated with the IoT domain) by calculating a secure Message Authentication Code (MAC) over the face part (e.g. the complete face part) of ticket information including the ticket index a i.
  • the MAC may be added to the face part of the ticket (e.g., the access ticket).
  • a ticket (e.g., the access ticket) may be integrity protected at 3 according to examples herein. In an example, this may be performed in response to a domain access request received at the AS at 1 1 and the access ticket may be sent to the end user client that may be integrity protected at 12 as shown.
  • An IoT unit (e.g., 202e-h) may receive an access request from an end user device
  • An IoT unit may log the complete ticket value (e.g., the access ticket) used for the access including the MAC at 4.
  • the IoT unit may use, as described herein, a secure logging mechanism (e.g., as shown and described with respect to FIG. 14) to securely record the log data and transfer (e.g., periodically and/or securely) the log information to the DMS at 5.
  • the integrity key candidate may be used to calculate an integrity check value (e.g., a second MAC) over the face parts of the ticket (e.g., except the MAC included in the ticket or the first MAC).
  • the integrity key candidate may be used to calculate a MAC for the face parts such as a second MAC or MAC that may be compared with the MAC generated by the AS and included in the ticket.
  • a fraud warning may be issued, at 6, by the DMS such that the domain owner may check the potential reason for the false ticket (e.g., the access ticket being false based on the MAC calculated independently from the ticket generation key, an integrity key generation secret not matching a MAC generated from values in the ticket (e.g., not including MAC), etc.).
  • the domain owner may also determine if an IoT unit in the domain may have been compromised.
  • the warning may include information such as one or more of the following: a time of issue of the ticket, which domain key may have been used to issue/verify the ticket, the ticket index, a ticket validity period, access type granted, which IoT unit received the ticket and/or from which client, and/or the like.
  • an end-user may use the end-user client or device 214a-b to contact the responsible AS and request access to the subject IoT resource domain (e.g., A).
  • This request may include information (e.g., detailed information) such as what type of services within the domain the user may be interested to obtain access for, the requested time period for such access, and/or the like.
  • the end-user client may send information regarding the IoT resource (e.g., or service) in the IoT domain the end-use client may want to access and an access request time during which the IoT resource may be used or access may be desired.
  • the IoT resource e.g., or service
  • the AS may examine or evaluate the access request (e.g., may determine whether the request may have the necessary information).
  • the AS may request additional information from the end-user connected to the requested service such as payment information, end-user authentication information, and/or the like.
  • the AS may determine whether the requested IoT resources (e.g., or services) in the domain may be available for the requested period. If AS determines that the access request may be granted (e.g., the resources may be available and/or the information provided and/or additional information may be the information needed by the AS 207), the AS may use a temporary credential or credentials or key it may have received from the DMS 208a to issue one or more access tickets (e.g., IoT domain access tickets).
  • IoT domain access tickets e.g., IoT domain access tickets
  • one or more tickets that may be provided or used may depend on a requested time period.
  • the periodic domain credentials the AS may have received from the DMS may be valid for a period of time that spans a part (e.g., including the entirety) of the requested access period.
  • the AS may receive the secret generated at 1 and received at 2 to issue and/or generate the ticket or access ticket as described herein.
  • an IoT domain access ticket may be generated based upon a credential or key associated with the IoT domain and/or an authorization time period for the credential or key.
  • the credential or key, and/or the authorization time period may be received from the DMS.
  • the access ticket may be generated based on the integrity protection key (e.g., from an independent ticket generation key separate from the credential or key) that may be used to integrity protect the ticket and/or an index.
  • the AS may return or send the requested access ticket(s) to the end-user client 214a-b.
  • the AS may send the ticket(s) to the end-user client 214a-b.
  • the tickets may be integrity protected at 1-3 as described herein.
  • the tickets may be an access ticket that is integrity protected such that a MAC may be included and/or used to determine whether access should be granted and/or whether the access or ticket is valid, for example.
  • the end-user client may use an access ticket to request secure access to an IoT unit 202e-h within the resource domain.
  • the request may be authorized/authenticated based on the access ticket (e.g., the access ticket) the end-user devices received from the AS at 2.
  • the client may present the IoT domain access ticket to one or more IoT devices associated with the IoT domain to obtain access to the requested device or resource.
  • the IoT devices may authenticate the client based on the access ticket and the credential associated with the IoT domain received by the IoT devices from the DMS.
  • 4-6 may be performed as shown (e.g., to determine whether the access ticket or ticket may be valid).
  • the examples herein may enable or allow the domain owner to detect if an IoT unit in the system may have been compromised and/or whether the compromised IoT unit may be used or utilized to issue false access tickets in the system.
  • a compromised IoT unit may not adhere to the examples herein and may not send secure logs to the DMS.
  • one or more (e.g., each) of the non-compromised IoT units may send such logs.
  • an attacker connecting to these non-compromised IoT unit using faked access tickets e.g., tickets constructed from a compromised IoT unit
  • Such detection may be provided with the examples herein as an attacker may be more motivated to try to get false access(using faked tickets) to non-compromised parts of the system than an already compromised IoT unit
  • an attacker may attempt to attack the AS to circumvent the example protection scheme.
  • Such an attack at the AS may be harder than compromising a single IoT unit.
  • compromise of a single IoT unit long term secret may be more severe than compromise of the AS, as that may enable the attacker to get access to one or more (e.g., each) of the domain keys generated by the DMS.
  • the protection example e.g., fraud detection
  • the protection example may provide an overall robust scheme.
  • examples herein may provide lower additional complexity and/or implementation costs.
  • the example methods, systems, and/or instrumentalities for detecting fraud and/or protecting against an attack as described herein may include one or more of the following:
  • ticket integrity protection (e.g., at the
  • an IoT unit may be denoted by u; an end-user client may be denoted by c; an IoT resource domain may be denoted by d; a complete set of IoT units in domain d may be denoted by Ud a domain key with index i, generated by
  • DMS may be denoted as KL ; a ticket generation secret may be denoted by K g ; a ticket index corresponding to the domain key Ki may be denoted by a,i; an access ticket with ticket index a, i generated by the AS may be denoted by 7 ⁇ ; a ticket unique integrity protection key for the ticket with index a,i may be denoted by IK , a message authentication code calculated over the face part of a ticket (except the MAC itself) using an integrity key, IKm , may be denoted by MAC; a maximum number of access log entries that may be allowed to be stored locally by the IoT units in the system before transferring them to the DMS may be denoted by s.
  • fraud detection and/or attack prevention may include generation and distribution of ticket generation secret.
  • the DMS may use any suitable key generation mechanism to generate a random key of sufficient length
  • the key may be generated directly from a good random source (e.g., collected from a noise signal for instance), through the generation of a pseudo random key using a good random seed value from a random source (e.g., such as one generated from a noise signal) and a Pseudo Ransom Function (PRF) that may receive or take the seed value as input and a pseudo random value as output, and/or the like.
  • a good random source e.g., collected from a noise signal for instance
  • PRF Pseudo Ransom Function
  • This key may be denoted by Kg.
  • the key .K may be securely stored on the DMS side for future use.
  • the DMS may securely transfer (e.g., over a confidentiality and integrated protected channel) the ticket generation secret K g to the AS. This may be part of the secure domain keys transfer as described herein and/or through a separate secure transfer session 1600 as shown in FIG. 16.
  • the example for fraud detection and/or attack prevention may include ticket integrity protection (e.g., at the AS such as the AS 207).
  • the AS may follow the examples (e.g., shown in FIG. 15) as described herein for receiving access requests and/or generating access tickets.
  • the AS may be responsible for issuing unique ticket numbers to one or more (e.g., to each) newly generated access ticket.
  • the AS may keep track of the number of issued tickets per domain key (e.g., it may keep an index value for each new ticket that may have issued).
  • FIG. 17 illustrates an example 1700 that may be used for ticket integrity protection as described herein.
  • the AS e.g., 207 may receive from the DMS (e.g., 208a-c) a set of domain keys, K r , K r +i, K r + n -i.
  • the AS may set the ticket indices cir,a r +i, ... , cir+n-i all to 0.
  • a determination (e.g., by the AS) may be made at 3 as to whether an access request may be received from an end-user client (e.g., 214a-b).
  • a new access request may be received from an end user-client (e.g., based on the determination at 3)
  • the AS may move to or perform 6 in the example 1700.
  • a determination e.g., by the AS
  • the AS may move to or perform 1 in the example 1700.
  • the AS may move to or perform 3 (e.g., again) in the example 1700.
  • the AS may evaluate the new end-user access request.
  • the request may be evaluated by authenticating the requested client or client device and/or issuance of payment from the requesting client or client device, and/or the like.
  • a determination may be made (e.g., by the AS) regarding whether the access request may be accepted (e.g., if it may be authenticated and/or if payment may be accepted).
  • integrity protection and/or keys may be generated and/or applied to a ticket (e.g., 8 may be performed).
  • the access request in examples, may be for domain ticket slots l...k.
  • the AS may issue or generate k-l+l new access tickets for these slots.
  • k may be equal to / and in this case one ticket may be issued or generated.
  • the access ticket indices for these slots may be given by a i.
  • the integrity check code may be used to make sure the ticket may not be false (e.g., it is indeed issued by the AS that may have the valid a compromised IoT unit may not have).
  • the examples for fraud detection and/or attack prevention may include ticket integrity protection (e.g., at the AS such as the AS 207).
  • the examples for fraud detection and/or attack prevention may include access logging at an IoT unit (e.g., 202a-h).
  • the IoT unit u E U d may verify access requests from end-user clients and may further record and/or store successful access connections in an access log.
  • the IoT unit may have the possibility to store a limited number of log entries locally and when the number of items exceeds a threshold value (e.g., a pre-defined threshold value), s, the IoT unit may securely transfer the complete log to a back-end system (e.g., the DMS).
  • a threshold value e.g., a pre-defined threshold value
  • FIG. 18 illustrates an example 1800 that may be used for access logging as described herein (e.g., at an IoT unit such as 202a-h).
  • a new access attempt from an end-user client c (e.g., 214a-b) may be sent from and may be received by the IoT unit at 2.
  • the IoT unit u may evaluate the access request at 3. For example, a determination (e.g., by the IoT unit) may be made at 4 on whether the access request may be accepted (e.g., based on IoT validation examples described herein). According to an example, if the access request based on the determination at 4 may be invalid, the IoT unit may move to and/or perform 2. If the access request based on the determination at 4 may be valid, the IoT unit may perform 5.
  • a new secure connection may be established between u and the connecting c (e.g., as shown in 13 in FIG. 15).
  • the face part (e.g., as described herein) of the received ticket may be extracted (e.g., together with the time for the access request as well as the unique identity of the unit u) , and may be securely stored in local non-volatile memory (e.g., using any suitable mechanism) and/or may be broadcasted to other IoT units in the same network domain.
  • Such extracted information may be provide in a log (e.g., a log for access logging as described in FIG. 14 and/or as described in PCT App. No.
  • Such logged information (e.g., the complete log entry) may be denoted by L r and stored as described herein (e.g., in non-volatile memory).
  • IoT units within one local network domain may store log entries from devices in the domain.
  • the total number of stored log entries e.g., also including log entries from adjacent IoT units
  • the IoT unit u may set up a log transfer session with the DMS and may send or transfer securely log entries, Lo, Li,... , L s stored in local non-volatile memory to the DMS. Any suitable method may be used for such a transfer including, for example, IoT units in the same domain sharing log information from other units and collaboratively and securely transferring the information to the DMS.
  • the IoT unit may delete stored log entries from local non-volatile memory.
  • the IoT unit may then move to or perform 1 in the example 1800.
  • the examples for fraud detection and/or attach prevention may include log verification (e.g., at the DMS).
  • the DMS may collect (e.g., regularly collect), using a secure log transfer and integrity protection mechanism, log entries from the unitsw £ U d .
  • the following may be performed or applied (e.g., by the DMS): the access time, IoT unit identity u, as well as ticket face information from each log entry L E ⁇ L 0 , h x , ... , L s ] may be extracted (e.g,.
  • the DMS may determine whether MAC ⁇ MAC ' where MAC ' may the integrity check value in the face field based on such a determination (e.g., the MAC not equaling the MAC), the DMS may send a fraud alert warning to the system administrator of the domain.
  • FIG. 19 illustrates an example of a system 1900 in which one or more examples described herein may be used and/or implemented.
  • the system 1900 may include remote and direct control of an IoT infrastructure of a property (e.g., a property for rental on daily, weekly or monthly basis) with an advanced supporting IoT infrastructure that includes, for example, remote/internet control of heating and temperature sensing, remote/internet control of network video surveillance equipment, IoT based control of entrance gate, garage and house door locks, profiling and smart phone based wireless control of in house entertainment system, building control system, and/or the like.
  • IoT infrastructure of a property e.g., a property for rental on daily, weekly or monthly basis
  • an advanced supporting IoT infrastructure that includes, for example, remote/internet control of heating and temperature sensing, remote/internet control of network video surveillance equipment, IoT based control of entrance gate, garage and house door locks, profiling and smart phone based wireless control of in house entertainment system, building control system, and/or the like.
  • a legitimate end-user may rent the property and get temporary access credentials to the property.
  • the user may use the temporary physical access to the property to attack an IoT unit in the property to generate false access tickets to get access to the property IoT infrastructure after the renting period may have ended.
  • Such an attack may be detected and/or prevented using the systems, instrumentalities, and/or methods described.
  • an end-user e.g., 213a-b
  • an attacker may be looking online (e.g., via a client 214a-b) for a property to rent.
  • the attacker may find a property and may contact the corresponding AS that issues access tickets for access to the property.
  • the attacker may pay for one week, and may receive the access tickets Ti and T2 giving him or her both physical and remote access to the desired property.
  • the attacker may use the received tickets, Ti, to get the desired access to the property at the rental time period.
  • the access tickets may allow or enable him or her to open electronic gates and doors and enter the property.
  • the attacker may have access to the local entertainment system.
  • the attacker may manage to install a Trojan in the entertainment system that may send or forward received domain keys that the DMS distributes to the attacker's external server on the internet.
  • the attacker may wait some weeks and then may use his or her external server to get access of the current valid domain key Ki and may use this key to issue a "valid" access ticket, ⁇ , that may give him or her both physical and remote access to the IoT units of the property for the upcoming period.
  • ⁇ a "valid" access ticket
  • the attacker may not have access to the key K g and may choose a random sequence, R, as the MAC value in the ticket. This may cause the MAC to be not equal to MAC thus indicating an invalid ticket as described herein.
  • the attacker uses his or her car to enter the property gate which may be successful using the ticket ⁇ .
  • the property gate may belong to a highest security class and it may, after a very short period after the successful access, send the access log entry to the DMS according to the examples herein.
  • the DMS may determine or notice that MAC ⁇ MAC and that the fraudulent ticket has been used to enter the property gate.
  • the DMS may immediately issue a "lock" message to IoT units in the domain such that the IoT units may not accept any more access attempts until the system may reset. Further, in an example, an alarm may be sent to a security firm.
  • the attacker may try to use his/her access ticket to also get into the house on the property. However, he/she may not be able to open the door through the access ticket. Furthermore, the attacker's vehicle may be trapped on the property as he/she will not be able to open the property gate with the false access ticket.
  • the property owner may (e.g., after the alarm) be able to hire a network security expert that may investigate the internet traffic in the domain.
  • the Trojan in the entertainment system may be detected and removed.
  • the examples herein may show how a weak point of granting temporary access may compromise a system and how such compromises may be avoided at least partially. Further, examples herein may provide an ability to use a symmetric key based approach for the temporary access to a network domain scenario and public key based solutions. In such examples, certificate based solutions may provide revocation support in order to give a high security level
  • a third party AS ticket granting service may be provided and/or used.
  • a public key scheme that may add complexity with respect to "certification" of the third party public key of the AS function in the system, and/or the like.
  • a public key base scheme may have one or more drawbacks, e.g., in terms of compatibility with the proposed new DCAF scheme, ability to work with resource constrained IoT units, and/or speed for authentication and secure channel set-up.
  • examples herein may use such public key based approaches in order to provide broad coverage, to avoid work-arounds, and/or the like.
  • the example systems, instrumentalities, and/or methods herein may have relative low complexity as it may not be dependent on online connections at the authorization/authenti cation occasion, and may provide fast authorization and authentication for resource constrained devices. Further, the usage of time limited domain keys may imply or provide that even if these keys may be shared within the whole domain and the system may be sensitive to attacks, the effects of a compromise may be limited (e.g., as the keys may be regularly updated).
  • the long-term secrets of IoT units may be a potential target for an attacker trying to get hold of domain keys generated by the DMS. Such attacks on the IoT units can be detected by the mechanism described in the examples herein.
  • a public key based scheme may be less sensitive to compromise of a single or a few IoT units and may use a domain wide secure system for clock synchronization.
  • Another type of attack of the system that may be provided may be compromise of an end-use client. Such an attack may allow cloning of access tickets.
  • the risk and consequences of such an attack may be the same for the examples herein.
  • the consequences of such attack may be less severe than an IoT unit compromise (e.g., as the attacker may not be able to get any more access rights than the original cloned ticket may have).
  • a successful attack on the AS may have more severe consequences (e.g., independent of the type of chosen security technology).
  • a compromised AS may not have more rights than the domain keys gives and those keys it gets from the DMS periodically.
  • systems, instrumentalities, and/or methods may be provided for authorization and authentication (e.g., based on a public key) of end-user devices towards IoT units belonging to a domain such as a single administrative domain.
  • the systems, instrumentalities, and/or methods may allow or enable faster symmetric key based, temporary, authentication of resource constrained IoT units without, for example, a need to issue IoT unit specific credentials to connecting clients (e.g., the clients can use the same credentials to access each of IoT units within the domain). This may be useful when granting temporary access to an IoT domain.
  • the example systems, instrumentalities, and/or methods may provide a standards based efficient system for the issuing and verification of such credentials using public key cryptography. Further, in examples, the systems,
  • instrumentalities, and/or methods described herein may issue short-lived keys to an authorization server and the IoT devices and may then provide access tickets associated with the short-lived keys to the visiting client where the tickets may be authenticated by the IoT devices upon connection of the client.
  • UMA User-Managed Access
  • IETF may provide User-Managed Access (UMA) profile of OAuth that may apply an authorization model as shown in FIG. 20 that may be similar to the example described above (e.g., for DCAF).
  • Example principles that may be used with or associated with the UMA profile of OAuth may include one or more of the following.
  • the resource owner may delegate on an Authorization Server (AS) the right for end- user client to manage the authorization to his/her IoT resources. This may be done by issuing authentication/authorization polices to the AS using a control interface.
  • AS Authorization Server
  • An owner may use the OAuth framework to configure his/her resources with access credentials to securely access an authorization server and through this interface may share credential necessary for verifying access tokens issued by the AS in the system.
  • a client that wants to access a protected resource e.g., an IoT resource
  • the client may use the authorization data retrieved (e.g., as described above) to get or receive secure (temporary) access to the requested resource.
  • the model shown in FIG. 20 may have one or more of the following limitations.
  • the resource server may be from a security perspective dependent on the protection API provided by the AS. In such an example, the resource owner may not want to outsource this capability to an external party. Instead, the resource owner may decide to keep the full security control in house and thus may use infrastructure within the house. Additionally, the model shown in Fig. 20 may use one or more (e.g., each) of the resources to support the protection API provided by the AS and that may involve special customizations of the IoT units.
  • SAML Security Assertion Markup Language
  • the standard that may be used may be an XML based standard for exchanging authorization and authentication data between peers.
  • the standard in examples may be used to provide Single Sign On for Web applications as depicted FIG. 21.
  • SAML and/or the use thereof may be flexible with respect to how assertions may be used and what to "assert.” This may include, for example, key material and/or the like.
  • the usage of SAML as shown in FIG. 21 may be characterized by using two simultaneous SSL/TLS connections for authentication of the client.
  • the client may have an online connection at each authentication occasion at the service provider.
  • a limitation with the SAML model may be that the client authentication of the service provider may be the standard SSL/TLS server certificate based authentication, which may be based on pre-installed trusted root CA (in the client). As such, it may provide the clients little protection from false service providers. Such a model may also not work in off-line authentication scenarios.
  • a number of IoT units within an administrative domain may have in examples a common need to efficiently authenticate an end-user device such as computer, smart phone, vehicle, watch, NFC ring, and/or the like (e.g., 214a-b) that may have temporary access to a IoT resource (e.g., 202a-h) within the domain (e.g., A-C).
  • an end-user device such as computer, smart phone, vehicle, watch, NFC ring, and/or the like
  • IoT resource e.g., 202a-h
  • A-C e.g., A-C
  • AS Authorization Server
  • the AS may be hosted within or outside the subject IoT domain without compromising the long term security of the system.
  • the system may include resource constrained IoT units.
  • the security framework and protocols described herein may provide authorization and authentication to a complete IoT domain that may include a number of heterogonous IoT units (e.g., rather than just for single entities that connect to single IoT peers).
  • a user friendly and efficient mechanism may be provided for an end-user to request a single or a few authorization ticket(s) for the access to the whole IoT domain over a limited time period.
  • the examples herein address such a problem and may suggest such security principles and protocols based on public key techniques and/or the use of public key materials.
  • FIG. 22 illustrates an example 2200 for granting temporary access to an end user device (214a-b) to an IoT resource (e.g., 202a-h of FIG. 1 or 202e-h of FIG. 7).
  • the flow 2200 may be based on a set of standard public key and/or internet security protocols that may be combined such that the security requirements of the particular IoT examples described herein may be fulfilled.
  • the AS 207 may be provided outside the resource domain (e.g., which may be controlled by a DMS such as 202a-c in FIG. 1 for domains A-C respectively).
  • the following example 2200 may be used for granting external clients secure access to an IoT infrastructure through an AS (e.g., 207) such as a third party AS.
  • the DMS may perform one or more of the following.
  • the DMS may have a pre-configured long-term security relationship with the IoT units within the resource domain in the form of signed IoT unit public key credentials (e.g., IoT unit certificates that may be used by the DMS).
  • the examples herein may not be limited to a particular way for establishing these security relations or security credentials or certification but may, for example, be created and maintained via secure IoT unit enrollment where the IoT units get the credentials that may be used to set-up secure connections with the DMS.
  • One such example may be described in PCT Application No. PCT/US2015/050714, filed September 17, 2015, the disclosure of which is incorporated by reference herein in its entirety.
  • the DMS may delegate to an AS such as a third party AS (e.g., 207) the right to issue access ticket or access assertion to the DMS domain. This may be done by issuing (e.g., with regularity) time limited certificates to the AS that may be signed by the DMS together with the public key root certificate of the DMS sent to the AS over a secure channel.
  • the time limit of the AS certificate may be set to the time that the DMS allows the AS to issue access grant tickets on DMS' behalf to the DMS domain.
  • the DMS may send the AS the access policies that may apply for the DMS domain.
  • the access policies may be used by the AS when clients subsequently request access to the DMS controlled IoT domain through the AS.
  • An example 2200 for requesting access (e.g., from the end-user client side) to an IoT resource domain is described herein.
  • An end user may want to get temporary access to services provided by IoT units within a particular IoT resource domain.
  • the user may receive or get knowledge of an availability of such a domain through a service advertisement, through a direct interaction with the owner of the service domain, and/or through any other suitable techniques.
  • the user e.g., the end-user client
  • an end-user may use the end-user client or device 214a-b to contact the responsible AS 207 and request access to the subject IoT resource domain (e.g., A).
  • This request may be done over a secure channel such as SSL/TLS or DTLS.
  • the request may be authenticated with the client public key credentials where the client public key may be sent, for example, in the client hello message in accordance with these standards.
  • This request may include information (e.g., detailed information) that may include what type of services within the domain the user may be interested to obtain access for as well as the requested time period for such access.
  • the end-user client may send information regarding the IoT resource
  • the end-use client may want to access and an access request time during which the IoT resource may be used or access may be desired.
  • the AS 207 may examine or evaluate the access request (e.g., may determine whether the request may have the necessary information) and may request additional information from the end-user connected to the requested service such as payment information, end-user authentication information, and/or the like. Furthermore, the AS 207 may determine whether the requested IoT resources (e.g., or services) in the domain may be available or not for the requested period and/or if the access policy the AS may have received from the DMS may actually allow such access.
  • IoT resources e.g., or services
  • the AS 207 may generate and/or issue a client IoT grant ticket that may include one or more the following parameters over the secure channel: an assertion describing the access rights of the requesting clients bind to the public key certificate of the requesting client and signed by the AS private key (e.g., this may not be restricted to any particular format but it could for instance be a SAML or CBOR), the AS time limited certificates provided by the DMS, the DMS root public key, and/or the like
  • the AS 207 may return or send the requested access ticket(s) to the end-user client 214a-b.
  • the AS 207 may send the ticket(s) to the end-user client 214a-b.
  • the end-user client 214a-b may use an access ticket (e.g., the currently valid access ticket) to request secure access to an IoT unit 202e-h (e.g., an arbitrary IoT) within the resource domain.
  • an access ticket e.g., the currently valid access ticket
  • the request may be authorized/ authenticated based on the access ticket the end-user devices may have received from the AS 207 at 2.
  • the client may present the IoT domain access ticket to one or more IoT devices associated with the
  • the access (e.g., granted as part of 3) may be done over a secure channel such as SSL/TLS or DTLS where the IoT unit public key certificate may be used for the server authentication and the client certificate for the client authentication.
  • the client may provide the IoT unit with the assertion as well as the AS time limited certificate which both may be evaluated for time and access validity before the IoT unit may grant the client the requested access.
  • the assertion may be part of the access ticket that may be used to determine the exact rights of the user, e.g., what type of IoT resources the user has rights to access and the time period for which those rights may be valid.
  • the client may use the DMS root certificate to verify the validity of the IoT unit certificate.
  • the examples herein may enable or allow an end- user client, through an authorization request (e.g., a single authorization request), to get one or more ticket(s) that may enable or allow the client to get authorization for access and authenticate itself to a set of IoT units at a specific resource domain (e.g., including resource constrained IoT units over remote or local interfaces towards the IoT units within the domain).
  • the client credentials may not be specific to a certain IoT resource, but may be valid for each of the resources at the specific domain.
  • the temporary domain credentials may be used for mutual authentication towards the service or resources or units. Public keys may be used for the authentication and authorization.
  • the examples herein may enable or allows the resource domain owner to delegate ticket issuing to a third party, e.g., the AS, that may not need to be fully trusted.
  • a third party e.g., the AS
  • relatively short lived credentials may be shared with the AS.
  • the IoT resource owner may stop issuing short lived domain credentials to the old AS and the old AS may not have an access right to the IoT resource domain once a certain time period may elapse.
  • IoT unit identity details for the IoT domain may be hidden to the temporary user or the end-user device, thus giving enhanced privacy.
  • the domain based IoT authentication described herein may be performed over a local interface between the end-user client and an IoT resource (e.g., each IoT resource) within the resource domain in real-time without a connection between the IoT unit and a central system. This may provide faster and more robust authentication even if the IoT unit may have limited network connectivity and may save power for the IoT unit (e.g., which may be a battery driven device).
  • the systems, instrumentalities, and/or methods here may include IoT unit credential provisioning, DMS to AS credential provisioning, client to AS access request, and/or client to IoT unit access request and connection in one or more examples.
  • an IoT unit may be denoted by u
  • an end-user client may be denoted by c
  • an IoT resource domain may be by d
  • a set of IoT units in domain d may be denoted by Ud.
  • a public and private key pair of a unit u may be denoted by (Pr H ,Pk H , a certificate issued by the DMS certifying Pk H may be denoted by Certu
  • a public and private (root) key pair of the DMS may be denoted by ⁇ ?rDMS,V oMS)
  • a DMS root certificate may be denoted by CertDMS
  • a public and private key pair of an AS may be denoted by ⁇ ?us,V AS)
  • the time limited access certificate for d issued by the DMS certifying access ticket issuing rights for ⁇ kAS may be denoted by Cert(f)AS
  • Cert(f)AS the time limited access certificate for d issued
  • IoT unit credential provisioning may be provided and/or used in the systems, instrumentalities, and/or methods herein.
  • the systems, instrumentalities, and/or methods herein may provide ability for the IoT units to efficiently verify end-user client authorizations and to authenticate the connecting unit.
  • each u E U d may be equipped with a unique private public key pair, (Pr H ,Pk H ;.
  • the public key of each unit may be certified by the DMS in the form of a public key certificate, Certu, such as X.509.
  • the DMS may certify one or more units (e.g., each unit) in the whole domain, which may be a complex procedure.
  • one or more (e.g., each) u E U d may store (e.g., securely store) a reference to the public key, PkoMS, or public key certificate, CertDMS, of the DMS of the domain.
  • provisioning of these credentials may be a problem to IoT units.
  • a user friendly, secure, low complexity procedure for IoT unit credential provisioning may be provided herein.
  • IoT unit unique keys and certificates may be issued and/or used together with the IoT unit credential provisioning procedure.
  • DMS to AS credential provisioning may be provided and/or used.
  • the DMS may choose to delegate authorization decision rights to the AS for limited time periods. Depending on the security requirements and the amount of trust the DMS put in the AS, the DMS may use different strategies for this authorization that may be delegated. According to the examples herein, the DMS may request the public key credentials of the AS (including Pl s, ID, ULR, and/or the like) and may issue
  • the DMS may give or send or provide over a secure channel DMS root certificate, CertDMS (e.g., during first or just after certificate transfer in the sequence).
  • the DMS may inform the AS of the secure access policies that may apply to the domain and what type of assertions the AS may be able to issue on behalf of the DMS.
  • a client to AS access request may be provided and/or used in one or more examples.
  • a client may request access using an AS (e.g., for end-user client credential provisioning).
  • AS e.g., for end-user client credential provisioning
  • Any suitable mechanism may be used for the end-user client to determine or find out the address of the devices in the requested resource domain as well as the address of the AS serving the domain.
  • Service Authorization Manager direct principle may be used when trying to access the resource (e.g., in accordance with DCAF). Other suitable ways described herein may be used.
  • any suitable mechanism may be used for the AS to determine if it should allow issuing of an authorization ticket to the end-user client or not.
  • the example shown in FIG. 22 may include one or more of the following.
  • the end user client may issue or send an "access request" message towards the AS over an authenticated and secure channel such as TLS or DTLS.
  • the channel may be mutually authenticated with the keys in Certc and by the AS server certificate (e.g., the AS may possess a general server certificate that can be used for protecting client access requests).
  • This message may include one or more of the following parameters: a unique identifier of the resource domain that the client wants to access, specification on the actions that the client wants to perform on the devices in this domain, UTC time parameters specifying the time period for which the end-user client requests the access to the requested resources in, th, t2 c , e.g., from th until t2 c , and/or the like.
  • the AS may evaluate the access request (e.g., as described herein) and if the client is authorized to access the requested domain and actions. In an example, the AS may perform the following. The AS may evaluate or determine the ticket start, th, and end times, th, for the request access period. The AS may evaludate the requested access rights against the general access policy that may apply in the subject domain, d.
  • the AS may fetch and/or receive from the TLS or DTLS layer the client public key/certificate information, Certc.
  • the AS may use this information to issue a new client access ticket that may include the following information: an assertion in a suitable format such as SAML, JSON, and/or CBOR including at least the following signed with the key PTAS: client subj ect public key or certificate reference such as a secure one-way hash of the key or certificate, the access time period, tl c , t2 c , the precise IoT resource rights expressed in a format compatible with the chosen assertion format; Cert( ⁇ s; and/or Certo S.
  • a suitable format such as SAML, JSON, and/or CBOR
  • client subj ect public key or certificate reference such as a secure one-way hash of the key or certificate, the access time period, tl c , t2 c , the precise IoT resource rights expressed in a format compatible with the chosen assertion format
  • Cert( ⁇ s and/or Certo S.
  • Client to IoT unit access request and connection may be provided and/or used. The following may be performed as part of the client to IoT access request and connection at 3 in FIG. 22.
  • the client resource may perform the following.
  • the client may set up a secure mutual authenticated SSL/TLS or DTLS session with u using the certificate Certc and Certu respectively.
  • the client may mark the DMS root key, CertDMS, as a trusted root key.
  • c may provide u with the access ticket information described herein (e.g., above).
  • the information may be transmitted to u in one or more of the following.
  • the access ticket information that may be sent may be embedded in the TLS or DTLS handshake for instance using the TLS supplemental data extensions as shown by example 2300 in FIG. 23.
  • the access ticket information that may be sent may be a special ticket transfer message directly after the secure channel establishment as shown by example 2400 in FIG. 24.
  • the unit u may perform the following checks (e.g., as shown in example 2500 in FIG. 25).
  • the unit u may extract the time parameters described herein and may check the expiry time and signature of
  • the time check may provide that one or more (e.g., each) of the IoT units have access to trusted global clock source.
  • the trusted clock values may be provided to u using any suitable mechanism and/or technique.
  • the unit u may check (e.g., at b) the assertion signature against the public key in Cert ⁇ s. In an example, such a check may be made if the current time may be less than the expiry time and the signature of CertC ⁇ s may be valid.
  • the unit u may check (e.g., at c) the assertion validity time, tl c , t2 Ci against its internal global clock value to make sure the ticket may still be valid.
  • the unit u may check the resources that c should have access to according to the assertion and/or policy (e.g., at di).I If those apply to the unit u, these resources may be made available to c over the secure connection (e.g., at dii).
  • FIG. 13 an example of a system 1400 is illustrated in which one or more examples described herein may be used and/or implemented.
  • the system
  • the 1400 may include remote and direct control of an IoT infrastructure (e.g., of a property including a property for rental on daily, weekly or monthly basis).
  • the IoT infrastructure may include, for example, remote/internet control of heating and temperature sensing, remote/internet control of network video surveillance equipment, IoT based control of entrance gate, garage and house door locks, profiling and smart phone based wireless control of in house entertainment system, building control system, and/or the like.
  • the examples herein may assist an end-user and property owner to offer the end-user the desired temporary access to an IoT infrastructure at the property without compromising the long-term security of the system 1400.
  • the property owner may have outsourced to a third party service provider the online contract signing for the property rental and/or the authorization/access control of the IoT infrastructure of the property (e.g., the third party provider may run the AS function according to the examples described herein).
  • an end-user e.g., 213a-b
  • may be looking online e.g., via a client 214a-b
  • a property to rent for one week.
  • the end-user may agree and sign online a contract, and may pay a party for the rental service for the desired property and time- period.
  • the contract may receive from the serving AS all or a subset of the following information that may be downloaded, e.g., via a secure channel authenticated with the client certificate, Certc, to his client device (e.g., a mobile unit such as 214a-b) as described herein.
  • the client device may receive (e.g., as part of the downloaded information) the certificate of the AS, Cert ⁇ s, with expiry time t, certifying that the AS is allowed to issue assertion to the property domain until time t, the property domain root certificate, CertDMS, and an assertion from the AS signed with the private key of the AS.
  • the assertion may certify one or more of the following rights to the end-user holding Certc including, for example, validity from three hours before the rental period starts, ti ' until the end of the rental period, t2 in a suitable format such as UTC, rights to access the domain property indoor and outdoor video cameras covering the property inside and outside, rights to access temperature sensors and heating control in the property from time ti until time t2, rights to access electronic gates and doors on the property, and/or rights to access in house entertainment system and building control system from the start of the rental period, ti until the end of the rental period, t2.
  • the end user via his device 214a-b) may receive or get the URLs to the video and temperature units in the property.
  • the end-user may use his client device (e.g., a mobile unit such as 214a-b) and the URLs received at 1 to access the video cameras mounted in the property.
  • the video cameras may use DTLS protected authentication and secure channel for access, for example.
  • the end-user device may use his client certificate to authenticate the client device (e.g., 214a-b) towards the video camera (e.g., IoT resource or 202a-h), for example, using DTLS client authentication.
  • the end-user device may send the certificate and assertion information (e.g., at 1) in the client hello extension field as described herein.
  • the video camera may evaluate the assertions according to the procedure shown in FIG. 25 and may grant the mobile access to the video camera.
  • the end-user may want to check the temperature in the different rooms of the property (e.g., by directly connecting to temperature sensors (e.g., IoT resources 202a-h) inside the property).
  • the end-user may adjust temperature by connecting to heating control units inside the house.
  • These connections may be DTLS protected and authentication may be performed using the client and IoT unit certificates. Access may be checked using the AS and DMS certificate information together with the assertion information transferred in the client hello.
  • the end-user may arrive by car to the entrance gate of the rented property.
  • the end-user may then use his client device (e.g., a mobile device such as 214a-b) to request gate opening over a short-range wireless protocol such as Bluetooth.
  • the electronic gate may use
  • the end-user device may use the client certificate to authenticate the device towards the access gate using DTLS client authentication.
  • the end-user device may send the certificate and assertion information (from 1) in the client hello extension field as described herein.
  • the gate may be (e.g., automatically) opened. In such an example, public key calculations may be performed at the gate and/or at the client device before the access may be authenticated and allowed or accepted.
  • the user may arrive at the rented house at the property.
  • the end-user may use the example described with respect to the entrance gate to open the door of the house. Once inside the house, the end-user may want to play his favorite HiFi music using his mobile device
  • the end-user device may find the entertainment system on the local
  • WLAN that may be connected to an open network. This may be done using a suitable discovery protocol and setting up a secure TLS session with the controlling unit using the client certificate to authenticate the mobile device towards the entertainment system.
  • the end-user device may send the certificate and assertion information (e.g., at 1) in the client hello extension field as described herein. The end-user may be allowed to control the
  • the examples herein may provide secure temporary IoT domain access using public key mechanisms. Such public key based mechanisms may protect the security of other IoT units in the domain if a single IoT unit is compromised. The impact from a compromised AS may be more significant (e.g., the system may be compromised). In examples herein, the AS may get temporary rights to issue assertions on the DMS behalf such that an AS compromise may have limited effects on the security of the system.
  • the AS may be run by a larger organization (e.g., one with lots of resources for providing a very high level of security). The public key based examples may leave more processing to IoT units and client devices (e.g., thus may slow down authentication).
  • public keys may be revoked (e.g., if public key credentials have been compromised). This may be challenging to achieve in PKI based systems.
  • time limited rights may be given to the AS to enable revocation of CertC ⁇ s .
  • the assertions issued by the AS may have a short life span or be short lived. As such, client revocation may not be an issue for the DMS system described herein.
  • the AS may have ways to authenticate and verify requesting clients and/or to distinguish between trusted and non-trusted or compromised clients.
  • the IoT units themselves may have public key capabilities. As such, a compromised IoT unit may not be part of the IoT domain and may be excluded from the system.
  • the revocation of the IoT unit credentials may be provided.
  • the IoT unit may be addressed or performed as follows.
  • the owner of the domain notices that an IoT unit has been stolen or otherwise have reasons to suspect that a particular IoT unit is
  • the DMS may change root key and issues new certificates to all non-compromised IoT units in the system.
  • the DMS may assign relatively short lived certificates to the IoT units within the domain. As such, when the keys are about to be renewed, detected compromised or stolen units may be excluded from the key update.
  • a revocation scheme such as Online Certificate Status Protocol (OCSP) may be used.
  • OCSP Online Certificate Status Protocol
  • FIG. 26A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • the communications systems 100 may also include a base station 114a and a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the
  • the base stations 114a and/or 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode
  • BTS base transceiver station
  • eNode B eNode B
  • Home Node B eNode B
  • Home eNode eNode
  • B a site controller, an access point (AP), a wireless router, and the like. While the base stations
  • 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • the base stations 114a and/or 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, and/or 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • HSPA High-Speed Packet Access
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
  • E- UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 26A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
  • a cellular- based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.
  • the RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d.
  • the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • VoIP voice over internet protocol
  • the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT.
  • the core network in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network
  • 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and/or 102d to access the PSTN 108, the Internet 110, and/or other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired or wireless
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • the WTRU 102c shown in FIG. 26A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. 26B depicts a system diagram of an example WTRU 102.
  • the WTRU 102 may be an IoT unit, a DMS, an authorization server, and/or end-client device as described herein and/or the IoT unit, DMS, authorization server, and/or end-client device may include one or more of the components of the WTRU 102. As shown in FIG.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • GPS global positioning system
  • the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 26B and described herein.
  • BTS transceiver station
  • Node-B a Node-B
  • AP access point
  • eNodeB evolved home node-B
  • HeNB home evolved node-B gateway
  • proxy nodes among others, may include some or all of the elements depicted in FIG. 26B and described herein.
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,
  • DSP digital signal processor
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the
  • FIG. 26B depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player
  • FIG. 26C depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 115.
  • the RAN 103 may also be in communication with the core network 106.
  • the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 115.
  • the Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • the RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
  • the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the
  • the Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface.
  • the RNCs 142a, 142b may be in communication with one another via an Iur interface.
  • Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, and/or 140c to which it is connected.
  • each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 26C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC mobile switching center
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • the RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface.
  • the MSC 146 may be connected to the MGW 144.
  • the MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.
  • the RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface.
  • the SGSN 148 may be connected to the GGSN 150.
  • the SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.
  • packet-switched networks such as the Internet 110
  • the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. 26D depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 116.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 26D, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. 26D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management gateway
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via an SI interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the
  • the MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the SI interface.
  • the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c.
  • the serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.
  • the serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.
  • the PDN gateway 166 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.
  • the core network 107 may facilitate communications with other networks.
  • the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.
  • the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108.
  • the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • IMS IP multimedia subsystem
  • FIG. 26E depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment.
  • the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 117.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points.
  • the RAN 105 may include base stations 180a, 180b, and/or
  • the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117.
  • the base stations 180a, 180b, and/or 180c may implement MIMO technology.
  • the base station 180a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like.
  • the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
  • the air interface 117 between the WTRUs 102a, 102b, and/or 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification.
  • each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109.
  • the logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.
  • the communication link between each of the base stations 180a, 180b, and/or 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations.
  • the communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway 182 may be defined as an R6 reference point.
  • the R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and/or 102c.
  • the RAN 105 may be connected to the core network 109.
  • the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.
  • the core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MIP-HA mobile IP home agent
  • AAA authentication, authorization, accounting
  • the MIP-HA may be responsible for IP address management, and may enable the
  • the MIP-HA 184 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the
  • the AAA server 186 may be responsible for user authentication and for supporting user services.
  • the gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
  • the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs.
  • R5 reference may include protocols for facilitating interworking between home core networks and visited core networks.
  • Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention permet de fournir un accès à des ressources Internet des objets (IoT) dans un domaine IoT. Par exemple, un serveur d'autorisation (AS) peut recevoir, en provenance d'un serveur de gestion de dispositif (DMS), des premiers justificatifs d'identité associés à un domaine IoT et une première période temporelle d'autorisation. L'AS peut également recevoir, en provenance d'un dispositif client, une demande d'accès aux ressources IoT dans le domaine IoT, la demande comprenant des informations concernant les ressources IoT demandées dans le domaine IoT et une première période temporelle de demande d'accès durant laquelle les ressources IoT peuvent être utilisées. L'AS peut envoyer (par exemple, directement), au client, un ticket d'accès au domaine IoT. Dans un exemple, le ticket d'accès au domaine IoT peut être généré sur la base des premiers justificatifs d'identité associés au domaine IoT reçus en provenance du DMS et de la première période temporelle d'autorisation. La première période temporelle d'autorisation et la première période temporelle de demande d'accès reçues en provenance du client peuvent se chevaucher.
PCT/US2016/050150 2015-09-25 2016-09-02 Authentification et autorisation de domaine basé sur l'iot WO2017053048A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201562232841P 2015-09-25 2015-09-25
US62/232,841 2015-09-25
US201562255836P 2015-11-16 2015-11-16
US62/255,836 2015-11-16
US201562268465P 2015-12-16 2015-12-16
US62/268,465 2015-12-16

Publications (1)

Publication Number Publication Date
WO2017053048A1 true WO2017053048A1 (fr) 2017-03-30

Family

ID=56943949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/050150 WO2017053048A1 (fr) 2015-09-25 2016-09-02 Authentification et autorisation de domaine basé sur l'iot

Country Status (1)

Country Link
WO (1) WO2017053048A1 (fr)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107483495A (zh) * 2017-09-21 2017-12-15 浪潮软件股份有限公司 一种大数据集群主机管理方法、管理系统及服务端
WO2018194368A1 (fr) 2017-04-18 2018-10-25 Samsung Electronics Co., Ltd. Procédé et appareil de contrôle d'accès dans un réseau de l'internet des objets (ido) basé sur une chaîne de blocs distribuée
US20190239043A1 (en) * 2018-02-01 2019-08-01 Nokia Technologies Oy Device provisioning
US10581872B1 (en) * 2016-12-29 2020-03-03 Alarm.Com Incorporated Service authorization for IoT devices operating locally
WO2020058559A1 (fr) * 2018-09-17 2020-03-26 Nokia Solutions And Networks Oy Gestion de justificatifs d'identité
US20200396613A1 (en) * 2019-04-29 2020-12-17 Sonicwall Inc. Securing transmission paths in a mesh network
US11025627B2 (en) * 2017-07-10 2021-06-01 Intel Corporation Scalable and secure resource isolation and sharing for IoT networks
CN114050932A (zh) * 2021-11-10 2022-02-15 安徽健坤通信股份有限公司 分布式系统的网络安全验证方法和系统
WO2023273458A1 (fr) * 2021-06-30 2023-01-05 华为技术有限公司 Procédé et appareil de commande de dispositif
US11563542B2 (en) 2017-03-23 2023-01-24 Samsung Electronics Co., Ltd. Apparatus and method for performing initial access in wireless communication system
US20230055966A1 (en) * 2021-08-17 2023-02-23 Jastecm Co., Ltd. Indoor and outdoor seamless positioning device for data safety and data reliability
US11638149B2 (en) 2019-04-29 2023-04-25 Sonicwall Inc. Instant secure wireless network setup
CN116155633A (zh) * 2023-04-23 2023-05-23 农数源(成都)科技有限公司 一种传感器外置数据安全保护与双向鉴别方法、系统、装置
US11695568B1 (en) 2019-10-01 2023-07-04 Equinix, Inc. Virtualized network functions verification using decentralized identifiers
US11777932B1 (en) * 2019-11-22 2023-10-03 Equinix, Inc. Controlling access to internet of things devices using verifiable credentials
US11997635B2 (en) 2019-04-29 2024-05-28 Sonicwall Inc. Establishing simultaneous mesh node connections
US12022295B2 (en) 2019-05-06 2024-06-25 Sonicwall Inc. Streamlined creation and expansion of a wireless mesh network

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150271296A1 (en) * 2012-10-12 2015-09-24 Citrix Systems, Inc. Enterprise Application Store for an Orchestration Framework for Connected Devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150271296A1 (en) * 2012-10-12 2015-09-24 Citrix Systems, Inc. Enterprise Application Store for an Orchestration Framework for Connected Devices

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JEAN-YVES MIGEON: "The MIT Kerberos Administrator's How-to Guide. Protocol, Installation and Single Sign On", INTERNET CITATION, 23 July 2008 (2008-07-23), pages 1 - 62, XP002712247, Retrieved from the Internet <URL:http://www.kerberos.org/software/adminkerberos.pdf> [retrieved on 20130904] *
THOMAS HARDJONO: "Kerberos for Internet-of-Things Contents", IETF89, 25 February 2014 (2014-02-25), pages 1 - 25, XP055326649 *

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11184366B1 (en) 2016-12-29 2021-11-23 Alarm.Com Incorporated Service authorization for IoT devices operating locally
US10581872B1 (en) * 2016-12-29 2020-03-03 Alarm.Com Incorporated Service authorization for IoT devices operating locally
US11563542B2 (en) 2017-03-23 2023-01-24 Samsung Electronics Co., Ltd. Apparatus and method for performing initial access in wireless communication system
WO2018194368A1 (fr) 2017-04-18 2018-10-25 Samsung Electronics Co., Ltd. Procédé et appareil de contrôle d'accès dans un réseau de l'internet des objets (ido) basé sur une chaîne de blocs distribuée
EP3596880A4 (fr) * 2017-04-18 2020-03-04 Samsung Electronics Co., Ltd. Procédé et appareil de contrôle d'accès dans un réseau de l'internet des objets (ido) basé sur une chaîne de blocs distribuée
US10749677B2 (en) 2017-04-18 2020-08-18 Samsung Electronics Co., Ltd. Method and apparatus for access control in distributed blockchain-based internet of things (IoT) network
US11025627B2 (en) * 2017-07-10 2021-06-01 Intel Corporation Scalable and secure resource isolation and sharing for IoT networks
CN107483495A (zh) * 2017-09-21 2017-12-15 浪潮软件股份有限公司 一种大数据集群主机管理方法、管理系统及服务端
EP3522478A1 (fr) * 2018-02-01 2019-08-07 Nokia Technologies Oy Approvisionnement de dispositifs
US10945107B2 (en) 2018-02-01 2021-03-09 Nokia Technologies Oy Device provisioning for association with a user or a user account
US11902868B2 (en) 2018-02-01 2024-02-13 Nokia Technologies Oy Device provisioning for association with a user or a user account
US20210168575A1 (en) * 2018-02-01 2021-06-03 Nokia Technologies Oy Device provisioning for association with a user or a user account
US20190239043A1 (en) * 2018-02-01 2019-08-01 Nokia Technologies Oy Device provisioning
WO2020058559A1 (fr) * 2018-09-17 2020-03-26 Nokia Solutions And Networks Oy Gestion de justificatifs d'identité
US20220030431A1 (en) * 2018-09-17 2022-01-27 Nokia Solutions And Networks Oy Credentials management
US11638149B2 (en) 2019-04-29 2023-04-25 Sonicwall Inc. Instant secure wireless network setup
US20200396613A1 (en) * 2019-04-29 2020-12-17 Sonicwall Inc. Securing transmission paths in a mesh network
US11997635B2 (en) 2019-04-29 2024-05-28 Sonicwall Inc. Establishing simultaneous mesh node connections
US12022295B2 (en) 2019-05-06 2024-06-25 Sonicwall Inc. Streamlined creation and expansion of a wireless mesh network
US11695568B1 (en) 2019-10-01 2023-07-04 Equinix, Inc. Virtualized network functions verification using decentralized identifiers
US11777932B1 (en) * 2019-11-22 2023-10-03 Equinix, Inc. Controlling access to internet of things devices using verifiable credentials
WO2023273458A1 (fr) * 2021-06-30 2023-01-05 华为技术有限公司 Procédé et appareil de commande de dispositif
US20230055966A1 (en) * 2021-08-17 2023-02-23 Jastecm Co., Ltd. Indoor and outdoor seamless positioning device for data safety and data reliability
CN114050932A (zh) * 2021-11-10 2022-02-15 安徽健坤通信股份有限公司 分布式系统的网络安全验证方法和系统
CN116155633A (zh) * 2023-04-23 2023-05-23 农数源(成都)科技有限公司 一种传感器外置数据安全保护与双向鉴别方法、系统、装置

Similar Documents

Publication Publication Date Title
WO2017053048A1 (fr) Authentification et autorisation de domaine basé sur l&#39;iot
Zhang et al. Towards secure 5G networks: A Survey
US20240064144A1 (en) Security lifecycle management of devices in a communications network
EP3286871B1 (fr) Systèmes, procédés et dispositifs pour la protection de justificatifs d&#39;identité de dispositifs
JP6595631B2 (ja) サービス層におけるコンテンツセキュリティ
JP5390619B2 (ja) Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル
Jan et al. Design and analysis of lightweight authentication protocol for securing IoD
Sathyadevan et al. Protean authentication scheme–a time-bound dynamic keygen authentication technique for iot edge nodes in outdoor deployments
TWI558253B (zh) 進行用戶認證的計算機執行方法及使用用戶識別碼得到存取目標域處服務的方法
TWI514896B (zh) 可信賴聯合身份方法及裝置
US10992472B2 (en) Systems and methods for secure roll-over of device ownership
US20170295491A1 (en) Systems and methods for secure device provisioning
US20170366342A1 (en) Protecting the Integrity of Log Entries in a Distributed System
TW201417598A (zh) 安全性關聯特性
Kim et al. A toolkit for construction of authorization service infrastructure for the internet of things
US20080295144A1 (en) Network client validation of network management frames
EP3422630B1 (fr) Contrôle d&#39;accès à un dispositif de réseau à partir d&#39;un dispositif utilisateur
TW201230750A (en) Certificate validation and channel binding
WO2022062517A1 (fr) Procédé et système d&#39;authentification
Panwar et al. Smart home survey on security and privacy
Aragon et al. ACE of spades in the IoT security game: A flexible IPsec security profile for access control
Wang et al. XAuth: Secure and privacy-preserving cross-domain handover authentication for 5G HetNets
TW201225697A (en) Identity management on a wireless device
Kim et al. Advanced Secure DNS Name Autoconfiguration with Authentication for Enterprise IoT Network
US20190068573A1 (en) Detection of the network logon protocol used in pass-through authentication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16767096

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16767096

Country of ref document: EP

Kind code of ref document: A1