Method and device for providing a level of security for communications - Patents.com

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 over a physical channel by means of a security protocol.

[0002] The present invention relates to the field of security in wireless or wired data communication, and more particularly to a device and a method applying a security protocol. 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 transported over a physical channel. The security protocol provides different security levels, each of which defines, for example, at least one specific security measure, cryptographic algorithm, security option or key length. [Background technology]

[0003] A device securely connects to a wireless network, for example according to the Device Provisioning Protocol (DPP, see [DPP]), to gain access to a Wi-Fi Access Point (AP). DPP is a protocol for configuring Wi-Fi devices using a DPP Configurator device. The device that wants to gain access is called a DPP Enrollee. When a device is configured with DPP, it receives a DPP Configuration Object from the DPP Configurator. The DPP Configuration Object contains a so-called Connector or DPP Connector. The Connector is signed by the DPP Configurator. The Connector contains a public key belonging to the device, a network access key, a netAccessKey, or a NAK. The NAK is present in the Connector in plain text. Other information, for example an expiry timestamp, is present in the Connector in plain text. Since DPP Configuration Objects are not signed, there is no integrity protection in DPP Configuration Objects. Nevertheless, the message sent to the DPP enrollee, the DPP configuration response message, is integrity protected by the symmetric key negotiated between the DPP configurator and the DPP enrollee in the previous DPP authentication protocol. It is noted that in this application, the acronym DPP refers to any version of DPP, for example, DPP R1, DPP R2, and any subsequent releases.

[0004] Given the growing number of connected devices, security is of growing concern, for example for privacy and protection against tracking by third parties. Tracking means following the location of a device across multiple communication sessions in a network, for example based on repeated data in the device's messages. Document WO2020043634A1[2018PF00508] describes an upgraded security protocol with added security options that provide protection against said tracking.

[0005] Thus, existing security protocols are upgraded with at least one enhanced security level. For interaction with existing devices, previous versions of such protocols are usually supported as well. The security level to be applied, e.g. the version or option of the security protocol to be used, is negotiated between devices during communication setup using grading information transported over the physical channel. Grading information is, for example, an explicit indication that a specific version of a protocol or security option is supported by the device. Grading information is also implicit by other protocol data, e.g. by including a key of a specific length if multiple key lengths are supported. By exchanging said grading information, the security level to be applied is determined. Nevertheless, such messages can be intercepted and modified by devices also operating on the physical channel, which is called a "man-in-the-middle" attack (MitM). By said manipulation of the grading information, a security level can be established lower than intended, which is called "downgrading" of the security level. Summary of the Invention

[0006] In order to mitigate at least one of the above mentioned security problems, it is an object of the present invention to provide a method and a device for protecting against downgrading of security level, e.g. via said MitM. To this end, a device and a method are provided as defined in the accompanying claims. According to one aspect of the present invention, a method for establishing a security level for communication between a first device and a second device over a physical channel according to a security protocol is provided as defined in claim 1. According to a further aspect of the present invention, a device and a method are provided as defined in the independent claims.

[0007] The security protocol provides for establishing first integrity data in the first device and second integrity data in the second device. The integrity data are applied to provide integrity protection for messages transported over the physical channel. For example, the first integrity data is a 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 a corresponding private key. The first integrity data is also a signature or certificate of a connector provided to the first device by a third party.

[0008] The security protocol provides at least two security levels, and the security level is selectable based on the grading information, e.g., 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 part of one or more protocol messages, explicit or implicit, or embodied in a separate message to be exchanged. Any message that includes explicit or implicit grading information is referred to as a grading message in this document. The grading message is transported via the physical channel. Thus, grading information refers to any data appropriate to establish one or more grades of security that devices can provide and to negotiate the grades to be used between devices for communication, privacy protection, integrity protection, authentication, network access, etc. For example, the grading information includes a version indication of the security protocol supported by the device. The unique version number indicates the range of security options to be selected by other devices as specified by this version of the protocol specification.

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

[0010] The grading information may be fully, partially, or not integrity protected at all. In contrast, the grading indicator is always fully integrity protected. Thus, the grading indicator helps to prevent MitM attacks on the non-integrity protected parts of the grading message from causing the negotiated security to fall below a certain level, or to maintain a certain minimum security in case of changing the server or client setup without requesting new certificates.

[0011] In effect, a device sends a grading indicator, and the device itself or the recipient then applies a minimum security level as indicated by the grading indicator. Also, when two devices cooperate, the two devices apply at least the level of security as indicated by the grading indicator. Moreover, when two devices exchange grading messages indicating that a higher security grade than that required by the grading indicator is supported by both, such a higher security level is also selected. Nevertheless, downgrading to a security level lower than that indicated by the grading indicator is blocked. Thus, if a grading message allows legacy communication with a lower grade of security supported by both sides of a communication link, such a link can now be blocked when the communication link applies a security level lower than that indicated by the grading indicator. Similarly, when a message containing a grading indicator is received and when verifying its integrity, a device can block or abort any communication having a security level lower than that indicated by the grading indicator.

[0012] Advantageously, said grading information indicates at least one security level that can be considered as a suggestion, while the grading indicator indicates constraints on the security level that is actually used: thus, in common language, "whatever is mentioned in the grading message, at least level X must be used" or "whatever is mentioned in the grading message, if level X is supported, at least level X must be used, but otherwise at least level Y must be used (level Y being less secure than level X).

[0013] Providing integrity protection covers both sender and receiver actions. For example, providing integrity protection of a grading indicator based on integrity data involves signing a grading indicator message by a device and checking the signature when the message is received. Providing integrity protection can also be the act of sending an object including the grading indicator by a first device, where the object (hence, for example, a connector) is further signed by a third device. The receiver side then verifies the signature using the respective key material for the third device. For example, this occurs during the negotiation of the use of PFS and tracking prevention during the network introduction protocol as described later.

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

[0015] Further preferred embodiments of the device and method according to the invention are set out in the attached dependent claims, the disclosure of which is incorporated herein by reference.

[0016] These and other aspects of the invention will be apparent and elucidated with further reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0017] [Figure 1] 1 is a diagram of a system in which the present invention may be practiced; [Figure 2a] FIG. 1 is an illustration of a computer readable medium. [Figure 2b] 1 is a schematic diagram of a processor system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] The figures are purely diagrammatic and are not drawn to scale. In the figures, elements corresponding to elements already described have the same reference numbers.

