Methods and devices for providing a security level for communications

Abstract

A device 110, 120 and a method for establishing a secure communication between a first device and a second device over a physical channel by a security protocol are described. The protocol establishes a first integrity data in the first device and a second integrity data in the second device. The protocol has at least two security levels. The applied security level is selectable based on grading information transported over the physical channel. Advantageously, a grading indicator indicating a minimum security level as minimally required in at least one of the first device 110 and the second device 120 is transported over the physical channel, while integrity protection of the grading indicator is provided based on the integrity data. This prevents man-in-the-middle attacks by a further device (130) to downgrade the security level.

Description

Technical Field

[0001] The present invention relates to a method and a device for establishing a security level for communication between a first device and a second device via a physical channel according to a security protocol.

[0002] The present invention relates to the field of security of wireless or wired data communication, and more particularly, to providing a device and a method to which a security protocol is applied. The security protocol establishes first integrity data in a first device and second integrity data in a second device. The integrity data provides integrity protection for messages transferred via a physical channel. The security protocol provides various security levels, and the security levels define, for example, at least one specific security measure, a cryptographic algorithm, a security option or a key length.

Background Art

[0003] To gain access to a Wi-Fi access point (AP), a device securely connects to a wireless network, for example, according to a Device Provisioning Protocol (DPP), see [DPP]. DPP is a protocol for configuring Wi-Fi devices using a DPP configurator device. A device seeking access is called a DPP enroller. When a device is configured by DPP, it receives a DPP configuration object from the DPP configurator. The DPP configuration object includes a so-called connector or DPP connector. The connector is signed by the DPP configurator. The connector contains the public key, network access key, netAccessKey, or NAK, belonging to the device. The NAK exists in plain text within the connector. Other information, such as an expiration timestamp, also exists in plain text within the connector. Since the DPP configuration object is not signed, it has no integrity protection. Nevertheless, the DPP configuration response message, which is a message sent to the DPP enroller, is integrity protected by a symmetric key negotiated between the DPP configurator and the DPP enroller in the previous DPP authentication protocol. In this application, the acronym DPP refers to any version of DPP, such as DPP R1, DPP R2, and any subsequent releases.

[0004] Given the increasing number of connected devices, security concerns are growing, particularly regarding privacy and protection against third-party tracking. Tracking refers to tracking a device's location across multiple communication sessions within a network, for example, based on recurring data within the device's messages. Document WO2020043634A1[2018PF00508] describes an upgraded security protocol that includes security options to provide protection against such tracking.

[0005] Therefore, existing security protocols are upgraded to at least one enhanced security level. Previous versions of such protocols are also typically supported for interaction with existing devices. The applicable security level, such as the version or option of the security protocol to be used, is negotiated between devices during the setup of communication using grading information transmitted over the physical channel. The grading information is, for example, an explicit indication that a specific version or security option of the protocol is supported by the devices. The grading information is also implicit by other protocol data, for example, by including keys of specific lengths if multiple key lengths are supported. The applicable security level is determined by exchanging the grading information. However, such messages can still be intercepted and modified by devices operating over the physical channel, which is called a "man-in-the-middle" attack (MitM). The aforementioned manipulation of the grading information may result in the security level being established lower than intended, which is called "downgrading" the security level. [Overview of the project]

[0006] To mitigate at least one of the security problems described above, the object of the present invention is to provide methods and devices for protecting against security level downgrading, for example, via the aforementioned MitM. For this purpose, devices and methods as defined in the appended claims are provided. According to one aspect of the present invention, a method is provided for establishing a security level for communication between a first device and a second device over a physical channel by a security protocol, as defined in claim 1. According to a further aspect of the present invention, devices and methods as defined in the independent claims are provided.

[0007] The security protocol provides for establishing first integrity data in a first device and second integrity data in a second device. The integrity data is applied to provide integrity protection for messages transported over a physical channel. For example, the first integrity data is the public key of the second device stored in the first device, while the second integrity data is a signature set by the second device using the corresponding private key. The first integrity data may also be a connector signature or certificate supplied to the first device by a third party.

[0008] A security protocol provides at least two security levels, which are selectable based on grading information, such as a basic security level and at least one upgraded security level. The actual security level to be applied is determined based on the grading information via the physical channel. The grading information is transported via the physical channel and is either part of one or more explicit or implicit protocol messages, or embodied in separate messages exchanged. Any message containing explicit or implicit grading information is referred to in this document as a grading message. Grading messages are transported via the physical channel. Therefore, grading information means any data appropriate for establishing one or more grades of security that devices can provide and that will be used between devices for communication, privacy protection, integrity protection, authentication, network access, etc. For example, grading information includes a version indicator of the security protocol supported by the device. A unique version number indicates the range of security options that other devices may choose, as specified by the protocol specification for this version.

[0009] The method and device are configured to transport a grading index indicating the minimum security level required by at least one of the first and second devices via a physical channel. Furthermore, the device and method provide integrity protection for the grading index based on integrity data. The grading index is transported separately via a physical channel, via different channels, or as part of a grading message.

[0010] Grading information may be fully or partially integrity-protected, or not integrity-protected at all. In contrast, grading indicators are always fully integrity-protected. Therefore, grading indicators help prevent MitM attacks against the unintegrated portion of a grading message from causing a negotiated security level below a certain level, or maintain a certain minimum security when changing server or client setups without requesting a new certificate.

[0011] In effect, a device sends a grading index, and the device itself or the recipient then applies the minimum security level indicated by the grading index. Furthermore, when two devices cooperate, they both apply at least the security level indicated by the grading index. Moreover, when two devices exchange grading messages indicating that a higher security grade, higher than that required by the grading index, is supported by both devices, such a higher security level is also selected. Nevertheless, downgrading to a security level lower than that indicated by the grading index is blocked. Therefore, if a grading message allows for outdated communication at a lower security grade supported on both sides of a communication link, and the communication link applies a security level lower than that indicated by the grading index, such a link can be blocked. Similarly, when a device receives a message containing a grading index and verifies its integrity, it can block or abort any communication with a security level lower than that indicated by the grading index.

[0012] Conveniently, the grading information indicates at least one security level that could be considered a suggestion, while the grading indicator indicates the constraints on the security level that will actually be used. Therefore, in common language, this means either "at least level X must be used, regardless of what is mentioned in the grading message," or "at least level X must be used if it supports level X, otherwise at least level Y must be used (level Y is less secure than level X)."

[0013] Providing integrity protection covers both sending and receiving actions. For example, providing integrity protection for grading metrics based on integrity data involves a device signing the grading metric message and checking the signature upon receiving the message. Alternatively, providing integrity protection is the act of a first device sending an object containing the grading metric, which is then signed by a third device. The receiver then verifies the signature using the respective key materials of the third device. This occurs, for example, during negotiations for the use of PFS and tracking prevention in network deployment protocols, as will be discussed later.

[0014] According to a further aspect of the present invention, the security protocol is based on a device provisioning protocol that further requires a configurator adapted to establish communication between a first device and a second device in a wireless network, such as DPP. The configurator is arranged to insert a grading index into a connector message and to send the connector message to the first device. The processor of the first device is configured to receive the connector message and to extract the grading index from the connector message.

[0015] Further preferred embodiments of the devices and methods according to the present invention are shown in the appended dependent claims, the disclosures of which are incorporated herein by reference.

[0016] These and other aspects of the present invention will become clear and apparent with further reference to the embodiments described as examples in the following description and with reference to the accompanying drawings. [Brief explanation of the drawing]

[0017] [Figure 1] This is a diagram of a system in which the present invention is put into practice. [Figure 2a] This is a diagram of a computer-readable medium. [Figure 2b] This is a schematic diagram of the processor system. [Modes for carrying out the invention]

