Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Applicant asserts the prior art of record does not teach establishment of an encrypted layer 2 end-to-end tunnel between the client device and one or more servers in the secure cloud environment using an IEEE 802.1X authentication process.
In response, The Examiner respectfully disagrees because the combination of references is relied upon to suggest an encrypted layer 2 (The Examiner construes this to be a necessary if not obvious limitation of implementing the EAP-FAST (Flexible Authentication via Secure Tunneling with a protected authentication credential) because one of ordinary skill in the art would know EAP-FAST creates an encrypted end-to-end tunnel (using TLS) to protect the inner authentication credentials from eavesdropping and man-in-the-middle attacks. The tunnel is established using a shared secret (PAC) or optionally a server certificate to secure the subsequent EAP method exchange, see Sharaga para 0035. In addition, one of ordinary skill in the art would know EAP-FAST (Flexible Authentication via Secure Tunneling) is inherently tied to Layer 2 network access control because the underlying Extensible Authentication Protocol (EAP) framework is designed to operate at the link layer to facilitate initial network access decisions before higher-layer protocols (like IP) are configured) end-to-end (reads on end-to-end authentication between peripheral device and cloud server, see Sharaga para 0035) tunnel (The Examiner construes this to be an obvious limitation of the prior art’s VPN/trusted or secure connection via RADIUS/Diameter secret/encryption key for trusted and secure communications/ EAP-FAST disclosure because these technologies at the least imply and in some cases require secure/encrypted tunneling, see Sharaga para 0023, 0028, 0031 and 0035) between the client device (reads on the TEE inside the client computing device, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) and one or more servers in the secure cloud (reads on the cloud server, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) environment using an IEEE 802.1X authentication process (reads on the combination of well-known EAP methods like EAP-TLS, EAP-AKA, and EAP-FAST commonly run over RADIUS/Diameter to provide authentication, and this entire framework implies or is foundational to IEEE 802.1X for network access control, see Sharaga para 0035 and a 802.1x authentication server, see Nijdam page 10 lines 21 – 31). As a result, the prior art of record indeed reads on this limitation.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sharaga (US Pub. No. 2016/0182499 A1) in view of Nijdam (WO 2007/107708 A2) in view of Sood (US Pub. No. 2007/0110245 A1).
Per claim 1, Sharaga (US Pub. No. 2016/0182499 A1) suggests a method comprising: implementing an Institute of Electrical and Electronics Engineers (IEEE) 802.1X (see Sharaga para 0023) authenticator proxy (reads on the authenticator is a middle entity that forwards messages between the supplicant and the authentication server, see Sharaga para 0046 and Figures 2 and 3) in a computer platform (reads on the peripheral/computing device combination, see Sharaga para 0040 and Figures 2 and 3) communicatively coupled to a switch (reads on the cloud server encompasses exemplary switches or any other suitable device/component/element or object operable to exchange information in a network environment, see Sharaga para 0027) or an access point (AP) in a local area network (LAN) or a wireless LAN (WLAN) (reads on a LAN, WLAN or any other appropriate architecture or system that facilitates communications in a network environment, see Sharaga para 0023);
employing (reads on the authenticator is a middle entity that forwards messages between the supplicant and the authentication server, see Sharaga para 0046 and Figures 2 and 3) the IEEE 802.1X authenticator proxy (reads on the authenticator of Sharaga Figures 2 and 3 that forwards messages between the supplicant and the authentication server, see Sharaga para 0046 and Figures 2 and 3) to proxy (reads on is a middle entity, see Sharaga para 0046) Extensible Authentication Protocol (EAP) messages (reads on EAP messages, see Sharaga para 0041, 0046 and 0056) communicated between (reads on forwards messages between the supplicant and the authentication server, see Sharaga para 0046 and Figures 2 and 3) a supplicant (reads on the supplicant of Sharaga Figures 2 and 3) on the computer platform (reads on the peripheral/computing device combination, see Sharaga para 0040 and Figures 2 and 3) and an authentication server (reads on the authentication server in cloud server of Sharaga para 0044 and Figures 2 and 3) in a secure cloud environment accessed via the switch or AP to establish an encrypted Layer 2 (L2) (The Examiner construes this to be a necessary if not obvious limitation of implementing the EAP-FAST (Flexible Authentication via Secure Tunneling with a protected authentication credential) because one of ordinary skill in the art would know EAP-FAST creates an encrypted end-to-end tunnel (using TLS) to protect the inner authentication credentials from eavesdropping and man-in-the-middle attacks. The tunnel is established using a shared secret (PAC) or optionally a server certificate to secure the subsequent EAP method exchange, see Sharaga para 0035. In addition, one of ordinary skill in the art would know EAP-FAST (Flexible Authentication via Secure Tunneling) is inherently tied to Layer 2 network access control because the underlying Extensible Authentication Protocol (EAP) framework is designed to operate at the link layer to facilitate initial network access decisions before higher-layer protocols (like IP) are configured) end-to-end (reads on end-to-end authentication between peripheral device and cloud server, see Sharaga para 0035) tunnel (The Examiner construes this to be an obvious limitation of the prior art’s VPN/trusted or secure connection via RADIUS/Diameter secret/encryption key for trusted and secure communications/ EAP-FAST disclosure because these technologies at the least imply and in some cases require secure/encrypted tunneling, see Sharaga para 0023, 0028, 0031 and 0035) between the computing platform (reads on the TEE inside the client computing device, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) and one or more servers in the secure cloud (reads on the cloud server, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) environment using an IEEE 802.1X authentication process (reads on the combination of well-known EAP methods like EAP-TLS, EAP-AKA, and EAP-FAST commonly run over RADIUS/Diameter to provide authentication, and this entire framework implies or is foundational to IEEE 802.1X for network access control, see Sharaga para 0035). The prior art of record is silent on explicitly stating an authenticator proxy coupled to an access point; and a supplicant in an operating system on the computing platform.
PNG
media_image1.png
880
1067
media_image1.png
Greyscale
PNG
media_image2.png
359
843
media_image2.png
Greyscale
[0040] Peripheral devices may be coupled with a computing device via a global, local or body area network (GAN, LAN or BAN) or any suitable combination thereof. For example, the sub-elements of server 130, computing device 150 and peripheral device 180 may communicate with each other via a global network (for example, the Internet), LAN or BAN, or any suitable combination thereof. Such communications may be wired, wireless or use any other means of transmission like electromagnetic (including light and infra-red), sound waves, skin conductivity, etc. By way of example, and not of limitation, external peripheral devices (e.g., keyboard 171, USB 172, display screen 173, mouse 174, video camera, microphone, other input devices, etc.) may use wired or wireless technologies (e.g., USB, WiFi, Bluetooth, etc.) to communicate with computing device 150. Internal peripheral devices (e.g., memory modules 175, network interface card 176, hard disk 177, etc.) may be included in a SoC or on circuit board of computing device 150.
[0041] Each peripheral device can be associated with a vendor that configures the peripheral device to enable authentication between the peripheral device and an associated cloud server. For example, the vendor may be a manufacturer who produces peripheral device 180 and configures peripheral device 180 with supplicant 181, credentials 186, and PMK register 187. Supplicant 181 may be configured with appropriate logic to request authentication to a TEE of a computing device to which the peripheral connects (e.g., via WiFi, Bluetooth, LAN, USB, etc.) and to perform an EAP method with authentication server 131 of cloud server 130. Memory 188 can be configured to maintain data needed to support the authentication, such as credentials 186, PMK register 187, etc.
[0044] Turning to FIG. 3, FIG. 3 illustrates logical entities included in at least one embodiment of an extensible authentication protocol (EAP) authentication framework according to the present disclosure. EAP is an authentication framework that is generally used for network communications and is defined in IETF RFC 3748, entitled “Extensible Authentication Protocol (EAP),” dated June 2004. In at least one embodiment, the logical entities of the EAP authentication framework include a supplicant 380, an authenticator 360, and an authentication server 330. Supplicant 380 resides in an end device that requests authentication (e.g., supplicant 181 in peripheral device 180). Authenticator 360 resides in the entity with whom the supplicant needs to establish trust by access and shared keys (e.g., authenticator 161 in TEE 160). Authentication server 330 has corresponding (the same or complementary) credentials with supplicant 380 and performs an authentication protocol, such as an EAP method. Authentication server 330 can be an authentication server in a cloud server (e.g., authentication server 131 in cloud server 130).
[0046] Supplicant 380 can initiate authentication with authentication server 330 as the authentication target. Authenticator 360 is a middle entity that forwards messages between the supplicant and authentication server. An EAP method 310 is a layer on top of the EAP framework and is the end-to-end (E2E) authentication method to verify Trust 1, represented at 301, between supplicant 380 and authentication server 330. EAP 312 and EAP 314 represent messages of EAP method 310 that are received and forwarded by authenticator 360 when authentication server 330 and supplicant 380 are performing EAP method 310. Any EAP method, using appropriate credentials for the particular method, may be used on the EAP framework of FIG. 3 including, for example, EAP-TLS (using X.509 certificates), EAP-AKA (using USIM), EAP-Fast (using PAC), etc.
[0056] Authenticator 161 acts as a middle entity to receive and forward messages between authentication server 131 and supplicant 181. Messages can be exchanged between authenticator 161 and authentication server 131 during the EAP method based on Radius or Diameter protocol, where the Radius/Diameter secret is based on the attestation exchange. Messages can be exchanged between authenticator 161 and supplicant 181 during the EAP method using a data link layer transport. During the EAP method, a master key can be created in both authentication server 131 and supplicant 181, according to the particular authentication scheme that is used (e.g., TLS). At 424, authentication server 131 sends a message to authenticator 161 that indicates the EAP method was a success. The message can include a pairwise master key (PMK), which can be a derivative of the master key in at least one embodiment. After the success message with the PMK is received, at 426, authenticator 161 sends a message to supplicant 181 that indicates the EAP method was a success.
[0076] FIG. 7 illustrates one possible example of a computing system 700 that is arranged in a point-to-point (PtP) configuration according to an embodiment. In particular, FIG. 7 shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. In at least one embodiment, cloud server 130 and/or computing device 150, shown and described herein, may be configured in the same or similar manner as exemplary computing system 700.
[0087] In certain example implementations, the functions outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an ASIC, digital signal processor (DSP) instructions, software (potentially inclusive of object code and source code) to be executed by one or more processors, or other similar machines, etc.), which may be inclusive of non-transitory machine readable storage media. Cloud server 130, computing device 150, and peripheral device 180 may include one or more processors (e.g., processors 139, 159, 189) that can execute logic or an algorithm to perform activities as discussed herein. A processor can execute any type of instructions associated with the data to achieve the operations detailed herein. In one example, the processors could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), an EPROM, an EEPROM) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof. Any of the potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term ‘processor.’
[0090] Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these example configurations and arrangements may be changed significantly without departing from the scope of the present disclosure. Additionally, although communication system 100 has been illustrated with reference to particular elements and operations that facilitate the trust establishment activities, these elements and operations may be replaced by any suitable architecture, protocols, and/or processes that achieve the intended functionality of the system for establishing trust.
Nijdam (WO 2007/107708 A2) suggests
implementing an Institute of Electrical and Electronics Engineers (IEEE) 802.1X authenticator proxy (reads on the device 103 implements an authenticator for device 101, see Nijdam Figure 2 and page 11 line 25 – page 12 line 2) in a computer platform (reads on device 103, see Nijdam Figure 2) communicatively coupled to (reads on the line between block 103 and 105 in Nijdam Figure 2) a switch or an access point (AP) in a local area network (LAN) or a wireless LAN (WLAN) (reads on device 105 of Nijdam Figure 2 which is an access point, see Nijdam page 11 line 25 – page 12 line 2).
PNG
media_image3.png
583
1089
media_image3.png
Greyscale
[page 11 lines 13 - 23]
In the following description of the present invention, two users using handheld devices (node A 101 and node B 103) would like to communicate wirelessly in ad- hoc mode to exchange data. Securing the communication channel between the two nodes is achieved using a trusted third party - authentication server 109. However, instead of all transmissions being directed through the fixed infrastructure (as in infrastructure mode), one of the devices communicates briefly with the fixed infrastructure (e.g. via access point 105) in order to obtain the symmetric keys required to encrypt the ad-hoc communications between the two devices (e.g. from authentication server 109 over internet 107). Once the keys are obtained, the two devices are able to communicate with each other directly (in ad-hoc mode) and do not need to be in range of a fixed WiFi infrastructure.
[page 11 line 25 – page 12 line 2]
The conventional 802.1 X framework for port-based network access control (as described in relation to figures 12a and 12b) is, however, no longer appropriate since there are now four entities: ad-hoc node A 101 , ad-hoc node B 103, access point 105 (authenticator) and authentication server 109. The present invention makes use of the 802.1 X framework in a novel and inventive way as shown in figure 2. One of the WiFi nodes (node B 103 in this example) acts as supplicant where it receives symmetric encryption keys from authentication server 109 via access point 105 (acting as authenticator). Additionally, node B 103 acts as a temporary authentication server and authenticator in order to authenticate node A 101 (acting as supplicant).
[page 12 line 4 - 12]It is assumed that no prior trust has been established between node A 101 and node B 103. However, it is assumed that node A 101 and node B 103 have independently established prior trust with authentication server 109. This is achieved by node A 101 pre-sharing a secret symmetric encryption key (A. S) with the authentication server 109 and node B 103 pre-sharing a different secret symmetric encryption key (B. S) with authentication server 109. For example, when node A 101 and node B 103 first register with a service provider for wireless internet access they set up a username and password for future use. The passwords would then comprise secrets A. S and B. S.
[page 12 line 25 – page 13 line 8]
Like in the conventional IEEE 802.1 X framework, the present invention is based on EAP. EAP is built around the challenge-response paradigm; there are four types of EAP message: EAP-request, EAP-response, EAP-success and EAP-failure. The EAP over LAN (EAPOL) protocol is used to encapsulate the EAP messages and carry them between supplicant and authenticator. The EAP methods described below make use of the Otway-Rees key establishment protocol (D. Otway & O. Rees, "Efficient and timely mutual authentication". Operating Systems Review, 21(1):8- 10, 1987). Referring now to figure 3, three port access entities (PAE) take part in this instance of EAP: a supplicant PAE 30, authenticator PAE 32 and an authentication server PAE 34. (A PAE is a logical entity that supports the IEEE 802.1 X protocol and that is associated with a port.) In this instance of EAP, the supplicant PAE 30 is located on node A 101 . It will be remembered that node B 103 acts as a temporary authentication server and authenticator in order to authenticate node A 101 . Hence, in this instance of EAP, the authenticator PAE 32 and authentication server PAE 34 are both located on node B 103.
[page 14 lines 17 - 23]
Referring to figure 4, three PAEs take part in this second instance of EAP: a supplicant PAE 40, authenticator PAE 42 and an authentication server PAE 44. Supplicant PAE 40 is now located on node B 103, authenticator PAE 42 is located on access point 105 and authentication server PAE 44 is located on authentication server 109. A secure connection is assumed to exist between authenticator PAE 42 and authentication server PAE 44. For example, this could be established by access point 105 using IP Security (IPsec).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the authenticator proxy teachings of the prior art of record by integrating the authenticator proxy coupled to an access point teaching of Nijdam to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Nijdam would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the ability to have an authenticator proxy communicatively coupled to an access point as taught by Nijdam (see Nijdam Figure 2 and page 11 line 25 – page 12 line 2) to the conventional authenticator proxy coupled to any suitable device/component/element or object operable to exchange information in a network environment (see Sharaga para 0027) teachings of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such network element features into similar systems, resulting in an improved system that uses all available known in the art techniques to provide restricted access to network elements. The motivation to combine the references is applied to all claims below this heading.
Sood (US Pub. No. 2007/0110245 A1) is relied upon to teach a supplicant in an operating system on the computing platform (reads on host OS may include 802.1X supplicant, see Sood para 0025).
[0025] As illustrated in FIG. 4, in order to facilitate embodiments of the invention, Host OS 405 may include typical components such an 802.1X supplicant ("Supplicant 420"), a network stack, e.g., Transmission Control Protocol ("TCP"), User Datagram Protocol ("UDP") and/or Dynamic Host Configuration Protocol ("DHCP") (collectively referred to as "Network Stack 425") and a wireless network driver ("Driver 430"). In one embodiment, Host 405 may additionally include an "AMT offload API" ("AMT Crypto Offload API 435") and EAP methods ("EAP Methods 440").
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the supplicant teachings of the prior art of record by implementing the supplicant as part of the OS teachings of Sood to realize the instant limitations. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly,
since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the OS supplicant of the secondary reference(s) for the non-OS supplicant of the primary references. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious. The motivation to combine the references is applied to all dependent claims under this heading.
Per claim 2, the prior art of record further suggests wherein a cloud authenticator is implemented in the secure cloud environment (reads on the authentication server in cloud server of Sharaga para 0044 and Figures 2 and 3), and wherein the IEEE 802.1X authenticator proxy and the cloud authenticator are configured to collectively operate as an IEEE 802.1X authenticator (reads on the cloud authentication server and the authenticator operate collectively to authenticate the peripheral, see Sharaga para 0041).
Per claim 3, the prior art of record further suggests wherein, from the perspective of the authentication server, the authentication server is communicating with an IEEE 802.1X authenticator (reads on the authenticator acts as middle entity to receive and forward messages between authentication server and supplicant, see Sharaga para 0056).
Per claim 4, the prior art of record further suggests wherein the computer platform is running an operating system (reads on the computing device has an operating system, see Sharaga para 0002), further comprising exposing the secure cloud environment to the operating system as a virtual Wireless Local Area Network (WLAN) (The Examiner construes this to be an obvious limitation of the prior art’s teaching of an operating system running on a device and implementing any suitable means of communication because it is within the realm of conventional computer science based on the teachings of Sharaga, see Sharaga para 0002 and 0023).
Per claim 5, the prior art of record further suggests wherein the AP is deployed in a WLAN that is accessible to the public (The Examiner construes this to be an obvious limitation of the prior art’s disclosure of using any suitable means of communication, see Sharaga para 0023).
Per claim 6, the prior art of record further suggests wherein the secure cloud environment comprises a secure backend overlay network (reads on configured as any appropriate architecture or system that facilitates communications in a network environment using any suitable technologies, see Sharaga para 0023), and the LAN or WLAN comprises an underlay network (reads on configured as any appropriate architecture or system that facilitates communications in a network environment using any suitable technologies, see Sharaga para 0023).
Per claim 7, the prior art of record further suggests wherein the computer platform is running an operating system (reads on the computing device has an operating system, see Sharaga para 0002), further comprising exposing the overlay network as an enterprise SSID (Service Set Identifier) (reads on configured as any appropriate architecture or system that facilitates communications in a network environment using any suitable technologies, see Sharaga para 0023 and Nijdam page 1 lines 6 - 7).
Per claim 8, the prior art of record further suggests wherein the secure cloud environment employs a (Secure Access Service Edge) SASE architecture (reads on configured as any appropriate architecture or system that facilitates communications in a network environment using any suitable technologies, see Sharaga para 0023).
Per claim 9, the prior art of record further suggests wherein the 802.1X authenticator proxy is implemented using embedded logic in hardware on the computer platform (see Sharaga para 0033, 0039, 0070 and 0087).
Per claim 10, the prior art of record further suggests wherein the embedded logic comprises one or more of firmware executing on an embedded processor, logic programmed into a programmable logic device, or one or more Application Specific Integrated Circuits (ASICs) containing fixed logic (see Sharaga para 0087).
Claim 11 is analyzed with respect to claim 1. The prior art of record further suggests hardware, including a processor, memory, and a wireless network interface (see Sharaga para 0013 – 0014 and 0087).
Per Claim 12, the prior art of record further suggests wherein the hardware is further configured to: enable the computer system to connect to an IEEE 802.11-based AP via the wireless network interface (reads on the authenticator connects to the authentication server via the access point, see Sharaga para 0046, Figures 2 and 3 and Nijdam Figures 2); and expose a virtual network to the operating system as a virtual wireless network BSSID (Basic Service Set Identifier) (reads on using any appropriate architecture or system that facilitates communications in a network environment, see Sharaga para 0023 and Nijdam page 1 lines 6 - 7).
Claim 13 is analyzed with respect to claim 1.
Claim 14 is analyzed with respect to claim 7.
Per claim 15, the prior art of record further suggests the computer system comprises a laptop computer, a notebook computer, or a desktop computer (reads on any type of computing system that can be used to initiate network communications in a network including mobile devices, laptops and desktop computers, see Sharaga para 0033).
Claim 16 is analyzed with respect to claim 13.
Per claim 17, the prior art of record further suggests wherein the apparatus comprises a network interface chip or a wireless network interface chip (see Sharaga para 0075, 0078 and 0080).
Claim 18 is analyzed with respect to claim 10.
Claim 19 is analyzed with respect to claim 2.
Claim 20 is analyzed with respect to claim 4.
Claim 21 is analyzed with respect to claim 1.
Claims 21 – 25 are rejected under 35 U.S.C. 103 as being unpatentable over Sharaga (US Pub. No. 2016/0182499 A1) in view of Nijdam (WO 2007/107708 A2).
Per claim 21, Sharaga suggests a server, configured to be implemented in a secure cloud environment (reads on a cloud server as one or more servers including an authentication server and attestation server in a networked/cloud environment, see Sharaga para 0013 and 0025 – 0027) including an Institute of Electrical and Electronics Engineers (IEEE) 802.1X (The Examiner construes this to be obvious because one of ordinary skill in the art would know IEEE 802.1X is expressly built on EAP + RADIUS/Diameter, see Sharaga para 0044 – 0045) authentication server (AS) (reads on the authentication server and attestation server combination in the cloud server of Sharaga Figure 2 block 130, 131 and 133),
wherein the server is configured as a cloud authenticator (reads on cloud server can be configured with one or more servers including an authentication server, see Sharaga para 0013, 0044 and Figure 1/2 blocks 130, 131. The Examiner asserts the authentication server implements EAP authentication, acts as AAA server with RADIUS/Diameter and is located in a cloud based component which is precisely a cloud authenticator as claimed) that performs server-side operations in cooperation (reads on exchanging messages between authenticator 161 and authentication server 131 which is clear cooperation, see Sharaga para 0035, 0056) with an authenticator proxy (reads on the authenticator 161 in the client TEE which is functionally an authenticator proxy between the local supplicant and the remote cloud server, see Sharaga para 0035, 0045, 0056 and Figure 2 blocks 150, 160, 161 and Figure 1 blocks 150, 160) in a client device (see Sharaga Figure 1/2 block 150) connected to (reads on the arrows between Sharaga blocks 130 and 150) the secure cloud environment (reads on the cloud server, see Sharaga Figures 1 / 2 block 130) to facilitate establishment of an encrypted Layer 2 (L2) (The Examiner construes this to be a necessary if not obvious limitation of implementing the EAP-FAST (Flexible Authentication via Secure Tunneling with a protected authentication credential) because one of ordinary skill in the art would know EAP-FAST creates an encrypted end-to-end tunnel (using TLS) to protect the inner authentication credentials from eavesdropping and man-in-the-middle attacks. The tunnel is established using a shared secret (PAC) or optionally a server certificate to secure the subsequent EAP method exchange, see Sharaga para 0035. In addition, one of ordinary skill in the art would know EAP-FAST (Flexible Authentication via Secure Tunneling) is inherently tied to Layer 2 network access control because the underlying Extensible Authentication Protocol (EAP) framework is designed to operate at the link layer to facilitate initial network access decisions before higher-layer protocols (like IP) are configured) end-to-end (reads on end-to-end authentication between peripheral device and cloud server, see Sharaga para 0035) tunnel (The Examiner construes this to be an obvious limitation of the prior art’s VPN/trusted or secure connection via RADIUS/Diameter secret/encryption key for trusted and secure communications/ EAP-FAST disclosure because these technologies at the least imply and in some cases require secure/encrypted tunneling, see Sharaga para 0023, 0028, 0031 and 0035) between the client device (reads on the TEE inside the client computing device, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) and one or more servers in the secure cloud (reads on the cloud server, see Sharaga Figure 1 and Figure 2 and para 0028, 0031 and 0035) environment using an IEEE 802.1X authentication process (reads on well-known EAP methods like EAP-TLS, EAP-AKA, and EAP-FAST commonly run over RADIUS/Diameter to provide authentication, and this entire framework implies or is foundational to IEEE 802.1X for network access control, see Sharaga para 0035). The prior art of record is silent on explicitly stating Institute of Electrical and Electronics Engineers (IEEE) 802.1X authentication server; and an authenticator proxy.
[0013] FIG. 1 is a simplified block diagram of an example communication system 100 for establishing trust between a trusted execution environment (TEE) and peripheral devices. Communication system 100 includes an example computing device 150 with a TEE 160. Computing device 150 can be coupled to multiple internal and external peripheral devices. Examples of internal and external peripheral devices may include, but are not limited to a keyboard 171, a universal serial bus (USB) storage device 172, a display screen 173, a mouse 174, memory modules 175, a network interface card (NIC) 176, and a hard disk 177. A network 110 can facilitate network communication between computing device 150 and a cloud server 130. Cloud server 130 can be configured with one or more servers including an authentication server 131 and an attestation server 133.
[0022] Turning to FIG. 2, FIG. 2 is a simplified block diagram illustrating one possible set of details associated with communication system 100. Computing device 150 is configured with trusted execution environment (TEE) 160, which can include an authenticator 161, a radius/diameter client 162, an attestation client 163, a cryptography module 164, a policy module 165, a pairwise master key (PMK) database 167, a memory element 158, and a processor 159. An example peripheral device 180 can include a supplicant 181, a cryptography module 184, a policy module 185, one or more credentials 186, a PMK register 187, a memory element 188, and a processor 189. Cloud server 130 can include authentication server 131, attestation server 133, one or more credentials database 136, a memory element 138, and a processor 139. Before discussing potential flows associated with the architectures of FIGS. 1-2, a brief discussion is provided about some of the possible components and infrastructure that may be associated with communication system 100.
[0025] Cloud server 130 represents one or more servers configured by a vendor of peripheral devices (or by another capable entity) to enable trust to be established between TEEs and the peripheral devices associated with the vendor. A vendor could be a manufacturer, seller, producer, end device owner (e.g., Information Technology shop, etc.), etc. of peripheral devices. A vendor configures (or causes to be configured) its peripheral devices with credentials and supplicants. In one possible implementation, the vendor may also configure (or cause to be configured) one or more servers with corresponding credentials or access to corresponding credentials. In other possible implementations, a server may be configured by any other entity capable of configuring the server with credentials that correspond to the credentials configured in the peripheral devices. For example, an authentication server may be implemented with credentials in-house in high security scenarios, and corresponding credentials can be provided to the vendors to configure the peripheral devices. Cloud server 130 is an example of a server that could be configured by a vendor or other capable entity.
[0026] Cloud server 130 can be provisioned in any suitable network environment capable of network access (e.g., via network 110) to a TEE of a computing device. Such network environments can include, but are not limited to, the backbone of the vendor's network infrastructure, which may be configured on the premises of the vendor, the backbone of a network infrastructure of an entity associated with end devices when an authentication server is implemented in-house, or one or more cloud networks offered by a cloud service provider. The configuration and provisioning of a peripheral device and the associated cloud server enables an end-to-end trusted relationship between the peripheral device and a TEE of a computing device to be established.
[0027] A server, such as cloud server 130, is a network element, which is meant to encompass routers, switches, gateways, bridges, loadbalancers, firewalls, inline service nodes, proxies, proprietary appliance, servers, processors, modules, SDN controller/switch, or any other suitable device, component, element, or object operable to exchange information in a network environment. This network element may include any suitable hardware, software, firmware, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.
[0028] Cloud server 130 can include authentication server 131, attestation server 133, credentials database 136, a memory element 138, and a processor 139. Authentication and attestation servers 131 and 133 may be discrete entities residing in different machines or may be combined in a single cloud server, as shown in FIG. 2. In at least one embodiment, authentication server 131 may be configured for a particular vendor as an authentication, authorization, and accounting (AAA) server. An authentication server 131 can operate according to either Radius (Remote Authentication Dial-In User Services) protocol, as defined by Internet Engineering Task Force (IETF) Request for Comments (RFC) 2865, entitled “Remote Authentication Dial In User Service (RADIUS),” dated June 2000, or by a successor protocol to RADIUS, referred to as Diameter and defined by IETF RFC 6733, entitled “Diameter Base Protocol,” dated October 2012. Generally, a shared secret can be used with Radius and Diameter protocols to verify that received messages are sent by a Radius/Diameter-enabled device configured with the same shared secret. Additionally, the shared secret can also be used to verify message integrity (i.e., that the message has not been modified in transit). Accordingly, once a Radius/Diameter shared secret has been configured in a Radius/Diameter server and Radius/Diameter client, a trusted or secure connection can be established between the two.
[0031] In at least one embodiment, trust between cloud server 130 (via authentication server 131) and TEE 160 can be dynamically established. Cloud server 130 is capable of performing attestation protocol with a TEE and using an encryption key generated from that exchange as a Radius/Diameter secret. In at least one embodiment, attestation server 133 uses an attestation and key exchange protocol to communicate with attestation clients in TEEs, such as attestation client 163 in TEE 160, to dynamically establish trust between the TEEs and the cloud server. The attestation exchange can cause an encryption key to be generated by the attestation server and the attestation client in the TEE. The encryption key may be symmetric (i.e., the same key is known to the endpoints) and can be a secret if it is known only to the endpoints (e.g., attestation client 163 and attestation server 133). For ease of reference, the encryption key is also referred to herein as ‘symmetric key’. However, it will be apparent that other types of keys, such as asymmetric keys for example, may be used in other embodiments. Authentication server 131 can use the encryption key from attestation server 133 to configure a Radius/Diameter secret to enable trusted and secure communications with TEE 160.
[0035] Authenticator 161 is configured to use an EAP authentication framework to authenticate a peripheral (e.g., peripheral device 180) to its respective cloud server (e.g., cloud server 130) and establish trust with the peripheral using a unique pairwise master key generated during the EAP authentication. The end-to-end (E2E) authentication between peripheral device 180 and cloud server 130 can be implemented using any well-known EAP method including, but not limited to, EAP-TLS (Transport Layer Security (TLS) protocol with an X.509 certificate), EAP-AKA (Authentication and Key Agreement (AKA) protocol with a universal Subscriber Identity Module (USIM)), or EAP-FAST (Flexible Authentication via Secure Tunneling with a protected authentication credential (PAC)). Authenticator 161 can run over Radius/Diameter client 162 to communicate with authentication server 131. The Radius/Diameter protocol provides a secure connection between TEE 160 and cloud server 130.
[0036] The EAP authentication framework used by authenticator 161 is enhanced with an attestation capability of TEE 160 such as EPID or any root of trust/attestation inside the TEE. Attestation client 163 of TEE 160 communicates with attestation server 133 of cloud server 130 using an attestation and key exchange protocol (e.g., Sigma/EPID, TLS, AKA, etc.) to dynamically establish trust between TEE 160 and cloud server 130.
[0044] Turning to FIG. 3, FIG. 3 illustrates logical entities included in at least one embodiment of an extensible authentication protocol (EAP) authentication framework according to the present disclosure. EAP is an authentication framework that is generally used for network communications and is defined in IETF RFC 3748, entitled “Extensible Authentication Protocol (EAP),” dated June 2004. In at least one embodiment, the logical entities of the EAP authentication framework include a supplicant 380, an authenticator 360, and an authentication server 330. Supplicant 380 resides in an end device that requests authentication (e.g., supplicant 181 in peripheral device 180). Authenticator 360 resides in the entity with whom the supplicant needs to establish trust by access and shared keys (e.g., authenticator 161 in TEE 160). Authentication server 330 has corresponding (the same or complementary) credentials with supplicant 380 and performs an authentication protocol, such as an EAP method. Authentication server 330 can be an authentication server in cloud server (e.g., authentication server 131 in cloud server 130).
[0045] The EAP framework, as shown in FIG. 3, may use the Radius or Diameter protocols 316 between authenticator 360 and authentication server 330. Radius and Diameter protocols are secure protocols with a pre-shared key (e.g., Radius key, Diameter key) that is established out-of-band from the protocol. In at least one example, communication between authenticator 360 and authentication server 330 may occur using Internet Protocol (IP) 318 over a network, such as network 110. A medium 320 used for communication between supplicant 380 and authenticator 360 can be wired or wireless and is considered non-secure until trust is established. Common, but non-limiting examples of medium 320 include LANs, USBs, and WiFi. The EAP framework enables the establishment of trust in medium 320 while utilizing the medium itself for message exchange.
[0054] Once the attestation is completed, at 414, attestation server 133 can set the Radius/Diameter secret for authentication server 131 based on the symmetric key generated in attestation server 133 during the attestation exchange. At 416, attestation client 163 can set the Radius/Diameter secret for authenticator 161 based on the symmetric key generated in the TEE during the attestation exchange. Once the Radius/Diameter secrets have been configured for authentication server 131 and authenticator 161 of TEE 160, a trusted Radius/Diameter connection can be established at 418 between authentication server 131 and authenticator 161.
[0055] At 420, the authenticator can send the EAP identity of peripheral device 180 to authentication server 131. The EAP identity can be the identifier received from supplicant 181 at 408. The EAP identity can enable authentication server 131 to determine corresponding credentials of peripheral device 180 that are stored, for example, in credentials database 136. At 422, authentication server 131 and authenticator 161 may agree to use a particular EAP method. For example, the vendor of peripheral device 180 may have configured and stored an X.509 certificate as credentials 186 of peripheral device 180 and in credentials database 136 of cloud server 130. In addition, the vendor may have configured an indicator in a database (or other suitable storage) identifying TLS as the EAP method to be used to authenticate peripheral device 180. Accordingly, an EAP TLS method may be performed at 422 between supplicant 181 and authentication server 131.
[0056] Authenticator 161 acts as a middle entity to receive and forward messages between authentication server 131 and supplicant 181. Messages can be exchanged between authenticator 161 and authentication server 131 during the EAP method based on Radius or Diameter protocol, where the Radius/Diameter secret is based on the attestation exchange. Messages can be exchanged between authenticator 161 and supplicant 181 during the EAP method using a data link layer transport. During the EAP method, a master key can be created in both authentication server 131 and supplicant 181, according to the particular authentication scheme that is used (e.g., TLS). At 424, authentication server 131 sends a message to authenticator 161 that indicates the EAP method was a success. The message can include a pairwise master key (PMK), which can be a derivative of the master key in at least one embodiment. After the success message with the PMK is received, at 426, authenticator 161 sends a message to supplicant 181 that indicates the EAP method was a success.
[0057] At 428, supplicant 181 can derive the same or a complementary PMK from the master key that was created during the EAP method. At 430, the PMK is verified between the TEE and the peripheral device to ensure that they share corresponding PMKs. Various techniques can be implemented to perform this verification and embodiments disclosed herein are not limited to a particular technique. By way of example, a 4-way handshake could be performed between authenticator 161 and supplicant 181 to verify the PMK. Once the PMK is verified, at 432, it can be stored in the peripheral device (e.g., in PMK register 187), and at 436, the PMK can be stored in the TEE (e.g., in PMK database 167). The TEE may also store the identifier of the peripheral, which may be mapped to or otherwise associated with the PMK. Thus, trust can be established between the TEE and multiple peripheral devices, where a unique PMK is associated with each peripheral device, and mappings between the PMKs and their respective peripheral devices are stored in the TEE. Other parameters associated with the peripheral device may also be stored in the TEE including, but not limited to, a lifetime parameter and a reputation parameter. Parameters may be received from authentication server 131 and/or from the peripheral device itself.
[0058] In addition, as part of verifying the PMK at 430, a transport key may also be derived. For example, during a 4-way handshake between authenticator 161 and supplicant 181, the PMK can be used to derive a transport key. The transport key can be used to protect data (e.g., by encryption) that is exchanged between the peripheral device and the TEE. The transport key can be derived from the PMK each time the computing device associated with the TEE powers on and the PMK is verified. At 434, the transport key may be provided to peripheral device 180 to use for encrypting data exchanged with the TEE.
Nijdam suggests an Institute of Electrical and Electronics Engineers (IEEE) 802.1X authentication server (AS) (reads on a 802.1x authentication server, see Nijdam page 10 lines 21 – 31); authenticator as translation/proxy entity (reads on authentication of the supplicant by the authentication server occurs through the authenticator, see Nijdam page 10 lines 30 – 31. The Examiner relies on the functional description and asserts one of ordinary skill in