[0019] Fig. 1 shows a system 100 comprising a first device 110, a second device 120 and a third device 130. Each of these devices comprises a communication module 111, 121, 131, comprising a transmitter / receiver suitable for communication over a physical channel 160, such as Wi-Fi, Bluetooth or a wired network. The devices comprise an input / output unit for communicating over the wired physical channel and / or at least one antenna 113, 123, 133 serving as input / output for a wireless physical channel. Each of the devices operates under the control of a processor 112, 122, 132. The communication module, the processor and further elements of the devices are integrated in a single system on a chip. Each of the devices comprises a user interface 151, 152, 153, comprising at least one user control element. For example, the user control element comprises a touch screen, various buttons, a mouse or a touch pad, etc. The buttons are traditional physical buttons, touch sensors or for example virtual buttons on a touch screen or icons that are to be activated via a mouse. The 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 a device of the IoT (Internet of Things) type. The second device may correspond to a server, an access point, a router, a further portable device or an IoT device etc. The user of the first device is interested to be connected to the second device (access point) in order to access one or more resources provided through the second device. The third device, which is not part of the invention, in practice corresponds to a so-called man-in-the-middle, i.e. a device used by a malicious third party to intercept, modify or swap messages to and from the first device.

[0021] In this application, the word "certificate" is intended to denote a small chunk of data that contains at least the public key of the certificate's owner. An example of such a certificate as intended in this application is an X509 v3 [RFC5280] certificate. The owner is called the "subject" and the public key is called the "subject public key". Said small chunk is digitally signed by a Certificate Authority (CA) called the "issuer". Certificates are signed by a different entity (the "issuer") than the owner (the "subject") of the certificate's public key (the "subject public key"), except for so-called root certificates. Root certificates are signed by the owner himself, i.e. the elements "issuer name" and "subject name" are the same.

[0022] The public key to be used to verify the signature of a certificate can be found as the "subject public key" of another certificate, whose "subject name" is the same as the "issuer name" of the certificate to be verified. If this other certificate is a root certificate, then 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 was therefore issued by yet another issuer, issuer 2, then the signature of the root certificate can be checked 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 checking therefore involves checking the signatures of several certificates in this certificate tree, up to (and including) the so-called root certificate of the certificate tree.

[0023] A DPP Connector, like a certificate, is also a small chunk 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 chunk is digitally signed by the DPP Configurator, not by a CA. One difference between the latter two is that CAs are 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, but DPP Configurators are 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. When inspecting this root certificate using an appropriate tool, such as the website https: / / lapo.it / asn1js / , one sees, for example, that 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 certificates and connectors is how the device is configured with the public key to verify the signature. In the case of certificate signature verification, the public key to do this is provided in the form of the certificate itself, together with all the certificates of the certificate tree, up to and including the root certificate of the certificate tree. The certificate tree is installed on the device with a special and secure mechanism. This can be done, for example, at the time of manufacture. It can also be done, for example, by using a secure Internet connection. For example, Microsoft uses a dedicated secure connection between Windows devices and their servers to provide Windows devices with the latest certificate tree. The Firefox web browser uses its own dedicated secure channel between a Firefox installation and a server from Mozilla to provide Firefox installations with the latest certificate tree, even when running under a Windows operating system. The security required is not to keep the certificates secret, but to ensure that only valid certificate trees are provided. A device provided with a malicious root certificate, for example by a hacker, will start trusting websites that provide certificates signed with the public key of this root certificate. In contrast, the DPP configurator public key is not provided with the enrollee in the form of a certificate, but rather in a message that is (integrity) protected by a symmetric key. In the following, various examples of grading information in the DPP are discussed.

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

[0026] Enrollee->Configurator: SHA256(C-sign-key), Group, A-NONCE, E'-id The attribute "SHA256(C-sign-key)" indicates the configurator signing key. The configurator has multiple signing keys. They 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). This attribute therefore indicates the configurator signing algorithm and the signing algorithm security level, and therefore serves as grading information. The attribute "group" indicates the elliptic curve group of the enrollee's NAK. This attribute therefore indicates the algorithm to use to calculate the PMK, and this attribute indicates the security level of the PMK (more specifically here, the number of bits), and therefore also contributes to the grading information.

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

[0028] If the enrollee only supports one curve, for example the required NIST P-256 curve, then the device will only support this as the first level. The second security level is therefore P-256 and tracking prevention, which are indicated in the parameters or version indication. Thus, the tracking prevention feature 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 in the next two protocol messages. The attribute "Protocol Version" represents the DPP protocol version that the configurator supports. If different versions provide or prescribe 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 prevention, this attribute can be used to select an "upgraded security level", i.e., use tracking prevention during reconfiguration. Alternatively, in DPP R3, the value 3 (representing DPP Release 3) of the attribute "Protocol Version" specifies that the configurator supports the enrollee's use of tracking prevention for the enrollee connector's NAK in the next message. The attribute "Protocol Version" serves as grading information, and thus this message is considered to be a grading message, in which case the configurator indicates that the enrollee has two options: to use tracking prevention or not. The attribute "C-Connector" contains an indication of the configurator signing key, i.e., an identifier named "kid" in the connector's JSON Web Signature (JWS) protected 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 the one indicated by the enrollee with the attribute named "group". This attribute therefore indicates the configurator signing algorithm and the signing algorithm security level. This attribute also contains a NAK. This attribute should be on the same curve as the enrollee's NAK. This attribute therefore also indicates the algorithm to use 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" contains a grading indicator to indicate that the enrollee can or must use tracking prevention for the enrollee's NAK. When communicating with the configurator, a grading indicator indicating that the enrollee must use tracking prevention for the enrollee'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] A further example relates to a network introduction protocol: 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 and 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 an indication of the NAK of the non-AP device, whose information is considered as grading information. If the non-AP device supports only one curve, e.g. P-256, only one security level can be selected with this information. The attribute "ConnectorB" contains a grading indication to indicate that the AP can or must use tracking prevention for NAK of this connector, or must use PFS. The optional attribute "ProtocolVersion" indicates the version of the DPP protocol that the non-AP device supports. PFS is as defined in DPP R2. When DPP R2 is indicated in this attribute, the AP decides to use PFS or not. Therefore, this attribute also contributes to the grading information.