[0018] The diagram is purely illustrative and not drawn to be scaled. In the diagram, elements corresponding to elements already described have the same reference number.

[0019] Figure 1 shows a system 100 comprising a first device 110, a second device 120, and a third device 130. Each of these devices has a communication module 111, 121, 131 with a transmitter / receiver suitable for communication over a physical channel 160, such as Wi-Fi, Bluetooth, or a wired network. The devices have input / output units for communication over a wired physical channel and / or at least one antenna 113, 123, 133 that functions as input / output for a wireless physical channel. Each of the devices operates under the control of a processor 112, 122, 132. Further elements of the communication modules, processors, and devices are integrated into a single system on a chip. Each of the devices has a user interface 151, 152, 153 having at least one user control element. For example, the user control element may be a touch screen, various buttons, a mouse, or a touchpad. The buttons may be traditional physical buttons, touch sensors, or virtual buttons on a touch screen, for example, or icons that will be activated via a mouse. A user interface is also a remote user interface.

[0020] In practice, the first device may correspond to a portable device such as a mobile phone, laptop, or tablet with an end user. The first device may also be an IoT (Internet of Things) type device. The second device may correspond to a server, access point, router, further portable device, or IoT device, etc. The user of the first device is interested in connecting to the second device (access point) to access one or more resources provided through the second device. The third device, although not actually part of the present invention, corresponds to a so-called man-in-the-middle, i.e., a device used by a malicious third party to intercept, modify, or replace messages between it and the first device.

[0021] In this application, the term “certificate” is intended to refer to a small block of data containing, at least, the public key of the certificate’s owner. An example of a certificate as intended in this application is an X509 v3 [RFC5280] certificate. The owner is referred to as the “subject,” and the public key is referred to as the “subject public key.” The small block is digitally signed by a Certificate Authority (CA) referred to as the “issuer.” With the exception of so-called root certificates, certificates are signed by an entity (the “issuer”) that is separate from the owner (the “subject”) of the certificate’s public key (the “subject public key”). Root certificates are signed by the owner themselves, i.e., the elements “issuer name” and “subject name” are the same.

[0022] The public key used to verify the signature of a certificate can be found as the "subject public key" of another certificate, where the "subject name" is the same as the "issuer name" of the certificate being verified. If this other certificate is a root certificate, the "subject public key" of the root certificate can be used to verify the signature of the root certificate. If this other certificate is not a root certificate and is therefore issued by yet another issuer, issuer 2, then the signature of the root certificate can be matched against the "subject public key" of yet another certificate that has issuer 2 listed in the "subject name" element of the root certificate. Certificate signature matching, therefore, involves matching the signatures of several certificates in the so-called certificate tree, up to the root certificate (including the root certificate).

[0023] A DPP connector, like a certificate, is a small piece of data that contains at least the public key of the owner of the DPP connector (i.e., the device configured by the DPP configurator). This small piece of data is digitally signed by the DPP configurator, not by a CA. One difference between the latter two is that a CA is publicly known, and some properties of the CA, such as the CA's issuer name or the CA's root certificate, are publicly known and can be found on the internet, whereas a DPP configurator is not publicly known. For example, Digicert provides CAs (www.digicert.com). A list of root certificates is provided at https: / / www.digicert.com / kb / digicert-root-certificates.htm, and the "DigiCert Assured ID Root CA" is available at https: / / cacerts.digicert.com / DigiCertAssuredIDRootCA.crt. For example, when examining this root certificate using a suitable tool such as the website https: / / lapo.it / asn1js / , you can see that, for example, the "Issuer Name" and "Subject Name" are "countryName US;organizationName DigiCert Inc;organizationalUnitName www.digicert.com;commonName DigiCert Assured ID Root CA".

[0024] Another difference between a certificate and a connector is how the device is configured with the public key to verify the signature. In the case of certificate signature verification, the public key for doing this is provided in the form of the certificate itself, together with all the certificates in the certificate tree up to and including the root certificate of the certificate tree. The certificate tree is installed on the device by a special and secure mechanism. This is done, for example, at manufacturing time. Also, this is done, for example, by using a secure Internet connection. For example, Microsoft uses a dedicated secure connection between Windows devices and its servers to provide the latest certificate tree to Windows devices. The web browser Firefox uses its own dedicated secure channel between the Firefox installation and a server from Mozilla to provide the latest certificate tree to the Firefox installation even when running under the Windows operating system. The security required is not for keeping the certificate secret but for ensuring that only a valid certificate tree is provided. For example, a device provided with a malicious root certificate by a hacker will start to trust a website that provides a certificate signed with the public key of this root certificate (the certificate). In contrast, the DPP configurator public key is provided not in the form of an enrollment in the form of a certificate but in a message protected (for integrity) by a symmetric key. Various examples of grading information in DPP are discussed below.

[0025] In the DPP reconfiguration authentication protocol, the first message is the DPP reconfiguration announcement message. The first message is not integrity protected.

[0026] Enrollment -> Configurator: SHA256(C-sign-key), Group, A-NONCE, E’-id The attribute "SHA256(C-sign-key)" indicates the configurator signature key. The configurator has multiple signature keys. These belong to the same elliptic curve group (e.g., NIST P-256) or different elliptic curve groups (e.g., NIST P-256 and NIST P-384). Therefore, this attribute indicates the configurator signature algorithm and the signature algorithm security level, and thus functions as grading information. The attribute "Group" indicates the elliptic curve group of the enrollee's NAK. Therefore, this attribute indicates the algorithm to be used for calculating the PMK, and this attribute indicates the security level (here, more specifically, the number of bits) of the PMK, and thus also contributes to the grading information.

[0027] The attributes "A-NONCE" and "E’-id" are elliptic curve points on the same elliptic curve as the configurator signature key, and thus do not add more information about the security level.

[0028] If the enrollee supports only one curve, for example, the mandatory NIST P-256 curve, the device only supports this as the first level. The second security level is then P-256 and tracking prevention, and these are indicated by parameter or version indication. Therefore, the function of tracking prevention is known to the configurator at this point but is not required as such.

[0029] The second message in the DPP reconfiguration authentication protocol is the DPP reconfiguration authentication request message. The second message is not integrity protected except for the attribute "C-Connector".

[0030] Configurator -> Enrollee: TransId, Protocol Version, C-Connector, C-nonce The attribute "TransId" is a random number that will be copied within the following two protocol messages. The attribute "Protocol Version" represents the DPP protocol version supported by the configurator. If different versions provide or specify other security levels, this attribute indicates the security level. This attribute is not integrity protected. When the DPP R3 specification supports the use of tracking block, this attribute is available to select "Upgraded Security Level," i.e., use tracking block during reconfiguration. Alternatively, in DPP R3, a value of 3 for the attribute "Protocol Version" (representing DPP Release 3) indicates that the configurator supports enabling tracking block for the enloader connector's NAK within the following message. The attribute "Protocol Version" functions as grading information and is therefore considered a grading message, in which case the configurator indicates that the enloader has two options: use tracking block or not. The attribute "C-Connector" indicates the configurator signing key, i.e., the identifier "kid" in the connector's JSON Web Signature (JWS) protection header (see section 4.2 of [WFEC_2]). The configurator has multiple signing keys. The multiple signing keys may belong to the same elliptic curve group (e.g., NIST P-256) or to different elliptic curve groups (e.g., NIST P-256 and NIST P-384). The configurator signing key should be indicated by an Enlorie with the attribute "group". Thus, this attribute indicates the configurator signing algorithm and the signing algorithm security level. This attribute also includes the NAK. This attribute should lie on the same curve as the Enlorie's NAK. Thus, this attribute also indicates the algorithm to be used to compute the PMK, and this attribute indicates the security level of the PMK (e.g., specifically, the number of bits).

