Certificate from server

Abstract

Accordingly, there is provided a method of obtaining trust by a client for a server in a network including the server and a suitably arranged device. The method comprises: acquiring a certificate of a bootstrap server by a client, and checking whether a root certificate of a certificate chain to which the certificate belongs is in a repository of trusted certificates, or checking whether the certificate itself is in the repository of trusted certificates if the certificate is a self-signed certificate. If the root certificate is not in the trusted repository, or the certificate itself is not in the trusted repository if the certificate is a self-signed certificate, then checking whether the boot server is network-local, and if the server is network-local, adding the root certificate to the repository, or if the certificate is a self-signed certificate, the certificate itself is added to the repository.

Description

Technical Field

[0001] The present invention relates to devices and methods for use in wireless networks, and in particular, to those devices and methods that comply with the IEEE 802.11 family of standards. Background Art

[0002] When implementing TLS (Transport Layer Security, [RFC 8446]) and SSL (Secure Sockets Layer [RFC 6101]), one of the security options that can be used is server-side authentication using certificates. This means that the client device obtains a certificate from the server along with other information when contacting the server over the network. The certificate contains the public key from the server along with other information, such as the server's IP (Internet Protocol) address, the URL (Uniform Resource Locator) where the server can be found, and / or the name of the server or server company. All of this information is digitally signed using a private signing key.

[0003] If the private signature key is the private signature key of the public key in the certificate, then the certificate is so-called self-signed. In this case, the client can use the server's public key in the certificate to check the signature on the certificate.

[0004] If the private signing key belongs to another party, the public signing key belonging to the private signing key is also mentioned in the certificate and is part of the signed data. In this case, the client can use the public signing key in the certificate to check the signature on the certificate. In this case, the server uses a public key infrastructure (PKI).

[0005] The important question for the client is whether the signing key of the certificate can be trusted. If the client trusts the signing key, then the client checks the signature on the certificate. If the signature is correct, then other information in the certificate can be checked and see if it is correct as well. For example, if the certificate contains an IP address or URL, then check if the server was contacted at that IP address or URL. If not, then the server that sent that certificate should not be trusted. If the certificate contains a company name, then the client (or its user) can check if that company name is indeed the name of the company the user wants to contact.

[0006] This problem for the client is solved in the PKI in the following way. Certain companies serve as so-called certification authorities (CA). These CAs have self-signed certificates. The self-signed certificates of the CAs are called root certificates. OS (operating system) vendors and Internet browser vendors collect the root certificates that they trust and store these in a secure location in the device so that root certificates cannot be added or removed without restriction. The superuser must give explicit permission for this. If an attacker can insert his own root certificate in the browser, the browser will trust all certificates pointing to this root certificate. This allows an attacker to make the browser trust, for example, a pirated banking website. OS vendors and browser vendors also store the certificates of intermediate CAs. The certificates of intermediate CAs are signed by one CA or another intermediate CA.

[0007] Therefore, in the case that the first certificate is not self-signed, the client searches for a second certificate containing a public signature key in its certificate repository. This second certificate is also checked. If correct and if this second certificate is also one of the intermediate CAs, the client further searches for a third certificate containing a second public signature key, and so on, until the certificate found is a root certificate. All certificates from the server to the root server form a certificate chain.

[0008] It is desirable to provide efficient certificate handling, particularly in network configuration scenarios. Summary of the invention

[0009] It is desirable that the configuration of the wireless network work in a manner that will allow TLS to be deployed for the resulting connection between the server and the devices using the service.

[0010] Therefore, a method for obtaining trust in a server in a network by a client is provided, the network including the server, the method comprising: obtaining, by the client, a certificate of the server, checking whether a root certificate of a certificate chain to which the certificate belongs is in a repository of trusted certificates, or checking whether the certificate itself is in a repository of trusted certificates if the certificate is a self-signed certificate. If the root certificate is not in the trusted repository, or the certificate itself is not in the trusted repository if the certificate is a self-signed certificate, the method comprises checking whether the server is local to the network, and if the boot server is local to the network, adding the root certificate to the repository, or adding the certificate itself to the repository if the certificate is a self-signed certificate.