[0035] Note that if an enrollee wishes to use tracking prevention for NAKs on this connector, it must obtain information that the AP supports this feature in another manner, for example, from a further information element that the AP includes in its beacon or probe response indicating this. Such an element can be considered to be 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" contains the value DPP_STATUS_OK in this case. When this attribute has another value, the attributes "ConnectorA" and "Protocol_Version" are omitted. The functionality of the other attributes is the same as that described above for the DPP Peer Discovery Request message, but the device is replaced.

[0038] Specific embodiments of the present invention are described below in the context of the generic 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 the first device and the second device over a physical channel by a security protocol as described above. The device has a processor arranged to send or receive over the physical channel a grading indicator indicating a minimum security level as minimally required by at least one of the first device and the second device. When sending, the processor includes protection data of the grading indicator based on the integrity data. When receiving, the processor verifies the protection data based on the integrity data. The processor then applies at least the 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 further requiring a configurator adapted to establish communication between the first device and the second device in the wireless network. The configurator is configured to insert the grading indicator into a connector message and send the connector message to the first device. A processor of the first device is configured to receive the connector message and extract the grading indicator from the connector message.

[0041] Optionally, the security protocol according to the first security level requires determining a pairwise master key in both the first device and the second device based on the private key and the public key material, the pairwise master key being used to determine a session key for encrypted communications between the first device and the second device. Additionally, the security protocol according to the second security level requires determining a pairwise master key involving an ephemeral Diffie-Hellman key pair, the processor of the device being configured to apply the second security level when so directed by the grading indicator. As an example "involving an ephemeral Diffie-Hellman key pair," PFS is described below, where PFS provides an example of an upgraded security level.

[0042] Typically, in the above embodiment, at least one grading message has no integrity protection in the security protocol. Such messages are therefore susceptible to MitM attacks. Optionally, various parameters in such messages are protected by transporting said grading indicator at some point in the enhanced security protocol. The grading indicator provides constraints, limits or requirements on various elements that may be affected by manipulating said 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 clause 12.4 of [WPA3] or [802.11]). In each of the devices, the protocol according to the invention is executed in the module controller (113, 123), in the processor (114, 124), or by both cooperating during the execution of the protocol. An embodiment relates to negotiating the Perfect Forward Security (PFS) feature, which was added in version 2 of the DPP (see section 6.6.3 "Network Access Protocol" of [WFEC_2]). Thus, the grading message includes an indication of the version of the security protocol supported by the device. For example, the version indication embodies unprotected "grading information" that indicates that the device supports a particular security level, e.g., "V3", if the device is a V3 device, while V3 suggests that security options such as PFS are used.

[0044] When a device wants to connect to an AP using DPP, it sends its connectors to the AP in a so-called DPP Peer Discovery Request frame. This frame is not encrypted. This frame is also not integrity protected, which means that this frame can be modified by a man-in-the-middle (MitM) attacker. Note that since the connectors are integrity protected by a signature from the DPP configurator device, but all other attributes in the DPP Peer Discovery Request frame have no integrity protection, it is not possible for the connectors to be modified by a MitM without the recipient being aware of this modification.

[0045] An AP that receives a DPP Peer Discovery Request frame will check the connector in this frame. If the AP finds that the connector is legitimate, i.e., the signature is correct, the connector has not expired, and the connector is for a network that the AP serves, it 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 that receives a DPP Peer Discovery Response frame will check the AP connector in the same manner that the AP did. Once the device finds that the AP connector is correct and matches its own connector (see Section 6.4.2, "Connector Group Comparison," of [DPP]), it can use its own private NAK and the public NAK from the AP connector to compute a Pairwise Master Key (PMK) in Diffie-Hellman fashion (see [DH]) (see Section 6.4, "Network Adoption Protocol," of [DPP]). The AP can use its own private NAK and the public NAK on the device connector to compute the same value for the PMK. The PMK is the basis for computing a session key between the device and the AP, using the so-called four-way handshake (see [802.11]). After a successful four-way handshake, the device associates with the AP, and transmissions between the device and the AP are encrypted and integrity protected with a session key derived from the PMK and from the plaintext information sent during the four-way handshake.

[0046] In version 2 of DPP, now called Wi-Fi Easy Connect™ [WFEC_2], the DPP deployment protocol has been improved. 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 the device and the AP, and therefore the DPP network deployment protocol exchanges, the 4-way handshake to calculate the session key, and the encrypted exchanges after association. The hacker has obtained a public NAK from the other device of the other device's connection, which the connector sent in plaintext, so when the attacker hacks the device or the AP and obtains one of the private NAKs, the attacker can calculate the PMK between the device and the AP. Using the PMK and the nonce in the captured 4-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 the DPP. The calculation of the PMK now also involves an ephemeral Diffie-Hellman key pair (public / private ECC keys). Because the private key of the ephemeral Diffie-Hellman key pair must be deleted by the device after use, an attacker who hacks either of the two devices will not be able to obtain these ephemeral private keys and therefore will not be able to calculate the PMK used and will not be able to decrypt encrypted transmissions that previously occurred between the device and the AP.