[0031] The attribute "C-Connector" includes a grading index to indicate whether or not the enloader can use tracking block for the enloader's NAK. When communicating with the configurator, the grading index indicating that the enloader must use tracking block for the enloader's NAK is also sent by the configurator as part of the DPP configuration response message, either within one of the connectors in this message or in another part of this message.

[0032] Further examples relate to network deployment protocols. The following message is a DPP peer discovery request message.

[0033] Device B → Device A: TransID, Connector B, [Protocol Version] Device B is a non-AP Wi-Fi device, while Device A is a Wi-Fi AP device.

[0034] The attribute "TransID" is a random number that will be copied in the next protocol message. The attribute "ConnectorB" contains the configurator signing key and the NAK index of the non-AP device, the information of which is considered grading information. If the non-AP device supports only one curve, such as P-256, then only one security level can be selected along with this information. The attribute "ConnectorB" contains a grading index to indicate whether the AP can or must use tracking block for the NAK of this connector, or whether it must use PFS. The optional attribute "Protocol Version" indicates the version of the DPP protocol supported by the non-AP device. PFS is defined in DPP R2. When DPP R2 is indicated in this attribute, the AP decides whether or not to use PFS. Therefore, this attribute also contributes to grading information.

[0035] If the enroller wishes to use tracking block for NAK of this connector, it should be noted that the enroller must obtain information that the AP supports this function in another way, for example, from further informational elements that the AP includes in the AP's beacon or probe response. Such elements can be considered grading information.

[0036] In a further example, the DPP peer discovery response message is as follows:

[0037] Device A → Device B: Transaction ID, DPP Status, Connector A, [Protocol Version] The attribute "DPP Status" in this case contains the value DPP_STATUS_OK. When this attribute has a different value, the attributes "ConnectorA" and "Protocol Version" are omitted. The functionality of the other attributes is the same as described above for DPP peer discovery request messages, but the device is replaced.

[0038] In the following, specific embodiments of the present invention will be described in relation to the general-purpose system described above.

[0039] In a first exemplary embodiment, the device functions as a first device adapted to establish a security level for communication between a first device and a second device over a physical channel by a security protocol, as described above. The device has a processor configured to send or receive over the physical channel a grading index indicating a minimum security level such that it is at least required by at least one of the first and second devices. When sending, the processor includes protective data for the grading index based on integrity data. When receiving, the processor verifies the protective data based on integrity data. The processor then applies at least a minimum security level for communication between the first device and the second device.

[0040] Optionally, the security protocol is based on a device provisioning protocol that further requires a configurator adapted to establish communication between a first device and a second device in a wireless network. The configurator is configured to insert grading indicators into connector messages and to send connector messages to the first device. The processor of the first device is configured to receive connector messages and to extract grading indicators from connector messages.

[0041] Optionally, a security protocol with a first security level requires determining a pair of master keys on both the first and second devices based on private and public key material, and the pair of master keys is used to determine the session key for encrypted communication between the first and second devices. Furthermore, a security protocol with a second security level requires determining a pair of master keys with a transient Diffie-Hellman key pair, and the device's processor is configured to apply the second security level when instructed so by a grading index. As an example of "with a transient Diffie-Hellman key pair," PFS is described below, and PFS provides an example of an upgraded security level.

[0042] Typically, in the above embodiments, at least one grading message lacks integrity protection in the security protocol. Therefore, such messages are vulnerable to MitM attacks. Optionally, various parameters in such messages are protected by transporting the grading indicator at some point in the enhanced security protocol. The grading indicator provides constraints, limits, or requirements for various elements affected by manipulating the grading message without integrity protection.

[0043] In various embodiments, the communication channel is Wi-Fi. The second device corresponds to an access point (AP), and the first device attempts to connect to the AP, for example, via the SAE protocol (see Section 12.4 of [WPA3] or [802.11]). In each device, the protocol according to the present invention is implemented in the module controller (113, 123), the processor (114, 124), or by both working together during protocol execution. Embodiments relate to negotiating the Perfect Forward Security (PFS) feature, which is an addition to version 2 of DPP (see Section 6.6.3, “Network Access Protocols” of [WFEC_2]). Therefore, the grading message includes an indicator of the version of the security protocol supported by the device. For example, the version designation might be a V3 device, which would then be an unprotected "grading information" indicating that the device supports a specific security level, such as "V3," while V3 would suggest that security options like PFS are being used.

[0044] When a device wishes to connect to an AP using DPP, it sends its connector to the AP in a so-called DPP peer discovery request frame. This frame is not encrypted. This frame is also not integrity protected, meaning that it can be modified by a man-in-the-middle (MitM) attacker. Note that while the connector is integrity protected by the signature from the DPP configurator device, all other attributes in the DPP peer discovery request frame are not integrity protected, so it is impossible for the connector to be modified by MitM without the recipient noticing the change.

[0045] An AP receiving a DPP peer discovery request frame will check the connector in this frame. If the AP determines that the connector is legitimate—that is, that the signature is correct, the connector is not expired, and the connector is for a network provided by the AP—the AP can reply with a DPP peer discovery response frame. This frame contains the AP's connector, which must be signed by the same configurator that signed the device connector. A device receiving a DPP peer discovery response frame will check the AP connector in the same way that the AP did. If the device determines that the AP connector is correct and matches its own connector (see section 6.4.2, “Connector Group Comparison” in [DPP]), the device can use its own secret NAK and the public NAK from the AP connector to calculate the master key (PMK) of the pair in Diffie-Hellman format (see [DH]) (see section 6.4, “Network Deployment Protocol” in [DPP]). The AP can use its own secret NAK and the public NAK in the device connector to calculate the same value for the PMK. The PMK is the basis for calculating the session key between the device and the AP using a so-called four-way handshake (see [802.11]). After a successful four-way handshake, the device is associated with the AP, and transmissions between the device and the AP are encrypted and integrity-protected with the session key derived from the PMK and the plaintext information sent during the four-way handshake.

[0046] Version 2 of DPP, now called Wi-Fi Easy Connect(TM) [WFEC_2], features an improved DPP deployment protocol. The problem with Release 1 is that the PMK between a Wi-Fi device and an AP is always the same. Suppose an attacker captures all Wi-Fi traffic between a device and an AP, and therefore the DPP network deployment protocol exchange, the four-way handshake to calculate the session key, and the encrypted exchange after association. Since the hacker has obtained the public NAK from another device of the connected device, sent in plain text, when the attacker hacks the device or AP and obtains one of the secret NAKs, the attacker can calculate the PMK between the device and the AP. Using the PMK and nonce from the captured four-way handshake, the attacker can calculate the session key and decrypt all encrypted transmissions between the two devices.

[0047] To protect against this attack, the PFS feature was added in version 2 of DPP. The PMK calculation now also involves a transient Diffie-Hellman key pair (public / private ECC keys). Since the private key of the transient Diffie-Hellman key pair must be deleted by the device after use, an attacker hacking either of the two devices cannot obtain these transient private keys and therefore cannot calculate the PMK to be used, nor can they decrypt encrypted transmissions that have occurred between the device and the AP in the past.

[0048] The problem with PFS, as specified in [WFEC_2], is that the use of PFS is negotiated in an insecure manner. When a device wants to use PFS, it adds a protocol version attribute to a DPP peer discovery request frame with a value of 2 or more. When an AP receives a DPP peer discovery request frame with a protocol version attribute with a value of 2 or more, and the AP supports PFS, the AP will respond with a DPP peer discovery response frame with a protocol version attribute with a value of 2 or more. In this case, both devices will use PFS to calculate the PMK, as specified in section 6.6.3 “Network Access Protocols” of [WFEC_2]. Since non-connector attributes in the DPP peer discovery request or response frame are not integrity protected, a MitM attacker can modify either of the two peer discovery frames so that the protocol version attribute has a value less than 2, or so that the protocol version attribute is removed entirely. If this is the case for either or both of the peer discovery frames, the device and AP will not use PFS. Such an attack is an example of a downgrade attack that should be prevented.