[0011] If the server is local, then the certification authority may not be accessible. However, in the local case, the server is under the control of the user and can therefore be provided with a degree of trust. By verifying that the server is local, the client can trust the server even in the absence of third-party certification and can therefore store the certificate. By storing the certificate in a repository of trusted certificates, the client will be able to identify the server in the future.

[0012] According to an aspect of the invention, the server is a boot server and the client is a boot configurator.

[0013] In this case, the method can advantageously be used for commissioning / configuration of devices in a network, wherein the booting uses a service running on a local server for booting (boot server).

[0014] In one aspect, the method includes performing an ownership check on the certificate to verify whether the certificate belongs to the local server, and if the certificate belongs to the local server, continuing execution of the method, otherwise suspending execution of the method.

[0015] In the case where the client discovers that the server is not local, it is useful to terminate the method at this point because trust cannot be established. In the case where the server is local, it is considered trustworthy.

[0016] In one aspect of the invention, the local server is not connected to a certification authority.

[0017] Even in this case, the approach provides for building trust.

[0018] In one aspect of the present invention, the client performs a signature check on the certificate, and if the certificate is not a self-signed certificate, the client performs a signature check on all certificates in the certificate chain to which the certificate belongs, and if the result of the check is that at least one of the signatures is incorrect, the execution of the method is terminated.

[0019] Unless all signatures on available certificates are correct, the client cannot be sure that even the local server can be trusted.

[0020] In one aspect of the invention, the certificate is obtained through an out-of-band (OOB) method.

[0021] The use of an OOB approach increases the level of security because it allows the transmission of information that is inherently sensitive (ie, should remain private to the devices legally involved) to be exchanged before trust is established and encryption is performed.

[0022] In one aspect of the invention, the OOB method involves a QR code or NFC.

[0023] In one aspect of the invention, an enrollee is configured for communicating in a wireless network.

[0024] In one aspect of the present invention, registrant guidance information is acquired through an OOB method to guide the registrant.

[0025] In one aspect of the invention, a protocol according to the Wi-Fi Device Configuration Protocol is executed.

[0026] There is also provided a configurator device according to the above method, the configurator device being further arranged to run a local server and configure a device for communication in a wireless network.

[0027] There is also provided a boot configurator device according to the above method, the boot configurator device being further arranged for obtaining OOB boot registrant information and transmitting the registrant boot information to a boot service.

[0028] There is also provided a computer program product arranged to, when run on a computer processor, perform the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and additional objects, features and advantages of the disclosed apparatus, system and method will be better understood through the following illustrative and non-limiting detailed description of embodiments of the apparatus and method with reference to the accompanying drawings, in which:

[0030] Figure 1 Indicates the wireless network you wish to configure your device to add.

[0031] Figure 2 The flowchart of the configuration process according to the embodiment is shown.

[0032] Figure 3 A flow chart showing a portion of a configuration process according to an embodiment. DETAILED DESCRIPTION

[0033] In the following description, the same reference numerals denote the same elements.

[0034] Figure 11 represents a local wireless network 1, which contains a first device 2 and another device 3, which may be a (network) printer. The first device 2 may have a central function and be similar to an access point (AP), a hub or a gateway device. For simplicity, the first device 2 will be referred to as an AP in the following text, although other types of devices are indeed possible. A user (not shown) wishes to add two other devices to the local wireless network 1, namely a complex device 4 (here represented as a computer) and a simple device 5 (here represented as a toothbrush). Devices similar to the simple device 5 typically do not have any real user interface (UI) except for a possible light, and are therefore typically referred to as headless devices. The first device or AP 2 has a processor 6, and the simple device 5 has a microcontroller and a small non-volatile memory 7 and a button 8 that can be used to reset the simple device 5. There is also a third device 9, which may be a configurator. Finally, there is a boot configurator 10. The server may reside in any of these devices (particularly the first device or AP 2, the device 3 or the device 9). The server may provide any service. In particular, AP 2 and device 9 may, for example, provide a boot service, and device 3 may provide a service similar to a printing service.