[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 wishes to use PFS, it adds a Protocol Version attribute to its DPP Peer Discovery Request frame with a value of 2 or greater. When an AP receives a DPP Peer Discovery Request frame with a Protocol Version attribute with a value of 2 or greater, and if 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 greater. In this case, both devices will use PFS to calculate the PMK, as specified in Section 6.6.3, "Network Access Protocol" of [WFEC_2]. Since attributes other than the connector in the DPP Peer Discovery Request or Response frames are not integrity protected, a MitM attacker can modify either of the two Peer Discovery frames such that the Protocol Version attribute gets a value less than 2, or the Protocol Version attribute is removed entirely. If this is the case in either or both of the Peer Discovery frames, the device and the 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 in such a way that it never calculates the PMK if PFS is not used and PFS is not flexible. For example, if the information available through this AP, e.g. public networks, requires less high security, it is perfectly OK for the device to connect to the AP without using PFS. Nevertheless, for APs that provide access to private or corporate networks, the device may have to always use PFS.

[0050] Another problem with this apparently simple option is that a user currently must perform two separate actions to set up a device or AP: first, the user must configure the device or AP using the DPP configurator, and second, the user must go through the device or AP setup procedure to configure the device or AP to always use PFS.

[0051] A solution is now described that makes setting up a PFS easier for the user than the apparently simpler solutions above, and makes the use of the PFS more flexible than in the simpler options above.

[0052] The configurator is the central device in DPP that configures the network. The configurator is now used to control in a secure manner whether PFS must be used for a network, thus preventing downgrade attacks against the use of PFS and making it easy for users to set up the use of PFS, which is a technique that both devices must use. If PFS must be used for a particular network, the configurator inserts a grading indicator, i.e., information indicating that PFS must be used, in any connector it generates 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 at a minimum, e.g., {...,"minVersion:3",...}, or in the form of a more detailed instruction, e.g., {...,"usePFS":true,...}. Devices using connectors in peer discovery frames where the connector contains information to use PFS will refuse to connect to a device where they have received a connector that does not specify that PFS must be used.

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

[0054] For networks that do not require the use of PFS, the configurator can insert information that PFS does not need to be used, for example by inserting {...,"usePFS":false,...} into all connectors created for this network, or the configurator does not insert information about the use of PFS into all connectors, for example by using DPP Release 1 or DPP Release 2 with the protocol-version attribute value in peer discovery frames appropriately, thereby leaving it to the devices and APs themselves to decide whether or not to use PFS.

[0055] Optionally, the configurator may configure a device that supports a certain minimum version of the specification, e.g. version 3, with a connector that indicates that PFS is used for backward compatibility, but that the device may only connect to other devices that support this minimum version or higher if they are allowed to connect without using PFS to devices that support a version lower than the minimum. As an example, the configurator may indicate this using {…,”mustUsePFSIfVersionAtLeast”:3,…} in the connector, and a device configured with such a DPP connector will connect to devices that have connectors with no indication of whether PFS must be used or not, and thus to devices that conform to, e.g., DPP Release 1 [DPP] or Release 2 [WFEC_2], without insisting on the use of PFS. This is because DPP Release 1 [DPP] or Release 2 [WFEC_2] connectors do not include version or use of PFS information. Note that for {…,XYZ,…}, this means that “,XYZ” is inserted into the JSON code of the DPP connector.

[0056] It is noted that the DPP Enrollee and DPP Configurator can securely advertise to other devices the highest version of DPP that they support in the DPP Authentication Request and DPP Authentication Response messages because the attributes used for version information are integrity protected in the DPP Authentication Request and DPP Authentication Response messages, respectively. The highest supported version should not be confused with the minimum required version, as indicated in the grading indicator. Note further that in DPP Release 2 [WFEC_2] it is mandatory for a device or AP to support PFS. Thus, the configurator is certain which DPP versions the DPP enrollee supports, and therefore is certain whether the enrollee supports PFS, and therefore knows for certain whether the enrollee can include information that PFS must be used in the enrollee connector.

[0057] A further embodiment relates to negotiating device tracking prevention, where a security protocol at a first security level does not prevent tracking of a first device across multiple communication sessions in a network based on repeated data in messages of the first device, and a security protocol at a second security level requires avoiding or modifying said repeated data to prevent tracking, wherein a processor at the device is arranged to apply said tracking prevention when so instructed by a grading indicator.

[0058] Optionally, the security protocol is based on the Device Provisioning Protocol for configuring Wi-Fi devices, as defined in [DPP]. The Connector message is a Reconfiguration Connector based on the connector generated for use in the Reconfiguration Authentication Request message, as defined in the Device Provisioning Protocol. The configurator is arranged to insert a grading indicator into the Reconfiguration Connector, the grading indicator indicating a blocking constraint that indicates that device tracking blocking should be used by the device wishing to be reconfigured.

[0059] A processor in the device is configured to extract blocking constraints from the reconfiguration connectors and to apply tracking blocking during reconfiguration based on the blocking constraints. In a practical example, based on a configurator's grading indicator to the enrollee, where the configurator indicates to the enrollee that the configurator itself supports tracking blocking, the enrollee can use tracking blocking for NAKs of the enrollee's connectors that the enrollee sends to the configurator in a DPP reconfiguration response message. The blocking constraints are: As part of the enrollee's C-Connector in the DPP Reconfiguration Request message In a connector sent by the configurator to the enrollee during configuration, thus in the DPP configuration response message, or Not on any connector in this message, but as part of the DPP configuration response message Note that the grading indicators are integrity protected in each of these three cases.

[0060] It is pointed out that the "grading indicator indicating a minimum security level as minimally required" means, in addition to what has already been explained, that devices that do not support the minimum security level use a lower level, but only subject to further constraints, e.g. for backward compatibility or to enable support of low-cost devices. For example, upon receiving the grading indicator and finding out 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. Or, for example, an additional parameter indicating a lower acceptable level for backward compatible devices can also be part of the grading indicator. Nevertheless, if the device supports the minimum security level, it must use at least this minimum level.

[0061] In a practical example, a device with DPP Release 1 [DPP] and Release 2 [WFEC_2] sends the device's connector in plaintext to the AP in a DPP Peer Discovery Request frame, and the AP sends the AP's connector in plaintext to the Wi-Fi device in a DPP Peer Discovery Response frame. Since the device's or AP's connector contains the (uniform) public key NAK of this device, the device or AP can be tracked by any Wi-Fi device within RF range. The public NAK can serve as the device's identity. This violates the privacy of this device 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 the DPP Configurator is one that successfully connects to the network on which it was configured, but later encounters a problem when connecting to an AP using the device's connector. The problem may be, for example, that the device's connector expires, or that the first device and / or the AP are moved so that they happen to be out of RF range of each other. If the device experiences connectivity problems with the AP, it indicates this problem to the Configurator using the DPP Reconfiguration Authentication Protocol (see [WFEC_2]) and is reconfigured. Devices that are reconfigured using this protocol are called enrollees in the DPP Release 2 specification [WFEC_2].

[0063] A DPP Release 2 [WFEC_2] device sends 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] A configurator with DPP Release 2 [WFEC_2] sends the configurator's connector in plaintext to the enrollee in a DPP Reconfiguration Authentication Request message. However, the configurator connector's NAK is ephemeral, i.e., the NAK is randomly generated to be sent only once, and therefore the configurator cannot be tracked through these messages.