[0049] One possible, obviously simple option is for the device or AP to be set up so that PMK is not calculated if PFS is not used and PFS is not flexible. For example, if the information obtainable through this AP requires less security, such as on a public network, it is perfectly fine for the device to connect to the AP without using PFS. However, there are times when the device must always use PFS for APs that provide access to private or corporate networks.

[0050] Another issue with this seemingly simple option is that setting up a device or AP currently requires the user to perform two separate actions. The first action is that the user must configure the device or AP using the DPP configurator, and the second action is that the user must configure the device or AP to always use PFS by following the device or AP setup procedure.

[0051] A solution is described here that makes setting up PFS easier for the user than the obviously simpler solution described above, and that makes using PFS more flexible than the simpler option described above.

[0052] The configurator is the central device in the DPP that configures the network. The configurator is also used to securely control whether PFS must be used for the network, thus preventing downgrade attacks against PFS use and simplifying the setup of PFS use for users, a technique that both devices must employ. If PFS must be used for a particular network, the configurator inserts a grading indicator—information indicating that PFS must be used—in every connector generated by the configurator for this network, and therefore for both devices and APs. This information can be in the form of a minimum version number that will be used, for example, {…,”minVersion:3”,…}, or in the form of a more detailed instruction, for example, {…,”usePFS”:true,…}. Devices using a connector in a peer discovery frame containing information for using PFS will refuse to connect to a device that receives a connector that does not specify that PFS must be used.

[0053] Therefore, even if MitM changes the version information of the peer discovery frame, MitM cannot change the information in the connector that instructs the device to use PFS, because the connector is protected by signature integrity and matching will fail if the connector has been changed.

[0054] For networks that do not require the use of PFS, the configurator can insert information that PFS is not required by inserting, for example, {…,usePFS”:false,…} into all connectors generated for that network, or the configurator can choose not to insert information about the use of PFS into all connectors by, for example, using DPP Release 1 or DPP Release 2 with the protocol version attribute value in the peer discovery frame appropriately set, thereby leaving it up to the device and AP itself to decide whether or not to use PFS.

[0055] Optionally, the configurator configures a device that supports a specific minimum version of a specification, such as version 3, by specifying a connector that, while PFS is used for backward compatibility, allows connection to devices supporting versions lower than the minimum without using PFS, and therefore only connects to other devices supporting a minimum version or later. For example, the configurator specifies this using {…,mustUsePFSIfVersionAtLeast”:3,…} in the connector, and a device configured with such a DPP connector will connect to devices with connectors that have no indication of whether PFS must be used, and therefore to devices conforming to, for example, DPP Release 1[DPP] or Release 2[WFEC_2], without strongly requiring the use of PFS. This is because DPP Release 1[DPP] or Release 2[WFEC_2] connectors do not include PFS information regarding version or usage. Note that {…,XYZ,…} means that ",XYZ" is inserted into the JSON code of the DPP connector.

[0056] It should be noted that the DPP Enroller and DPP Configurator can securely communicate to other devices the highest version of DPP supported by the DPP Enroller and DPP Configurator in the DPP Authentication Request and DPP Authentication Response messages, respectively, because the attributes used for version information are protected for consistency in both the DPP Authentication Request and DPP Authentication Response messages. The highest supported version should not be confused with the minimum required version, as indicated by the grading metrics. It should be further noted that in DPP Release 2 [WFEC_2], it is mandatory for devices or APs to support PFS. Therefore, the configurator is confident in the DPP version supported by the DPP Enroller, and thus confident in whether the Enroller supports PFS, and thus confident in whether the Enroller can include information that PFS must be used in the Enroller connector.

[0057] Further embodiments relate to the negotiation of device tracking prevention, in which a security protocol at a first security level does not prevent tracking of the first device across multiple communication sessions in the network based on recurring data in the first device's messages, and a security protocol at a second security level requires the recurring data to be avoided or modified in order to prevent tracking. In the device, the processor is configured to apply the tracking prevention when instructed to do so by a grading index.

[0058] Optionally, the security protocol is based on the device provisioning protocol for configuring Wi-Fi devices, as defined in [DPP]. Connector messages are reconfiguration connectors based on connectors generated for use in reconfiguration authentication request messages, as defined in the device provisioning protocol. The configurator is configured to insert grading metrics into the reconfiguration connector, which indicate blocking constraints that indicate device tracking blocking should be used by the device to be reconfigured.

[0059] In the device, the processor is positioned to extract blocking constraints from the reconfiguration connector and to apply tracking blocking during reconfiguration based on the blocking constraints. In a practical example, based on the configurator's grading indicators to the enloader, which the configurator instructs the enloader to support tracking blocking, the enloader can use tracking blocking for the NAK of the enloader's connector that the enloader sends to the configurator in the DPP reconfiguration response message. The blocking constraints are, As part of the C-Connector of the Enrollee in the DPP Reconfiguration Request Message, In the connector sent to the enroller by the configurator during configuration, and therefore in the DPP configuration response message, Not in any connector in this message, but as part of the DPP configuration response message, It will be sent. Please note that the grading criteria will be protected in consistency in each of these three cases.

[0060] It should be noted that the aforementioned "grading indicator indicating the minimum security level required" means, in addition to what has already been described, that devices that do not support the minimum security level may use a lower level, but only under further constraints, for example, for backward compatibility or to enable support for low-cost devices. For example, upon receiving a grading indicator and learning that the minimum security level is not supported, an additional request is first securely exchanged, in which the older or low-cost device requests the use of a lower level. Alternatively, an additional parameter indicating a lower acceptable level for, for example, backward-compatible devices, may also be part of the grading indicator. Nevertheless, if a device supports the minimum security level, the device must use at least this minimum level.

[0061] In practical examples, devices using DPP Release 1 [DPP] and Release 2 [WFEC_2] send their device connector to the AP in plain text within a DPP peer discovery request frame, and the AP sends its connector to Wi-Fi devices in plain text within a DPP peer discovery response frame. Since the device or AP connector contains the device's (certain) public key NAK, the device or AP can be tracked by any Wi-Fi device within the RF range. The public NAK can function as the device's identity. This violates the device's privacy and is therefore problematic.

[0062] One of the extensions in DPP Release 2 [WFEC_2] is the DPP Reconfiguration Authentication Protocol. A device configured by a DPP configurator has successfully connected to the network it is configured for, but may later encounter problems when connecting to an AP using the device's connector. These problems may include, for example, the device's connector expiring, or the first device and / or AP being moved, resulting in them accidentally being out of each other's RF range. When a device experiences connectivity problems with an AP, it uses the DPP Reconfiguration Authentication Protocol (see [WFEC_2]) to instruct the configurator to reconfigure the device. A device reconfigured using this protocol is called an enrollee in the DPP Release 2 specification [WFEC_2].

[0063] Devices using DPP Release 2 [WFEC_2] send the device's connector in plain text to the configurator in the DPP Reconfiguration Authentication Response message. The connector in this message is the same connector that the device uses in the DPP Peer Discovery Request frame to gain access to the AP. Therefore, the device may also be tracked by other devices that capture the device's DPP Reconfiguration Authentication Response message or DPP Peer Discovery Request frame.