[0035] Some wireless networking standards allow one device (configurator or debugger) to configure another device (enrollee) in order to establish a connection and communication. This makes the task of adding or enrolling new devices in the network less onerous because the user no longer needs to perform manual input.

[0036] Figure 2 The flow of the configuration method of device control according to the embodiment is shown, whereby a device (for example, Figure 1 A third device 9) can configure another device (e.g., Figure 1 The third device 9 and the devices 4 and 5 are according to an embodiment. As an example, the case of the simple device 5 will be discussed. It should be understood that although most of this specification provides examples involving a network with devices similar to AP 2, the process can work in a peer-to-peer situation. It should also be understood that the configurator can be co-located in AP 2.

[0037] One example of a device-controlled configuration method is the Device Configuration Protocol (DPP) used in networks using Wi-Fi or IEEE 802.11. In the Device Configuration Protocol (DPP), a device acting as a DPP configurator can securely configure any Wi-Fi-enabled device for connecting to a Wi-Fi AP.

[0038] At S1, the process starts with two devices 9 and 5 being in an unconnected state and device 5 being unconfigured. For the purpose of discussion, device 9 will be used to configure device 5 to join wireless network 1, so device 9 can be called a configurator and device 5 can be called a registrant (because it is registering in wireless network 1).

[0039] One way for a user to ensure that, for example, the configurator and enrollee performing Diffie-Hellman at the beginning of a configuration protocol (e.g., specified in [DPP] or [WPS]) are indeed the devices expected by the user is that at least one of these devices makes its public key for Diffie-Hellman available in a QR code (see [DPP]). The information in the QR code contains a so-called DPP boot URI, which contains, among other information, the public boot key of the device to which the QR code belongs. The other device scans the QR code with its camera and uses the public key therein for Diffie-Hellman. In this way, the user performing the scan is sure that her device will perform Diffie-Hellman with the device whose QR code she scanned. The DPP boot URI can also be transmitted by other technologies, for example, by NFC (Near Field Communication) touch.

[0040] The problem exists because for certain devices (e.g., fixed devices like access points (APs)), supporting cameras is impractical. In the case of NFC, performing an NFC tap between two such fixed devices may be impractical: it is cumbersome to move the two fixed devices close enough to each other. Therefore, versions of the DPP specification [DPP] have specified that configurators without cameras (or NFC interfaces, etc.) can use mDNS (multicast DNS (Domain Name Service) [RFC 6762]) to advertise so-called bootstrap services. Devices on the same IP network can browse these advertisements using, for example, DNS-SD (Domain Name Service - Service Discovery) [RFC 6763].

[0041] A device with a camera (referred to in [DPP] as a bootstrap configurator) can be used to scan the QR code, browse mDNS for the bootstrap service using, for example, DNS-SD, and use this information to send the scanned public key (DPP bootstrap URI) to the bootstrap service, through which the configurator 9 obtains this information. In this way, it is as if the configurator supports the camera itself. The bootstrap configurator can of course also obtain the DPP bootstrap URI in any other way (for example, by NFC touch). The bootstrap configurator can, for example, be implemented as an application for a smartphone. In the case where the AP runs the bootstrap service, the AP as the registrant can use the bootstrap service (and use the bootstrap configurator through the bootstrap service) to obtain the DPP bootstrap URI of the configurator, or the AP can also act as a DPP configurator and use the bootstrap service (and use the bootstrap configurator through the bootstrap service) to obtain the DPP bootstrap URI of the registrant.

[0042] The problem with DPP is that the DPP specification requires the boot server to have a certificate. The boot server certificate can be used by the boot configurator to gain trust in the boot service (i.e., confirm that the boot service is a legitimate service), and for establishing a secure encrypted channel to send the DPP boot URI to the configurator's boot service. In practice, the boot service will only be reachable on the local network. This means that it is difficult to obtain a certificate from an (intermediate) CA, and most will have to use a self-signed certificate. But then how to make the boot configurator trust the boot service's certificate? The same problem arises for a device like the following: the device runs a print service, and for the print service the user wants to use TLS or SSL in order to be sure that she is printing on the right server and not on a server in another home.

[0043] At S2, often referred to as "bootstrapping", one device obtains the bootstrap public key (B R ) and for the device to be configured. This is done by another means (i.e., OOB) other than wireless communication technology. Examples of this could be a user causing one device to read a QR code on the Responder, causing NFC communication or another wireless technology (e.g., Bluetooth) between two devices, or by a user causing the boot configurator to obtain the DPP boot URI, for example, by reading a QR code containing the DPP boot URI and transmitting it to the configurator, for example, by using an HTTPS (secure hypertext transfer protocol) POST to the configurator's boot service.

[0044] The boot process is initiated by user intervention. If the boot has been successful, the process reaches S3 and the devices 9, 5 are booted, otherwise they return to the starting state at S1. In either case, the enrollee device (in this case the simple device 5) can record the result of the boot process in a suitable storage means, for example, as a flag in a register in memory. Typically, a simple device is programmed to wake up after manufacturing or after a reset and turn on its radio on the channel indicated in its QR code for configuration and start listening for authentication request messages. (Non-simple devices are usually set in this mode by their user, for example by a reset.)

[0045] At S4, the devices 9, 5 perform an authentication process, whereby the devices establish trust, i.e., the user can be confident that the device is the device they think it is, and not some other unknown (and potentially malicious) device "pretending" to be one or other of the devices in question. A message is sent from one device requesting the start of authentication. The message can be sent by the device being configured (configurator) or the device to be configured (registrant). In this example, the third device 9 is used as a configurator, and the simple device 5 is used as a registrar. It should be noted that the third device 9 is shown as being connected to the network 1, although this is not necessary for the embodiment to work. The device that starts wireless communication is called the initiator, and the device that responds is called the responder. In particular, the DPP protocol allows both the configurator and the registrar devices to act as the initiator of the DPP protocol, whereby the other device automatically becomes the responder. Simple devices or headless devices will typically assume the role of responder.

[0046] The other device responds to the message. If the authentication request message is decoded correctly and contains information indicating that the initiator is the device the user thinks it is and has the required capabilities, the response message indicates that the message has been "accepted" and contains the information required by the initiator to verify the credentials of the responder and that it also has the required capabilities. If neither device receives the required information from the other device, the process is aborted and the device returns to the booted state at S3. If the initiator is a registrant, the authentication request message may also include an additional portion indicating the results of a previous attempt to configure the registrant. If the responder is a registrant, the authentication response message may include an additional portion indicating the results of the previous attempt. It should be understood that the indication also indicates whether a previous attempt existed.

[0047] In the case of the DPP protocol, the first message is an authentication request message and the response message is a DPP authentication response. The responder checks that the DPP authentication request message contains a correctly generated cryptographic hash of the responder's public boot key and whether it has a copy of the initiator's public boot key. The responder sends a DPP authentication response message indicating whether the authentication can continue. If not, the process is aborted due to, for example, a failure in an attempt to decrypt the encrypted random number in the DPP authentication request message. The DPP authentication response contains a cryptographic hash of the responder's public boot key and may contain a hash of the initiator's public boot key. Similarly, for the initiator, the registrant may have obtained the public key through OOB communication. The initiator's public boot key can then be used for mutual authentication. In the absence of the initiator's public boot key, only the initiator can authenticate the registrant, but not the other way around.

[0048] If the authentication response message indicates that the responder has accepted the authentication request message and the response meets the criteria imposed by the configuration of the initiator, the initiator issues an authentication confirmation message. If the authentication values ​​in the authentication response and confirmation messages are found to be correct by the relevant devices, this part of the protocol (the authentication part) is successful, the process has reached S6 and configuration can begin. The confirmation message may also contain an indication of the results of a previous configuration attempt (where the registrant was also the initiator).

[0049] At S7, the registrant device sends a configuration request message with information about what type of configuration the registrant wants. If the configurator is able to grant the request, a message is sent with the information the registrant needs (e.g., network key). The process then ends at S8 with a successful configuration of the registrant.

[0050] In the case of DPP, the request message is a DPP configuration request, and the response of the configurator is a DPP configuration response message. The DPP configuration response may contain the service set identifier (SSID) of the network to which the registrant should connect, and may contain a DPP Connector. The DPP Connector may be considered a certificate, digitally signed by the configurator, and contains the public network access key of the registrant as well as other information. The DPP configuration response message also contains the configured public signature key. Other devices that have been configured by the same configurator can thereby check whether they can trust the public network access keys of other devices. The DPP configuration response message may also contain the Wi-Fi passphrase or pre-shared key (PSK) of the network. The registrant sends a DPP configuration result message (depending on the version of DPP) to the configurator to let it know whether it accepts the configuration. The fact that the configurator does not receive the message may indicate to the configurator that there is a Wi-Fi problem between the configurator and the registrant. Then, the "assumed configured" registrant can send its Connector to AP 2 configured by DPP. If the Connector signature is found to be correct, and if AP 2 has a matching Connector signed by the same configurator, i.e., a Connector for the same network, then AP 2 sends its own Connector to the Registrar. The Registrar and AP 2 can calculate a symmetric key in a Diffie-Hellman fashion based on each other's network access keys in the Connector and their own private network access keys.

[0051] In the event that the enrollee receives a Wi-Fi password or a Wi-Fi pre-shared key (PSK), the enrollee attempts to associate with AP 2 in a conventional manner through a 4-way handshake as specified in [802.11].

[0052] As mentioned above, part of the bootstrapping may be provided by a so-called bootstrapping configurator 10. In case a bootstrapping configurator 10 is used, the configurator (AP 2 or third device 9) may also run a bootstrapping service, which may be advertised using mDNS.

[0053] In a similar Figure 1 In the case of a local network, the server running in the device 2, 3 or 9 can actually be a local server. The inventors have recognized that there are problems with this situation.

[0054] A local server is a server that is not accessible from the global Internet but is confined to a local network in a restricted area (eg, confined to a building, a company's intranet, or a home).

[0055] The URL of a local server can sometimes be found when the local network supports a local DNS (Domain Name System) server that can translate URLs to local IP (Internet Protocol) addresses. Services can also be advertised on the network, for example, through mDNS (multicast DNS). In the case of an advertisement, devices on the network can browse for a service, for example, a printer service. The advertisement of a (printer) service should contain information about how to access and use the service by including, for example, the IP address of the service and the protocol to be used for the service or the port number that the service listens on.

[0056] This presents a problem if a server on the local network wants to use TLS or SSL to protect its services and requires a certificate. Obtaining a certificate from an (intermediate) CA means having to prove the correctness of the information that should be contained in the certificate. Proving the correctness of a local IP address or a local URL is difficult, since the (intermediate) CA has no access to these. In this case, the internal server can use a self-signed certificate, but how does the client (the boot configurator in the case of a DPP, or the device that wants to use the print service in the case of a printer) know whether this certificate can be trusted? Even if the local server is accessible from the outside (e.g. from the internet) in a certain way, obtaining a certificate may be cost-prohibitive, especially in a home environment.

[0057] This problem is particularly acute when the boot configurator is working with the network (and therefore with the local server) for the first time.The boot configurator needs to establish trust.

[0058] Figure 3 A process flow according to an embodiment is shown for the boot configurator to use a new boot service for the first time. The purpose of this process is to establish trust, and if the boot configurator aborts the following process, it will not use the boot service.

[0059] At S31, the process begins. The configurator 2 or 9 running the boot service has created a self-signed certificate, which may contain its IP address or URL and may indicate that it is for the boot service. Creating a self-signed certificate, other certificates, and certificates in a certificate chain may be done, for example, using openssl [OSSL]. The configurator 2 or 9 may also have created a root certificate for itself, whose public key is used to sign the certificate, which may contain its IP address or URL and may indicate that the certificate is for the boot service. The root certificate is the self-signed certificate at the top of the certificate chain.

[0060] In order to enable the user of the boot server (e.g., the boot configurator 10) to obtain trust in the certificate of the boot server when its repository of trusted certificates does not contain the certificate itself or its root certificate, the boot server can provide its certificate in an out-of-band (OOB) manner. It can, for example, put its certificate in a QR code and display the QR code in a specific way, for example, display it on a display or print it on its housing or in its manual. The self-signed certificate using Brainpool 512 requires about 1000 octets, which may seem like a lot of data for a QR code and does not look very intuitive. However, it still fits a QR code of version 25 (117*117). The certificate can also be made available through short-range communication technologies such as NFC or Bluetooth. In the next step, the credibility of the certificate of the boot service will be checked.

[0061] At S32, the boot configurator 10 helps the configurator (e.g., 2 or 9) that performs the boot to try to find the boot service of the configurator through mDNS. If the boot service is not found, the boot configurator terminates the process, otherwise it records the IP address or URL of the boot service.

[0062] At S33 , the boot configurator 10 scans the QR code of the device it thinks is running the boot service, or uses NFC touch, and obtains the certificate. An example of this device may be the local server 2 , 9 or 12 .

[0063] At S34, the configuration device 10 is guided to perform a signature check on the certificate. In the case where the certificate is part of a certificate chain, the signatures of all certificates in the certificate chain are checked, including the signature of the root certificate. If all signatures are correct, the configuration device continues to the next step, otherwise it stops at S39.

[0064] At S35, the boot configurator 10 checks whether the certificate is self-signed or part of a certificate chain, and checks whether the certificate (in the case of a self-signed certificate) or the root certificate is in its trusted certificate repository. If the certificate or the root certificate is actually in the repository, the process moves to S37, where the boot configurator 10 attempts to check that the certificate belongs to the boot server 2 or 9, otherwise the process continues to S36.

[0065] If the QR code contains a self-signed certificate, or it is part of a certificate chain and the certificate or root certificate is not in its trusted certificate repository, then at S36, the configurator attempts to determine whether the boot service is a local service. If it is a local service, the process proceeds to S37, otherwise it terminates at S39.

[0066] At S37, the boot configurator 10 attempts to find the URL or IP address or other information in the certificate and match it with the information from the mDNS advertisement of the boot service so found. If there is a match, the configurator trusts the boot service, the certificate, and the certificate belongs to the boot service provided by the server 2 or 9. The boot configurator 10 can store the certificate in its trusted certificate repository. This part of the process terminates at S38 and continues with the next steps of the configuration. If the match is unsuccessful, the configurator aborts the process at S39.

[0067] The following is an example of a method for checking whether the bootstrap service is a local service at S36 .

[0068] First, the boot configurator tries to get a response from the boot service. Possible ways of doing this are as follows:

[0069] The boot configurator attempts to get a response from the boot server with a request that definitely fails, so the response cannot cause harm, e.g., inject a virus into the boot configurator. This can be done, for example, using an HTTP GET to <IP address of the boot server> / <some large random string> (e.g.,

[0070] HTTP: / / 1192.169.0.1 / ksajfafaajhcbvjahfbejfjdfnjfdfvjj);

[0071] The boot configurator may also attempt to obtain a valid response from the boot service. However, in this case, it should be noted that the information in the server response is not used in any way, but only checked.

[0072] Once a response has been obtained, the boot configurator can check the hop count in the response. If it is low enough (e.g., less than 2), the boot service is considered to be a local service. The hop count is the total number of intermediate devices (e.g., routers) that the data must pass through from the source to the destination. A hop count of zero indicates that there are no intermediate devices or routers between the source and the destination. Alternatively or additionally, the boot configurator can time the response time. If it is low enough (e.g., less than one millisecond), the boot service is considered to be a local service.

[0073] exist Figure 2 Early execution of the process Figure 3 The process may be convenient, for example, in Figure 2 is executed before, as part of, or immediately after S2 in the process.

[0074] Understandably, Figure 3The process can also be used for other services besides the boot service. For example, in the case where the client device (PC 4) wants to print, mDNS can be used to search for the printer 3 running the print service. In the same way that the boot configurator 10 obtains and establishes trust in the certificate of the boot service provided by the configurator 2 or 9, the printer client (PC 4) can obtain and establish trust in the certificate of the print service of the printer 3.

[0075] Therefore, a method for obtaining trust in a server in a network by a client is described, the network including a server, the method comprising: obtaining a certificate of the server by the client; checking whether the root certificate of the certificate chain to which the certificate belongs is in a repository of trusted certificates, or checking whether the certificate itself is in a repository of trusted certificates if the certificate is a self-signed certificate; if the root certificate is not in the trusted repository, or the certificate itself is not in the trusted repository if the certificate is a self-signed certificate, checking whether the server is local to the network; and if the boot server is local to the network, adding the root certificate to the repository, or adding the certificate itself to the repository if the certificate is a self-signed certificate.

[0076] If the server is local, then the certification authority may not be accessible. However, in the local case, the server is under the control of the user and can therefore be provided with a degree of trust. By verifying that the server is local, the client can trust the server even in the absence of third-party certification and can therefore store the certificate. By storing the certificate in a repository of trusted certificates, the client will be able to identify the server in the future.

[0077] The server may be a boot server and the client may be a boot configurator. In this case, the method may be advantageously used for commissioning / configuration of devices in a network, wherein the boot uses a service running on a local server (boot server) for booting.

[0078] It may be useful to perform an ownership check on the certificate to verify whether the certificate belongs to the local server, and if so, continue execution of the method, otherwise abort execution of the method.

[0079] In the case where the client discovers that the server is not local, it is useful to terminate the method at this point because trust cannot be established. In the case where the server is local, it is considered trustworthy.

[0080] The server can be local and not connected to a certification authority. Even in this case, the method provides for the establishment of trust.

[0081] The client may perform a signature check on the certificate, and if the certificate is not a self-signed certificate, the client performs a signature check on all certificates in the certificate chain to which the certificate belongs, and if the result of the check is that at least one of the signatures is incorrect, the execution of the method is aborted. Unless all signatures of the available certificates are correct, the client cannot ensure whether even the local server can be trusted.

[0082] The certificate may be obtained through an out-of-band (OOB) method. The use of an OOB method increases the level of security because it allows the transmission of inherently sensitive (ie, should remain private to the legally involved devices) information to be exchanged before trust is established and encryption is performed.

[0083] The OOB method may involve a QR code or NFC.

[0084] Enrollees may be configured for communicating in a wireless network.

[0085] The bootstrapping of the enrollee may involve obtaining the enrollee bootstrapping information through an OOB method.

[0086] Once trust is established, the devices can proceed with executing the protocol according to the Wi-Fi Device Configuration Protocol.

[0087] The configurator device may be arranged to operate according to the method described above and the configurator device is further arranged to run a local server and to configure devices for communication in a wireless network.

[0088] The boot configurator device may be arranged to function according to the method described above and the boot configurator device is further arranged to obtain OOB boot registrant information and to transmit the registrant boot information to the boot service.

[0089] Aspects of the embodiments may be implemented in a computer program product, which may be a collection of computer program instructions that may be stored on a computer-readable storage device and may be executed by a computer. Instructions may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), or Java classes. Instructions may be provided as complete executable programs, partial executable programs, modifications (e.g., updates) to existing programs, or extensions (e.g., plug-ins) to existing programs. In addition, portions of the processing of the present invention may be distributed across multiple computers or processors.

[0090] Storage media suitable for storing computer program instructions include all forms of non-volatile memory, including but not limited to EPROM, EEPROM and flash memory devices, magnetic disks such as internal and external hard drives, removable disks and CD-ROM disks. The computer program product may be distributed on such storage media or may be provided for download via HTTP, FTP, email or through a server connected to a network such as the Internet.

[0091] The following documents can be used as reference:

[0092] [802.11] IEEE Computer Society, "IEEE Standard for Information Technology–Telecommunications and Information Exchange Between Systems–Localand Metropolitan Area Networks–Specific requirements Part 11: Wireless LANMedium Access Control (MAC) and Physical Layer (PHY) Specifications," (IEEEStd.802.11-2016), December 2016

[0093] [DH]Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEETransactions on Information Theory, 22(6):644–654

[0094] [DPP]Device Provisioning Protocol-Technical Specification-Version1.0, Wi-Fi Alliance, 2018, https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification.

[0095] [OSSL]https: / / www.openssl.org / .

[0096] [RD]The Resurrecting Duckling:Security Issues for Ad-Hoc WirelessNetworks,University of CambridgeComputer Laboratory,https: / / www.cl.cam.ac.uk / ~fms27 / papers / 1999-StajanoAnd-duckling.pdf

[0097] [RFC5297]Synthetic Initialization Vector(SIV)Authenticated EncryptionUsing the Advanced EncryptionStandard(AES),October 2008,(https: / / datatracker.ietf.org / doc / rfc5297 / )

Claims

1. A method for obtaining trust in a server in a network, the method being operated by a client, the method comprising: The client obtains the server's certificate; Checking whether a root certificate of a certificate chain to which the certificate belongs is in a repository of trusted certificates, or, if the certificate is a self-signed certificate, whether the certificate itself is in a repository of trusted certificates; If the root certificate is not in the trusted repository, or if the certificate is a self-signed certificate the certificate itself is not in the trusted repository, checking whether the server is local to the network; and adding the root certificate to the repository if the server is local to the network, or adding the certificate itself as a self-signed certificate to the repository if the certificate is a self-aligned certificate, and If the server is not local to the network, execution of the method is aborted.

2. The method according to claim 1, wherein: The server is a boot server and the client is a boot configurator.

3. The method according to claim 1 or 2, comprising: An ownership check of the certificate is performed to verify whether the certificate belongs to the server, and if the certificate belongs to the server, execution of the method continues, otherwise execution of the method is aborted.

4. A method according to any preceding claim, wherein: The server is not connected to a certification authority.

5. A method according to any preceding claim, comprising: The client performs a signature check on the certificate, and if the certificate is not a self-signed certificate, performs a signature check on all certificates in the certificate chain to which the certificate belongs, and if the result of the check is that at least one of the signatures is incorrect, the execution of the method is terminated.

6. A method according to any preceding claim, wherein: The certificate is obtained through an out-of-band (OOB) method.

7. The method according to claim 5, wherein: The OOB method involves a QR code or NFC.

8. A method according to any preceding claim, comprising: Configure enrollees for communicating in a wireless network.

9. The method according to claim 8, comprising: The registrant guidance information is acquired through the OOB method to guide the registrant.

10. A method according to any preceding claim, comprising: Executes a protocol according to the Wi-Fi device configuration protocol.

11. A configurator device arranged to perform the method according to claims 1-10, the configurator device being further arranged for running a server and configuring a device for communication in a wireless network.

12. A boot configurator device arranged to perform the method according to claims 1-10, said boot configurator device being further arranged for obtaining OOB boot registrant information and transmitting said registrant boot information to a boot service.

13. A computer program product arranged, when run on a computer processor, to cause the computer to perform the method of claims 1-10.

Images