[0065] Preventing devices and APs from being tracked as described above is not supported by DPP Release 2 [WFEC_2]. Nevertheless, device tracking based on information in the DPP reconfiguration authentication protocol is prevented by privacy measures, such as encrypting the connector's NAK, as described in [2018PF00508]. Additionally, the use of privacy measures must be negotiated between the device and the AP.

[0066] Negotiating the prevention of device tracking based on information in DPP Peer Discovery Request and Result messages is not supported in DPP Release 2 [WFEC_2]. A simple option similar to negotiating the use of PFS as described above is to use the Protocol Version attribute in DPP Peer Discovery Request and / or Response frames. Nevertheless, these are not integrity protected and a MitM can conduct a downgrade attack by modifying or removing the Protocol Version attribute.

[0067] Negotiating device tracking prevention based on information in the DPP Reconfiguration Authentication message is not supported in DPP Release 2 [WFEC_2]. A further simple option is for the configurator to add an attribute to the DPP Reconfiguration Authentication Request message that it signals to the device wishing to be reconfigured, i.e., the enrollee, that it 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. Nevertheless, the DPP Reconfiguration Authentication Request message does not provide any integrity protection (there is no shared key established at this point in the protocol to enable integrity protection), and a MitM could in principle strip this attribute and thus mount a downgrade attack.

[0068] The following solution thwarts downgrade attacks against the negotiation of the use of device tracking prevention in DPP Reconfiguration Authentication Response messages and DPP Peer Discovery Response frames.

[0069] The configurator securely controls the use of Device Tracking Prevention in DPP in a similar manner to controlling the use of PFS described above. In contrast to PFS, Device Tracking Prevention is a technique used by either device or both. 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 Prevention on its own connector in the DPP Peer Discovery Response frame, but a stationary AP supports devices that apply Device Tracking Prevention on the device's connector in the DPP Peer Discovery Request frame that the device sends to the AP. Nevertheless, many smart phones have the capability to function as hotspots, i.e., many smart phones can function as mobile Wi-Fi APs through which Wi-Fi devices associated with this mobile AP can have Internet access through the smart phone's mobile Internet subscription. In contrast to stationary APs, it makes sense to use Device Tracking Prevention for hotspots on mobile phones or in non-smart phone mobile Wi-Fi hotspots.

[0070] The AP signals to devices that wish to associate with the AP that the device can or must use Device Tracking Inhibition for the AP's connectors, for example in a DPP Peer Discovery Request frame, with a grading message. Still, there is no integrity protection at this point in the protocol because the device has not yet received the AP's connectors. An unprotected method for detecting whether to use Device Tracking Inhibition on a connector is described in [2018PF00508].

[0071] A solution is now described for a device that wants to associate with an AP to inform the AP in a secure manner that the AP can use device tracking prevention on its connectors. After the AP has received the device connector in a previous DPP Peer Discovery Request frame, the AP sends a DPP Peer Discovery Response frame to the device. The configurator now inserts a grading indicator into any connectors that the configurator generates for this device. The grading indicator indicates that device tracking prevention is enabled or must be used by the AP in the DPP Peer Discovery Response frame. This information can be in the form of a generic indication, such as a version number, e.g., {…,”version”:3,…}, or a more specific indication, e.g., {…,”mayUseTrackingPrevention”:true,…} or {…,”hasToUseTrackingPrevention”:true,…}. Note that for {…,XYZ,…}, “,XYZ” is meant to be inserted into the JSON code of the DPP connector. If a device sends such connectors to an AP in a DPP Peer Discovery Request frame and the device itself also uses Device Tracking Prevention, e.g., by encrypting a NAK of the device's connectors in the manner described in [2018PF00508], the AP MUST first restore the received connectors as described in [2018PF00508] before the AP can verify the signature of the received connectors and after it can securely determine a successful signature match, regardless of whether Device Tracking Prevention can or must be used.

[0072] A DPP Release 2 [WFEC_2] device (DPP enrollee) sends 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 frames.

[0073] In an embodiment, when a DPP Configurator is sending a DPP Reconfiguration Authentication Request message to a device (DPP Enrollee) that wishes to be reconfigured, the grading indicator in the connector is used to securely inform the enrollee that the enrollee can or must use device tracking prevention when the enrollee replies with a DPP Reconfiguration Authentication Response message. Thus, the configurator inserts a grading indicator into the configurator's connector that the configurator generates for use in the DPP Reconfiguration Authentication Request message. The grading indicator indicates that device tracking prevention can be used by the enrollee that wishes to be reconfigured. This information can be in the form of a generic indication, such as a version number, e.g., {...,"version":3,...}, or a more specific indication, e.g., {...,"mayUseTrackingPrevention":true,...} or {...,"useTrackingPrevention":true,...}. If the enrollee supports device tracking prevention and if the enrollee sees information in the DPP configurator connector that the enrollee can use device tracking prevention, the enrollee shall use device tracking prevention by, for example, encrypting the enrollee's connector's NAK, as described in [2018PF00508].

[0074] In a further embodiment, the security protocol includes a setup protocol that performs the following actions: First, a certificate is obtained from a certificate authority. Then, security parameters using the certificate are provided, e.g., generated and encrypted or integrity protected based on the certificate, e.g., using a generated key or a security algorithm indicated in the certificate. Then, the security parameters are transferred to the device via a setup message. The certificate includes a grading indicator, which indicates constraints on the security parameters. For example, the certificate is provided by the certification server based on a certification request message from the device to be configured or from a configurator. The request includes a request to include a grading indicator or an indication of parameters or settings to be protected via the grading indicator.