[0064] The configurator under DPP Release 2 [WFEC_2] sends the configurator connector to the enrollee in plain text within the DPP reconfiguration authentication request message. However, the configurator connector's NAK is transient; that is, the NAK is randomly generated for sending only once, and therefore, there is no possibility of the configurator being tracked through these messages.

[0065] As explained above, preventing devices and APs from being tracked is not supported by DPP Release 2 [WFEC_2]. Nevertheless, information-based device tracking in the DPP Reconfiguration Authentication Protocol can be prevented by privacy protection measures, such as encrypting the connector's NAK, as described in [2018PF00508]. Additionally, the use of privacy protection measures must be negotiated between the device and the AP.

[0066] Negotiating to prevent information-based device tracking in DPP peer discovery requests and result messages is not supported in DPP Release 2 [WFEC_2]. A simpler option similar to negotiating the use of PFS as described above is to use the protocol version attribute in DPP peer discovery requests and / or response frames. However, these are not integrity-protected, and MitM can carry out downgrade attacks by modifying or removing the protocol version attribute.

[0067] Negotiating information-based device tracking prevention in DPP reconfiguration authentication messages is not supported in DPP Release 2 [WFEC_2]. A simpler option is for the configurator to add an attribute to the DPP reconfiguration authentication request message that signals to the device, i.e., the enrollee, that the configurator wants to be reconfigured and that the configurator supports device tracking prevention. This allows the device to hide its device connector's NAK in the device's reply to the configurator, i.e., the DPP reconfiguration authentication response message. However, the DPP reconfiguration authentication request message still provides no integrity protection (there is no shared key established in the protocol at this point to enable integrity protection), and MitM can, in principle, remove this attribute and thus carry out a downgrade attack.

[0068] The following solution prevents downgrade attacks against negotiations for the use of device tracking blocking in DPP reconfiguration authentication response messages and DPP peer discovery response frames.

[0069] The configurator securely controls the use of device tracking blocking in DPP, similar to the control over the use of PFS described above. In contrast to PFS, device tracking blocking is a technique used by either or both devices. For example, an AP may or may not be stationary. The location of a stationary AP is known and does not change. Therefore, it is acceptable for a stationary AP not to use device tracking blocking for its own connector in the DPP peer discovery response frame, but a stationary AP supports devices that apply device tracking blocking to the device's connector in the DPP peer discovery request frame that the device sends to the AP. Nevertheless, many smartphones have the ability to function as hotspots, meaning many smartphones can function as mobile Wi-Fi APs, and through this mobile Wi-Fi AP, Wi-Fi devices associated with this mobile AP can access the internet through the smartphone's mobile internet subscription. In contrast to stationary APs, it makes sense to use device tracking blocking for hotspots in mobile phones, or in mobile Wi-Fi hotspots other than smartphones.

[0070] The AP signals to devices that wish to associate with the AP, for example, in a DPP peer discovery request frame, with a grading message indicating whether the device is capable of using device tracking block for the AP's connector or if it should use it. However, since the device has not yet received the AP's connector, there is no integrity protection at this point in the protocol. An unprotected method for detecting whether device tracking block should be used on the connector is described in [2018PF00508].

[0071] This document describes a solution for devices wishing to associate with an AP to securely inform the AP that device tracking prevention is available on its connector. After the AP receives the device connector in the previous DPP peer discovery request frame, the AP sends a DPP peer discovery response frame to the device. The configurator then inserts a grading metric into any connectors it generates for this device. The grading metric indicates that device tracking prevention is available or must be used by the AP within the DPP peer discovery response frame. This information can be in the form of a generic instruction, such as a version number, e.g., {…,version”:3,…}, or in the form of a more detailed instruction, e.g., {…,mayUseTrackingPrevention”:true,…} or {…,hasToUseTrackingPrevention”:true,…}. Note that in {…,XYZ,…}, ",XYZ" means that it is inserted into the JSON code of the DPP connector. If a device sends such a connector to the AP in a DPP peer discovery request frame, and the device itself also uses device tracking prevention by encrypting the NAK of the device's connector, for example, in the manner described in [2018PF00508], then before the AP can verify the signature of the received connector, and after a successful signature verification has been securely determined, regardless of whether device tracking prevention can or must be used, the AP must first restore the received connector as described in [2018PF00508].

[0072] Devices under DPP Release 2 [WFEC_2] (DPP Enloaders) send the device's connector in plain text to the configurator in the DPP Reconfiguration Authentication Response message. The connector in this message is the same connector that the device uses in the DPP Peer Discovery Request frame to gain access to the AP. Therefore, the device may be tracked by other devices that capture the device's DPP Peer Discovery Request frame.

[0073] In one embodiment, when the DPP configurator sends a DPP reconfiguration authentication request message to a device (DPP enloader) that wishes to be reconfigured, it uses a grading index in the connector to securely inform the enloader whether or not it can use device tracking prevention when the enloader replies with a DPP reconfiguration authentication response message. Thus, the configurator inserts a grading index into the configurator connector that it generates for use in its DPP reconfiguration authentication request message. The grading index indicates that device tracking prevention is enabled by the enloader that wishes to be reconfigured. This information can be in the form of a generic instruction, such as a version number, e.g., {…,”version”:3,…}, or in the form of a more detailed instruction, e.g., {…,”mayUseTrackingPrevention”:true,…} or {…,”useTrackingPrevention”:true,…}. If Enlorie supports device tracking prevention, and Enlorie sees information in the DPP configurator connector indicating that Enlorie can use device tracking prevention, Enlorie will use device tracking prevention by encrypting the NAK of Enlorie's connector, for example, as described in [2018PF00508].

[0074] In further embodiments, the security protocol includes a setup protocol that performs the following actions: First, a certificate is obtained from a certificate authority. Then, security parameters that use the certificate are provided, for example, generated and encrypted or integrity-protected based on the certificate, using a generated key or a security algorithm indicated in the certificate. The security parameters are then transported to the device via a setup message. The certificate includes a grading index, which indicates constraints on the security parameters. For example, the certificate is provided by the certificate server based on a certificate request message from the device to be configured or from a configurator. The request includes a request to include a grading index, or an instruction for parameters or settings that will be protected via the grading index.

[0075] The device processor of a device configured to apply the above security protocol is configured to extract a grading index from the certificate. The processor is then configured to receive and / or transmit a setup message. The processor is also configured to determine the security level based on the setup message and the constraints of the security parameters. Optionally, the security protocol sets up cryptographic security parameters. Cryptographic security parameters include one or more of the cryptographic algorithm to be used, the key size to be used, the cryptographic hash algorithm to be used, or further options or parameters of the security protocol or cryptographic process to be used.

[0076] An example of the above negotiation or setup of cryptographic parameters is Transport Layer Security (TLS). Many cryptographic protocols, one of which is TLS 1.3 [RFC 8446], have incorporated flexibility in the use of cryptographic primitives, such as the cryptographic algorithm to be used, the key size to be used, the cryptographic hash algorithm to be used, or the variant of the protocol to be used, whether or not Perfect Forward Secrecy (PFS) is used. TLS 1.3 [RFC 8446] is described in more detail below to illustrate how the above enhancements are used. Their use in other cryptographic protocols can be easily derived from this description.

[0077] In the TLS negotiation phase, the first message sent by the client is a ClientHello message specifying the best TLS protocol version the client supports, a random number, a list of proposed cryptographic suites, and a compression method. The server's reply to the ClientHello message is a ServerHello message, specifically containing the selected cryptographic suite. The ClientHello and ServerHello messages are not initially integrity protected. However, once a shared key is successfully established between the client and the server using one of three possible modes—(EC)DHE (Diffie-Hellman on finite fields or elliptic curves), pre-shared key (PSK) only, or PSK with (EC)DHE—the TLS setup is completed when the server sends a “completed” message to the client, which includes the ClientHello and ServerHello messages, and thus contains a keyed hash across the entire setup exchange, based on the key derived from the shared key just established. Subsequently, the client sends its own "completed" message to the server, which also contains a keyed hash across the entire setup exchange, and therefore includes the ClientHello and ServerHello messages. The keyed hash function is a hash function that produces a hash based on the input of the keyed hash function, and the hash value is also based on the value of the (secret) key. Thus, the ClientHello and / or ServerHello messages are later protected for integrity in the TLS protocol.