[0075] A device processor of a device arranged to apply said security protocol is configured to retrieve a grading indicator from the certificate. The processor is then configured to receive and / or transmit a setup message. The processor is also configured to determine a security level based on the setup message and the constraints of the security parameters. Optionally, the security protocol provides for the setup of cryptographic security parameters. The 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 such negotiation or setup of cryptographic parameters is Transport Layer Security (TLS). Many cryptographic protocols, of which TLS 1.3 [RFC 8446] is one, have incorporated flexibility in the use of cryptographic primitives, such as the encryption algorithm to be used, the key size to be used, the cryptographic hash algorithm to be used, or the protocol variant to be used, whether or not to use Perfect Forward Secrecy (PFS). TLS 1.3 [RFC 8446] is described in more detail below to show how the above enhancements are used. The use in other cryptographic protocols is easily derived from this description.

[0077] In the TLS negotiation phase, the first message sent by the client is a ClientHello message that specifies the highest TLS protocol version the client supports, a random number, a list of proposed cipher suites, and a compression method. The server's reply to the ClientHello message is a ServerHello message that includes, among other things, the selected cipher suite. The ClientHello and ServerHello messages are not initially integrity protected. Nevertheless, when a shared key has been successfully established between the client and server using one of the three possible modes: (EC)DHE (Diffie-Hellman over finite fields or elliptic curves), Pre-Shared key (PSK) only, or PSK with (EC)DHE, the TLS setup is completed by the server sending a "Completed" message to the client that contains a keyed hash over the entire setup exchange based on a key derived from the shared key that the server just established, thus including the ClientHello and ServerHello messages. The client then sends its own "finished" message to the server, which also contains a keyed hash over the entire setup exchange, and thus the ClientHello and ServerHello messages. The keyed hash function is a hash function that produces an input-based hash of the keyed hash function, and the hash value is also based on the value of a (secret) key. Thus, the ClientHello and / or ServerHello messages are integrity protected later in the TLS protocol.

[0078] There are many variations of TLS and several choices for the cryptographic parameters of TLS. It is possible for a hacker to change the TLS setup in a TLS server or client. The setup of a TLS server or client can also be accidentally or deliberately changed from the originally intended setup by any administrator of the TLS server or client. For example, the "Internet Options" menu of the browser Internet Explorer gives the user the choice to allow or not allow the use of specific TLS versions.

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

[0080] When setting up a server for TLS, the initial administrator must obtain a certificate from a certification authority (CA). Once created, the certificate cannot be accidentally or maliciously altered, since TLS clients will not accept this certificate any more. In addition to obtaining the certificate, a (possibly different) administrator must set up the use of TLS. Such an administrator must, for example, set up the following: The Authenticated Encryption with Associated Data (AEAD) algorithms / HMAC-based Extract-and-Expand Key Derivation Function (HKDF) hash pairs that the server is authorized to use, The (EC)DHE group that the server is allowed to use, The signature algorithms that the server is permitted to use, and The minimum version of TLS that the certificate owner device is permitted to use.

[0081] Note that the minimum version of the TLS protocol that is allowed to be used is functionally distinct from the TLS version of the certificate itself: for example, a TLS certificate may have an indicator formatted according to TLS V1.4, but a grading indicator in this TLS V1.4 certificate may indicate, for example, that only TLS versions from TLS V1.4 are allowed, or that TLS V1.2 or later must be used.

[0082] When requesting a server certificate from a certification authority, the initial administrator includes specialized grading data in the request to request that the certificate contain grading indicators indicating, for example, constraints, security options, acceptable or unacceptable values ​​as described above, or other TLS configuration parameters.

[0083] The current syntax of certificates is specified in X509 v3 [RFC5280], which uses Abstract Syntax Notation One (ASN.1), [X.680], as the specification language. Certificates use Object Identifiers (OIDs) as indicators for a number of things. For example, the OID one would use to indicate organizationName is 2.5.4.10, while the OID to indicate RSA encryption, a specific asymmetric encryption algorithm, is 1.2.840.113549.1.1.1. OIDs to indicate specific extensions in the "extensions" component of a certificate start with 2.5.29, and the OID to indicate the basic constraints extension of section 4.2.1.9 of X509 v3 [RFC5280] is 2.5.29.19.

[0084] Possible values ​​for the TLS parameter TLS1.3 are indicated in TLS messages by numbers specified in [RFC8446]; e.g., the hexadecimal value (0x0403) indicates the signature algorithm "Elliptic Curve Digital Signature Algorithm" (see [FIPS186-4]) using the elliptic curve P-256 (see [FIPS186-4]) and SHA256 (see [FIPS180-4]) as the hash algorithm.

[0085] Thus, to strengthen certificates as proposed, X509 can be extended with an extension called, for example, "allowedTLSParameters", denoted by a new OID 2.5.29.19.x, with the x being taken from the appropriate value from the organization that maintains this sector of the OID tree, and this new extension containing an array of allowed TLS parameters, denoted by values ​​as specified in TLS1.3 [RFC8446]. As an example, the type to be used for this new extension could be represented in ASN.1 as follows: AllowedTLSParameters::=SEQUENCE{allowedTLSParameter integer}

[0086] The ASN.1 for the encoding of an instantiation of type "AllowedTLSParameters" is stored in a component called "extnValue" in the "Extensions" 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 also uses object identifiers (OIDs) to indicate the allowed values ​​of the parameters. The advantage of using OIDs is that the OIDs can be used by any protocol to indicate cryptographic parameters, while the hexadecimal values ​​specified in TLS1.3 [RFC8446] can only be used to indicate this for the TLS protocol. As an example, the type to be used for this new extension using OIDs is represented in ASN.1 as follows: AllowedTLSParameters ::= Set of AllowedTLSParameters AllowedTLSParameter ::= SEQUENCE { allowedTLSParameterType object identifier, allowedTLSParameterValues ​​AllowedTLSParameterValues ​​Optional -- allowedTLSParameterValues ​​is required when the object identifier alone is not sufficient. } AllowedTLSParameterValues::= Set of AllowedTLSParameterValues AllowedTLSParameterValue ::= integer

[0088] The type AllowedTLSParameterValues ​​above is only an example: there may be other information in it besides integers, 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 that contains one integer component, e.g., with value 11, representing TLS version 1.1.

[0090] When an enhanced TLS server sends a certificate or a TLS client receives a certificate with information about the allowed TLS parameters to be used, and the negotiated TLS parameters are not mentioned in the allowed TLS parameters list in the certificate, the server or client must abort the setup of the TLS protocol. The grading indicator therefore indicates such a list, but also includes structures like algorithms for which the use of X is allowed if the algorithm version number is greater than or equal to Y or the algorithm quality is greater than or equal to Y, e.g. if an ECC curve with a prime length of 256 bits or more is used. The grading indicator also indicates blacklists, i.e. lists of TLS parameters that are not allowed to be used. The blacklist also includes structures like algorithms for which the use of X is not allowed if the algorithm version number is less than or equal to Y or the algorithm quality is less than or equal to Y, e.g. if an ECC curve with a prime length of 255 bits or less is not used.

[0091] A TLS client may also have a certificate that can be used by the TLS server to authenticate the TLS client, and that is used in TLS setup and for derivation of session keys. Similar to the TLS server certificate described above, a TLS client certificate may also include allowed or not allowed values, or minimum allowed values, for TLS parameters.

[0092] Thus, when using a grading index for TLS, an administrator of a TLS server or client can request a certificate for the TLS client or server with an indication of allowed or not allowed values ​​of TLS parameters, or of the minimum allowed values. Such a TLS client or server will only use values ​​of TLS parameters that are allowed by the certificate. Changing the configuration of the TLS client or server will not result in the TLS client or server using not allowed values, and thus the setup of the TLS server or client becomes more secure for its administrator.

[0093] In a further embodiment, 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 specifications and certification program for WFA. WPA comes in two flavors: WPA-PSK (Pre-Shared Key) or WPA-Personal on the one hand and WPA-Enterprise on the other. There are three major releases of WPA, namely WPA, WPA2, and WPA3 [WPA3], each of the three supporting the two flavors.

[0094] WPA-PSK requires each Wi-Fi device (as well as the AP) to have a PSK (Pre-Shared Key) for the network it will be connecting to. The PSK is usually the same for all users of a particular 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, depending on the 802.1x policy, can be several different systems labeled EAP (Extensible Authentication Protocol). Because each device is authenticated before connecting, a private encrypted tunnel is in effect created between the device and the network.

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

[0096] Several EAP protocols can be used by a RADIUS server, of which EAP-TLS [RFC5216] and EAP-TTLS / PAP [RFC5281] are EAP versions that use certificates.

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

[0098] The difference between WPA3-Enterprise and WPA2-Enterprise is that WPA3-Enterprise introduces a requirement that server certificate authentication be configured to verify the identity of the server to which the device is connecting.

[0099] In this description, WPA-Enterprise means WPA-Enterprise, WPA2-Enterprise, WPA3-Enterprise, or any future successor thereof.

[0100] As with the above embodiment, the entity that requests a certificate for use with WPA-Enterprise is different from the entity that configures an AP or Wi-Fi device for use with WPA-Enterprise. The proposed enhancements make the WPA-Enterprise setup more secure for TLS server or client administrators.