[0078] TLS has many variations, and there are several options for TLS cryptographic parameters. Hackers can modify the TLS setup on a TLS server or client. The TLS server or client setup can also be accidentally or intentionally changed from its originally intended setup by any administrator of the TLS server or client. For example, the "Internet Options" menu in the Internet Explorer browser gives the user the option to allow or disallow the use of specific TLS versions.

[0079] Therefore, the setup of the communication negotiation protocol requires protection from downgrade attacks. The above configuration parameters can also be changed, for example, accidentally, by the server administrator. These configuration parameters can also be deliberately changed by a hacker or malicious insider. The above enhancements make the TLS setup more secure for TLS server or client administrators. This also applies to other protocols where the messages used to negotiate parameter values ​​are not integrity protected.

[0080] When setting up a server for TLS, the initial administrator must obtain a certificate from a Certificate Authority (CA). Once created, the certificate cannot be changed accidentally or intentionally, as TLS clients will no longer accept it. In addition to obtaining the certificate, the administrator (and possibly other administrators) must set up the use of TLS. Such an administrator must set up, for example, the following: • Authenticated Encryption with Associated Data (AEAD) algorithms / HMAC-based Extract-and-Expand Key Derivation Function (HKDF) hash pairs that the server is permitted to use. • The server is permitted to use the (EC)DHE group. • The signature algorithms that the server is permitted to use, and • The minimum version of TLS that the certificate-owning device is permitted to use.

[0081] It should be noted that the minimum version of the TLS protocol permitted for use is functionally different from the TLS version of the certificate itself. For example, a TLS certificate may have grading metrics formatted according to TLS V1.4, but the grading metrics in this TLS V1.4 certificate may indicate, for example, that only TLS versions from TLS V1.4 onwards are permitted, or that TLS V1.2 or later must be used.

[0082] When requesting a server certificate from a certificate authority, the initial administrator includes dedicated grading data in the request to request that the certificate include grading metrics that specify, for example, constraints, security options, the aforementioned acceptable or unacceptable values, or other TLS configuration parameters.

[0083] The current syntax for certificates is specified in X509 v3 [RFC5280] using Abstract Syntax Notation One (ASN.1) [X.680] as the specification language. Certificates use Object Identifiers (OIDs) as indicators for many things. For example, the OID used to indicate an organizationName is 2.5.4.10, while the OID for indicating RSA encryption, i.e., a specific asymmetric encryption algorithm, is 1.2.840.113549.1.1.1. OIDs for indicating specific extensions in the certificate's "extensions" components begin with 2.5.29, and the OID for indicating the basic constraint extension in section 4.2.1.9 of X509 v3 [RFC5280] is 2.5.29.19.

[0084] The possible values ​​for TLS parameters are indicated in a TLS message by numbers specified in TLS1.3 [RFC8446], for example, the hexadecimal value (0x0403) indicates a signature algorithm called the "Elliptic Curve Digital Signature Algorithm" (see [FIPS186-4]) using Elliptic Curve P-256 (see [FIPS186-4]) and SHA256 (see [FIPS180-4]) as hash algorithms.

[0085] Therefore, in order to strengthen the certificate as proposed, X509 can be extended with an extension called "allowedTLSParameters", indicated by a new OID2.5.29.19.x with x, the appropriate value of which is obtained from the organization that maintains this area of ​​the OID tree, and this new extension contains an array of allowed TLS parameters, indicated by values ​​such as those specified in TLS1.3 [RFC8446]. As an example, the type to be used for this new extension is expressed in ASN.1 as follows: AllowedTLSParameters::=SEQUENCE{allowedTLSParameter integer}

[0086] The ASN.1 for encoding an instantiation of type "AllowedTLSParameters" is stored in a component called "extnValue" in the "extension" component of type "TBSCertificate" (see section A.1 of X509 v3 [RFC5280]).

[0087] Instead of the hexadecimal values ​​specified in TLS1.3 [RFC8446], the new extension uses object identifiers (OIDs) to also indicate the acceptable values ​​for parameters. The advantage of using OIDs is that any protocol can use OIDs to indicate cryptographic parameters, whereas the hexadecimal values ​​specified in TLS1.3 [RFC8446] can only be used to indicate this for the TLS protocol. As an example, the types that will be used for this new extension using OIDs are expressed in ASN.1 as follows: AllowedTLSParameters ::= Set of AllowedTLSParameters AllowedTLSParameter ::= SEQUENCE { allowedTLSParameterType object identifier, allowedTLSParameterValues ​​AllowedTLSParameterValues ​​option -- allowTLSParameterValues ​​is required when the object identifier alone is insufficient. } AllowedTLSParameterValues::= Set of AllowedTLSParameterValues AllowedTLSParameterValue ::= integer

[0088] The above type AllowedTLSParameterValues ​​is merely an example. Other non-integer information may be included, for example, an object identifier specifying a cryptographic algorithm, or a type / value pair similar to the AllowedTLSParameter type.

[0089] One of the possible OIDs for the component allowedTLSParameterType is an OID that indicates the minimum allowed version number of the TLS protocol that must be used when using this certificate with TLS. In this case, the component allowedTLSParameterValues ​​is a set containing one integer component with a value of 11, for example, representing TLS version 1.1.

[0090] When a strengthened TLS server sends a certificate, or when a TLS client receives a certificate containing information about the permissible TLS parameters to be used, and the TLS parameters to be negotiated are not mentioned in the permissible TLS parameter list within the certificate, the server or client must abort the setup of the TLS protocol. Thus, the grading index indicates such a list, but also includes structures such as algorithms for which the use of X is permitted if the algorithm version number is Y or greater, or the algorithm quality is Y or greater, for example, if an ECC curve with a peak length of 256 bits or more is used. The grading index also indicates a blacklist, i.e., a list of TLS parameters that are not permitted to be used. The blacklist also includes structures such as algorithms for which the use of X is not permitted if the algorithm version number is Y or less, or the algorithm quality is Y or less, for example, if an ECC curve with a peak length of 255 bits or less is not used.

[0091] A TLS client may also have a certificate that the TLS server can use to authenticate the TLS client, and which is used in the TLS setup and for deriving the session key. Similar to the TLS server certificate described above, the TLS client certificate may also include allowed or unallowed values, or minimum allowed values, for TLS parameters.

[0092] Therefore, when using grading indicators for TLS, the administrator of a TLS server or client can request a certificate for the TLS client or server that indicates the acceptable or unacceptable values, or the minimum acceptable values, for TLS parameters. Such a TLS client or server will only use the TLS parameter values ​​that are acceptable according to the certificate. Changing the configuration of a TLS client or server will not result in the TLS client or server using unacceptable values, and therefore the setup of the TLS server or client becomes more secure for its administrator.

[0093] In further embodiments, the negotiation of cryptographic parameters for wireless access to a network using certificates is described using WPA-Enterprise as a detailed example. WPA (Wi-Fi Protected Access) is a specification for Wi-Fi wireless network security. The Wi-Fi Alliance (WFA) maintains the WPA specification and certification program for the WFA. WPA comes in two types: WPA-PSK (Pre-Shared Key), or WPA-Personal and WPA-Enterprise. There are three main releases of WPA, namely WPA, WPA2, and WPA3 [WPA3], each of which supports two types.

[0094] WPA-PSK requires each Wi-Fi device (and APs) to have the PSK (Pre-Shared Key) of the network it will connect to. The PSK is typically the same for all users on a given network. In contrast, WPA-Enterprise requires a RADIUS server to handle the task of authenticating network user access. The actual authentication process is specified in [802.1x] and, based on the 802.1x policy, can take the form of several different systems labeled EAP (Extensible Authentication Protocol). Because each device is authenticated before connecting, a personal, encrypted tunnel is effectively created between the device and the network.

[0095] A WPA-Enterprise AP only allows unauthorized Wi-Fi devices to communicate with a RADIUS server. Once the RADIUS server authenticates a device, only the authenticated device and AP can establish a PMK (Master Key for Pair) for Wi-Fi security between them, and the PMK is based on information exchanged with the RADIUS server during the authentication process.

[0096] Several EAP protocols can be used by RADIUS servers, and among these protocols, EAP-TLS [RFC5216] and EAP-TLS / PAP [RFC5281] are certificate-based EAP versions.

[0097] EAP-TLS requires all Wi-Fi devices to have a certificate for network access, but a server certificate for (RADIUS) server authentication is optional. This is the opposite of EAP-TLS / PAP, where a server certificate is mandatory and a client certificate is optional.

[0098] The difference between WPA3-Enterprise and WPA2-Enterprise is that WPA3-Enterprise requires server certificate authorization to be configured to verify the identity of the server to which the device is connected.

[0099] In this explanation, WPA-Enterprise refers to WPA-Enterprise, WPA2-Enterprise, WPA3-Enterprise, or any of its future successors.

[0100] Similar to the embodiments described above, the entity requesting a certificate for use with WPA-Enterprise is different from the entity forming the AP or Wi-Fi device for use with WPA-Enterprise. The proposed enhancement makes the WPA-Enterprise setup more secure for TLS server or client administrators.

[0101] Security negotiation for the Wi-Fi connection between a Wi-Fi device and an AP is performed using the Robust Security Network element (RSNE, section 9.4.2.25 of [802.11]) in messages exchanged between the Wi-Fi device and the AP before the device can associate with the AP, and therefore, for example, in probe requests sent by the device, and probe responses and beacons sent by the AP. The RSNE includes a pair of cryptographic suite lists and an AKM (authentication and key management) suite list. The pair of cryptographic suite lists the cryptographics supported by the device, as indicated by the cryptographic suite selector; for example, the cryptographic suite selector 00-0F-AC:4 indicates the CCMP-128 algorithm. The AKM suite list lists the AKMs supported by the device, as indicated by the AKM suite selector. AKM is a protocol for authenticating devices and / or APs. For example, the AKM Suite Selector 00-0F-AC:1 indicates authentication negotiated via IEEE Std802.1X, which means authentication using a RADIUS server.

[0102] Probe requests, probe responses, and beacons are not integrity-protected and can be modified by a MitM attacker. Nevertheless, a device can never use a protocol or algorithm it does not support. A device also cannot successfully complete a protocol for which it does not possess the requested information. For example, a device that does not know its passphrase cannot use WPA-Personal to associate with an AP. Similarly, other security processes such as EAP-TLS and EAP-TLS / PAP also involve some negotiation.

[0103] After a device, server, or AP is provided with an initial certificate, several options remain for security setup, which can be modified by an attacker or careless administrator. For example, a device set up for EAP-TLS must have a certificate. However, it is still optional for the RADIUS server in this case to also have a certificate for server authentication. This means the device is originally set up to only accept the RADIUS server when the RADIUS server is capable of engaging in server-side authentication. Other careless administrators or hackers can change this later, thereby lowering the level of security. By using the above strengthening regarding grading metrics, the original administrator can request a device certificate that includes a constraint that server-side authentication using the server certificate must always be used. The device then refuses to authenticate a RADIUS server that does not perform server-side authentication, even if a careless administrator or hacker later changes the device setup to no longer require this. Another constraint that can be added to the certificate is the size of the PMK to be used after authentication. For example, the constraint is that the PMK to be used must be greater than 128 bits. The constraints can be included in the certificate through grading metrics, for example, as discussed in the previous embodiment.

[0104] In a further embodiment, the first device is a client device, the second device is a server device, and the grading metric indicates a client constraint that requires client-side authentication using a certificate. The client device's processor is configured to extract the client constraint from the certificate. The processor is then configured to receive a setup message and apply client-side authentication based on the client constraint. In a practical example, an AP set up for EAP-TTLS / PAP, as well as a device set up for EAP-TLS, must have a certificate. Client-side authentication is still optional. An administrator requesting a certificate for an AP uses the present invention to request a certificate with the constraint that client-side authentication using the certificate is always required. The AP will then always refuse to successfully complete EAP-TTLS / PAP on a device that is not capable of presenting a certificate during this protocol, even if an unscrupulous administrator or hacker later modifies the AP's setup so that it does not require a client certificate.

[0105] Therefore, the above enhancements make WPA-Enterprise setups on devices and APs using EAP-TLS or EAP-TTLS / PAP more secure and provide protection against MitM attackers who modify security negotiation messages.

[0106] The embodiments described above have been explained using devices. Nevertheless, various protocols, messages, and processor actions are performed by corresponding method steps which can be readily derived from the above description. The method is performed, for example, by circuit equipment and software in a processor or Wi-Fi controller. Appropriate encryption and decryption functions have been described above. As will be apparent to those skilled in the art, many different ways of performing the method are possible. For example, the order of stages or steps can be changed, or some stages may be performed in parallel. Furthermore, steps of other methods may be inserted between steps. The inserted steps may represent improvements to the method as described herein, or they may be independent of the method.

[0107] A computer program product is provided, downloadable from a network and / or stored on computer-readable media and / or microprocessor-executable media, comprising program code instructions for performing the above-described methods, connection sequences, security processes, and further actions when executed on a computer device. Accordingly, the methods according to the present invention are performed using software comprising instructions for causing a processor system to implement each of the methods.

[0108] Figure 2a shows a computer-readable medium 1000 having a writable portion 1010 containing a computer program 1020, the computer program 1020 comprising instructions for causing a processor system to perform one or more of the above methods in a system such as that described with reference to Figure 1. The computer program 1020 is embodied on the computer-readable medium 1000 as a physical mark or by magnetization of the computer-readable medium 1000. Nevertheless, any other suitable embodiment can be similarly conceivable. Furthermore, although the computer-readable medium 1000 is shown here as an optical disc, it will be understood that the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state memory, or flash memory, and may be non-rewritable or writable. The computer program 1020 comprises instructions for causing a processor system to perform the above methods.

[0109] Typically, a device performing the above process comprises a processor coupled to memory containing appropriate software code stored in the device, for example, downloaded and / or stored in corresponding memory such as volatile memory like RAM or non-volatile memory like flash (not shown). The device may be equipped with, for example, a microprocessor and memory (not shown). Alternatively, the device may be implemented in programmable logic, either entirely or partially, as a field-programmable gate array (FPGA). The device and server may be implemented entirely or partially as a so-called application-specific integrated circuit (ASIC), i.e., an integrated circuit (IC) customized for a specific application of the device and server. For example, the circuit may be implemented in CMOS using a hardware description language such as Verilog or VHDL.