[0101] Negotiation of the security of a Wi-Fi connection between a Wi-Fi device and an AP is performed using a Robust Security Network element (RSNE, Clause 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, thus e.g. in probe requests sent by the device and probe responses and beacons sent by the AP. The RSNE contains a paired cipher suite list and an AKM (authentication and key management) suite list. The paired cipher suite list lists the ciphers supported by the device as indicated by the cipher suite selector, e.g., the cipher 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 that it does not support. A device cannot successfully complete a protocol for which it does not have the required information. For example, a device that does not know the passphrase cannot use WPA-Personal to associate to an AP. Similarly, other security processes such as EAP-TLS and EAP-TTLS / PAP also perform some negotiation.

[0103] After the device, server, or AP is provided with the initial certificate, there are still some options that can be made for security setup and that can be changed by an attacker or a careless administrator. For example, a device set up for EAP-TLS must have a certificate. Still, it is optional for the RADIUS server in this case to have a certificate for server authentication as well. This is that the device is originally set up to only accept RADIUS servers when they are capable of engaging in server-side authentication. Another careless administrator or hacker can later change this, thereby reducing the level of security. By using the above enhancements on the grading index, the original administrator can apply for a device certificate that includes the constraint that server-side authentication using a server certificate must always be used. The device will then refuse 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 added to the certificate can be the size of the PMK that will be used after authentication. For example, a constraint is that the PMK that will be used must be larger than 128 bits. Constraints can be included in the certificate, for example via a grading index, as discussed in the previous embodiment.

[0104] In a further embodiment, the first device is a client device and the second device is a server device, and the grading indicator is indicative of a client constraint for which client-side authentication using a certificate is required. A processor of the client device is arranged to extract the client constraint from the certificate. The processor is then arranged to receive the setup message and apply the 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. Nevertheless, client-side authentication is 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 a certificate is always required. The AP will then always refuse to successfully complete EAP-TTLS / PAP with a device that is not capable of presenting a certificate during this protocol, even if a careless administrator or hacker later changes the setup of the AP to not require a client certificate.

[0105] The above enhancements therefore make the setup of WPA-Enterprise on devices and APs using EAP-TLS or EAP-TTLS / PAP more secure and provide protection against MitM attackers modifying security negotiation messages.

[0106] The above embodiments have been described using devices. Nevertheless, the various protocols, messages, and processor actions are performed by corresponding method steps that can be easily derived from the above description. The method is performed, for example, by circuit devices and software in a processor or a Wi-Fi controller. Appropriate encryption and decryption functions have been described above. As will be clear 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. Moreover, steps of other methods may be inserted between steps. The inserted steps may represent improvements of the method as described herein or may be unrelated to the method.

[0107] There is provided a computer program product, downloadable from a network and / or stored on a computer readable and / or microprocessor executable medium, comprising program code instructions for carrying out the above methods, connection sequences, security processes and further operations when executed on a computing device. Thus, the methods according to the invention are carried out using software comprising instructions for causing a processor system to carry out the respective methods.

[0108] FIG. 2a shows a computer readable medium 1000 having a writable portion 1010 with 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 FIG. 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 is equally conceivable. Furthermore, although the computer readable medium 1000 is illustrated here as an optical disk, it will be understood that the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, a solid state memory, a flash memory, etc., and may be non-writable or writable. The computer program 1020 comprises instructions for causing a processor system to perform said methods.

[0109] Typically, the devices performing the above processes each comprise a processor coupled to a memory containing the appropriate software code stored in the device, e.g., the software downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM, or a non-volatile memory such as Flash (not shown). The devices are, for example, equipped with a microprocessor and memory (not shown). Alternatively, the devices are implemented in whole or in part in programmable logic, e.g., as a Field Programmable Gate Array (FPGA). The devices and servers are implemented in whole or in part as so-called Application Specific Integrated Circuits (ASICs), i.e., integrated circuits (ICs) customized for the specific application of the devices and servers. For example, the circuits are implemented in CMOS, e.g., using hardware description languages ​​such as Verilog, VHDL, etc.

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

[0111] The software includes only the steps performed by a particular subentity of the system. The software is stored on a suitable storage medium, such as a hard disk, floppy, memory, etc. The software is sent as signals along wires, or wirelessly, or using a data network, such as the Internet. The software is made available for downloading and / or for remote use on a server. The method according to the invention is performed using a bit stream arranged to configure a programmable logic, such as a field programmable gate array (FPGA), to perform the method. It will be understood that the software is in the form of source code, object code, code intermediate source and object code, such as partially compiled form, or any other form suitable for use in implementing the method according to the invention. An embodiment of a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the described methods. These instructions are subdivided into subroutines and / or stored in one or more statically or dynamically linked files. Another embodiment of a computer program product comprises computer executable instructions corresponding to each of the means of at least one of the described systems and / or products.

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

[0113] It is pointed out that in this document, the word "comprises" does not exclude the presence of elements or steps other than those listed, the singular word "a" or "an" does not exclude the presence of a plurality of such elements, any reference signs do not limit the scope of the claims, the invention is implemented by both hardware and software, and several "means" or "units" are represented by the same item of hardware or software, and a processor, possibly in cooperation with a hardware element, performs the functions of one or more units. Moreover, the invention is not limited to the embodiments, and the invention consists in each and every novel feature or combination of features recited above or in mutually different dependent claims.

[0114] In summary, the present application relates to a device and a method for establishing a secure communication between a first device and a second device over a physical channel by means of a security protocol. 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 and the second device 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 that downgrade the security level.

Claims

1. 1. A method for establishing a security level for communication between a first device and a second device over a physical channel by a security protocol, the security protocol comprising: establishing first integrity data at the first device and second integrity data at the second device; at least two security levels, the security levels being selectable based on grading information transported over the physical channel, and the security protocol according to a first security level not preventing tracking of the first device across multiple communication sessions in a network based on repeated data in the first device's messages; provide the security protocol according to a second security level requires avoiding or modifying the repeated data to prevent tracking; The method comprises: transporting, via said physical channel, a grading indicator indicating a minimum security level as minimally required by at least one of said first device and said second device; providing integrity protection for the grading index based on the integrity data; applying tracking prevention when the grading indicator indicates that tracking prevention is to be performed; A method comprising:

2. 1. A device, the 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, the security protocol comprising: establishing first integrity data at the first device and second integrity data at the second device; at least two security levels, the security levels being selectable based on grading information transported over the physical channel, and the security protocol according to a first security level not preventing tracking of the first device across multiple communication sessions in a network based on repeated data in the first device's messages; provide the security protocol according to a second security level requires avoiding or modifying the repeated data to prevent tracking; the device comprising: sending or receiving, via the physical channel, a grading indicator indicating a minimum security level as minimally required by at least one of the first device and the second device; When sending, including protection data of the grading indicator based on the integrity data; Upon receipt, verifying the protected data based on the integrity data; applying at least the minimum security level for the communication between the first device and the second device; applying tracking prevention when tracking prevention is instructed by the grading indicator; A device comprising a processor that performs the steps of:

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 said grading indicator into a connector message; sending the connector message to the first device; and a processor of the first device, receiving said connector message; extracting the grading indicator from the connector message; The device of claim 2 , wherein

4. the security protocol according to the first security level requires determining a pairwise master key at both the first device and the second device based on a private key and public key material, the pairwise master key being used to determine a session key for encrypted communications between the first device and the second device; the security protocol according to the second security level requires determining a master key of the pair involving an ephemeral Diffie-Hellman key pair; The device of claim 3 , wherein the processor applies the second security level when the second security level is indicated by the grading index.

5. 5. A device according to claim 2, wherein in the security protocol at least part of the grading information is free of integrity protection.

6. The security protocol comprises: Obtaining a certificate from a certification authority; using said certificate to provide security parameters; transporting said security parameters to said device via a setup message; a setup protocol comprising: the certificate includes the grading indicator, the grading indicator indicating a constraint on the security parameter; the processor: retrieving the grading indicator from the certificate; receiving the setup message; determining the security level based on the setup message and the constraints of the security parameters; The device of claim 2 , wherein

7. The security protocol provides for the setup of cryptographic security parameters, the cryptographic security parameters comprising: the cryptographic algorithm to be used, The key size you will be using, the cryptographic hash algorithm to be used, the minimum version of said security protocol to be used; The security protocol options to be used The device of claim 6, comprising one or more of:

8. the first device is a client device, the second device is a server device, and the grading indicator indicates a client constraint requiring client-side authentication using a certificate; the processor: Retrieving the client constraints from the certificate; receiving the setup message; applying client-side authentication based on the client constraints; 8. 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 Wi-Fi devices defined in [DPP], and the connector message is based on a connector defined in the Device Provisioning Protocol modified by inserting the grading indicator; The device of claim 3 , wherein the processor receives the modified connector.

10. the security protocol is based on the Device Provisioning Protocol for configuring Wi-Fi devices 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; a configurator inserting the grading indicator into the reconfiguration connector, the grading indicator indicating a blocking constraint indicating that device tracking blocking can or should be used by the device desired to be reconfigured; the processor: extracting the blocking constraints from the modified connectors; applying tracking blocking during reconstruction based on said blocking constraints; The device according to claim 2 , wherein the device performs the following:

11. The device of claim 2 , wherein the physical channel is a wireless communication channel.

12. 12. A 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. 10. A program downloadable from a network and / or stored on a computer-readable and / or microprocessor-executable medium, said program comprising program code instructions for performing the method of claim 1 when said program is run on a computer.

Images