[0110] Figure 2b is a schematic diagram of a processor system 1100 according to an embodiment of a device or server as described with reference to Figure 1. The processor system is embodied by one or more circuits 1110, each comprising one or more integrated circuits. Circuit 1110 includes a processing unit 1120, such as a CPU, for running computer program components for performing the method according to the embodiment and / or for implementing the module or unit thereof. Circuit 1110 includes a memory 1122 for storing program code, data, etc. Part of the memory 1122 is read-only. Circuit 1110 includes a communication element 1126, such as a transceiver having an antenna, a connector, or both and similar. Circuit 1110 includes a dedicated integrated circuit 1124 for performing some or all of the processing defined in this method. The processor 1120, memory 1122, dedicated IC 1124, and communication element 1126 are connected to each other via an interconnection 1130, such as a bus. The processor system 1110 is arranged to perform contact and / or contactless communication using antennas and / or connectors, respectively.

[0111] The software includes only steps performed by specific sub-entities of the system. The software is stored on a suitable storage medium, such as a hard disk, floppy disk, or memory. The software is transmitted as a signal along a wire, wirelessly, or using a data network, such as the internet. The software is made available for download and / or for remote use on a server. The method according to the present invention is executed using a bitstream arranged to constitute programmable logic, such as a field-programmable gate array (FPGA), to carry out the method. The software will be understood to be in the form of source code, object code, code intermediate source and object code such as a partially compiled form, or any other form suitable for use in an implementation of the method according to the present invention. Embodiments relating to a computer program product comprise computer executable instructions corresponding to each of at least one processing step of the described method. These instructions are subdivided into subroutines and / or stored in one or more statically or dynamically linked files. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of at least one means of the described system and / or product.

[0112] For clarity, it will be understood that the above description illustrates embodiments of the invention with reference to different functional units and processors. Nevertheless, it will be clear that any appropriate distribution of functions between different functional units or processors can be used without departing from the invention. For example, a function indicated to be performed by a separate unit, processor, or controller may be performed by the same processor or controller. Thus, references to specific functional units are not intended to dictate a strict logical or physical structure or organization, but merely to be considered references to appropriate means for providing the described functionality. The invention can be implemented in any appropriate form, including hardware, software, firmware, or any combination thereof.

[0113] In this document, the word “equipped with” does not exclude the existence of elements or steps other than those listed, a singular element does not exclude the existence of multiple such elements, any reference numeral does not limit the scope of the claims, the invention is performed by both hardware and software, and some “means” or “units” are represented by the same item in hardware or software, and a processor, in some cases in cooperation with hardware elements, performs the function of one or more units. Furthermore, the invention is not limited to embodiments, and the invention lies in each and every novel feature, or in any combination of features enumerated in the above or mutually different dependent claims.

[0114] In summary, this application relates to a device and method for establishing secure communication between a first device and a second device via a physical channel using a security protocol. The protocol establishes first integrity data at the first device and second integrity data at the second device. The protocol has at least two security levels. The applicable security level is selectable based on grading information transported via the physical channel. Advantageously, a grading index indicating a minimum security level, such as the minimum required at least one of the first and second devices, is transported via the physical channel, while integrity protection of the grading index is provided based on the integrity data. This prevents man-in-the-middle attacks that could downgrade the security level.

Claims

1. A method for establishing a security level for communication between a first device and a second device via a physical channel using a security protocol, wherein the security protocol is Establishing first consistency data in the first device and second consistency data in the second device, At least two security levels, wherein the security levels are selectable based on grading information transported over the physical channel, and the security protocol under the first security level does not prevent tracking of the first device across multiple communication sessions in the network based on recurring data in the messages of the first device. Provided, The security protocol at the second security level requires avoiding or modifying the repeated data in order to prevent tracking. The method described above is The steps include transporting a grading index indicating the minimum security level required by at least one of the first and second devices via the physical channel, A step of providing integrity protection for the grading index based on the integrity data, When tracking prevention is instructed by the aforementioned grading indicator, the steps include applying the tracking prevention and A method having.

2. A device wherein the first device is adapted to establish a security level for communication between a first device and a second device via a physical channel by a security protocol, and the security protocol is Establishing first consistency data in the first device and second consistency data in the second device, At least two security levels, wherein the security levels are selectable based on grading information transported over the physical channel, and the security protocol under the first security level does not prevent tracking of the first device across multiple communication sessions in the network based on recurring data in the messages of the first device. Provided, The security protocol at the second security level requires avoiding or modifying the repeated data in order to prevent tracking. The aforementioned device Sending or receiving a grading index via the physical channel that indicates the minimum security level required by at least one of the first device and the second device, When sending, include the protection data for the grading index based on the integrity data, Upon receipt, the protection data is verified based on the integrity data, Applying at least the minimum security level for the communication between the first device and the second device, When tracking prevention is instructed by the aforementioned grading indicator, the aforementioned tracking prevention shall be applied. A device equipped with a processor that performs the following task.

3. The security protocol is based on a device provisioning protocol that further requires a configurator adapted to establish communication between the first device and the second device in a wireless network. The configurator, Inserting the aforementioned grading index into the connector message, Sending the aforementioned connector message to the first device Perform The processor of the first device, Receiving the aforementioned connector message, Extracting the grading index from the connector message and The device according to claim 2, which performs the following:

4. The security protocol at the first security level requires determining a pair of master keys on both the first and second devices based on private and public key materials, and the pair of master keys is used to determine a session key for encrypted communication between the first and second devices. The security protocol at the second security level requires determining the master key of the pair, which includes a transient Diffie-Hellman key pair. The device according to claim 3, wherein the processor applies the second security level when it is instructed to do so by the grading index.

5. The device according to any one of claims 2 to 4, wherein the security protocol lacks integrity protection for at least a portion of the grading information.

6. The aforementioned security protocol, Obtaining a certificate from a certification authority, To provide security parameters using the aforementioned certificate, Transferring the security parameters to the device via a setup message, It has a setup protocol that includes, The certificate includes the grading index, and the grading index indicates the constraints of the security parameters. The aforementioned processor, Extracting the grading index from the aforementioned certificate, Receiving the aforementioned setup message, Determining the security level based on the setup message and the constraints of the security parameters. The device according to claim 2, which performs the following:

7. The security protocol provides the setup of cryptographic security parameters, and the cryptographic security parameters are The cryptographic algorithm to be used, The size of the key you will be using, The cryptographic hash algorithm that will be used, The minimum version of the security protocol to be used, The security protocol options to be used as described above The device according to claim 6, comprising one or more of the above.

8. The first device is a client device, the second device is a server device, and the grading index indicates a client constraint that requires client-side authentication using a certificate. The aforementioned processor, Extracting the client constraints from the aforementioned certificate, Receiving the aforementioned setup message, Applying client-side authentication based on the aforementioned client constraints The device according to claim 6 or 7, which performs the following:

9. The security protocol is based on the device provisioning protocol for configuring a Wi-Fi device as defined in [DPP], and the connector message is based on a connector defined in the device provisioning protocol, modified by inserting the grading index. The device according to claim 3, wherein the processor receives the modified connector.

10. The security protocol is based on the device provisioning protocol for configuring a Wi-Fi device as defined in [DPP], and the connector message is a reconfiguration connector based on a connector generated for use in a reconfiguration authentication request message defined in the device provisioning protocol. The configurator inserts the grading index into the reconfiguration connector, and the grading index indicates a blocking constraint that indicates whether or should be used by the device to be reconfigured. The aforementioned processor, Extracting the blocking constraint from the modified connector, Apply tracking blocking during reconstruction based on the aforementioned blocking constraints. The device according to claim 9, which performs the following:

11. The device according to any one of claims 2 to 10, wherein the physical channel is a wireless communication channel.

12. The device according to any one of claims 2 to 11, wherein the integrity data is applied to provide integrity protection for messages transported over the physical channel.

13. A program that is downloadable from a network and / or stored on a computer-readable medium and / or a microprocessor-executable medium, wherein, when the program is executed on a computer, it comprises program code instructions for performing the method according to claim 1.

Images