System and method for connecting client devices to a network

CROSS-REFERENCE TO RELATED APPLICATIONS

0001The present application claims priority from U.S. Provisional Application No. 61/605,598 filed on Mar. 1, 2012 incorporated herein by reference.

TECHNICAL FIELD

0002The following relates to systems and methods for connecting client devices to a network.

DESCRIPTION OF THE RELATED ART

0003In networked environments, client devices that wish to join a network first find a network and then join that found network. Acceptance to a network is typically performed by a router, server, or other network controller or access device, hereinafter referred to as a “trust center”. In some networked environments, the client devices joining and communicating over the network operate using little or no user interfaces. Despite the limited interfaces of such client devices, the client device should be able to not only join a network, but join the correct network. Similarly, the trust center should be able to allow only acceptable client devices to join its network.

0004Networks such as home area networks (HAN) may utilize a security negotiation protocol such as the transport layer security (TLS) protocol or its predecessor, the Secure Sockets Layer (SSL) protocol, as the underlying security protocol for the network. The TLS protocol is a well known communication protocol that provides communications privacy and data integrity, and allows client/server applications to communicate in a way that is designed to prevent or inhibit eavesdropping, tampering, and message forgery.

0005In environments where the TLS or SSL protocols are used, including environments where client devices are provisioned with a digital certificate (“certificate” hereinafter), it can be difficult to indicate to the joining client device which network and trust center it should join. It can also be difficult to extract information from the joining client device and access the trust center to limit which client devices should be joining. Such difficulties are often referred to as the “steering problem”.

0006To address steering problems, the typical model is to provide the trust center with a small amount of identifying information about a client device that will be joining the network. Typically, the identifying information should be in a form that allows for easy human input by either a terminal or keypad. Once this information is known at the trust center, the trust center goes into an “allow joining” mode. At this time, the certified joining client device can prove that it is the device associated with the identifying information and is allowed to join the network.

0007A security concern with this model is that a rogue trust center could accept joining in a promiscuous mode, thus tricking a joining client device into joining the wrong network. Another security concern is that a rogue client device could attempt to join the network via the trust center during the allow joining phase and before the intended device is able to join.

BRIEF DESCRIPTION OF THE DRAWINGS

0008Embodiments will now be described by way of example only with reference to the appended drawings wherein:

0009<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a communication system including a networked environment;

0010<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram of a communication system including a home network;

0011<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating an example of a configuration for a client device in the networked environment;

0012<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating an example of a configuration for a trust center in the networked environment;

0013<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating an internet protocol (IP) stack used in the networked environment;

0014<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in providing an authentication code (AUTHCODE) to a trust center via an out-of-band channel;

0015<figref idref="DRAWINGS">FIG. 7</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing a TLS handshake;

0016<figref idref="DRAWINGS">FIG. 8</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing a TLS handshake;

0017<figref idref="DRAWINGS">FIG. 9</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing a TLS handshake;

0018<figref idref="DRAWINGS">FIG. 10</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing a TLS handshake;

0019<figref idref="DRAWINGS">FIG. 11</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing key material exporters for TLS;

0020<figref idref="DRAWINGS">FIG. 12</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in verifying an AUTHCODE post TLS establishment; and

0021<figref idref="DRAWINGS">FIG. 13</figref> is a flow chart illustrating an example of a set of computer executable operations that may be performed in using the AUTHCODE in performing a modified TLS establishment.

DETAILED DESCRIPTION

0022It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the examples described herein. However, it will be understood by those of ordinary skill in the art that the examples described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the examples described herein. Also, the description is not to be considered as limiting the scope of the examples described herein.

0023It will be appreciated that the examples and corresponding diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles.

0024In order to address the steering problem in networked environments that provide communication security, authorization codes (AUTHCODEs) for particular client devices are established in both the trust center and the joining client devices, and the AUTHCODEs are incorporated in at least one operation used in a security negotiation between the respective joining client device and the trust center. The AUTHCODE enables the trust center to identify the correct joining device and the joining devices to identify the correct trust center and thus obtain assurance that they have joined the correct network.

0025It can be appreciated that the principles discussed below may be utilized in various security negotiation protocols in which the AUTHCODE can be provided to the trust center out-of-band and such AUTHCODE can be used in at least one cryptographic operation utilized by the underlying security negotiation protocol. Examples include, without limitation, various TLS protocol versions including predecessor SSL versions and Datagram TLS (DTLS), IPSec, etc. Various examples provided herein illustrate these principles in a networked environment utilizing a version of the TLS or SSL protocols, hereinafter referred to as the “TLS protocol” for illustrative purposes.

0026In one example scenario, a client device may establish a TLS session with a trust center wherein both the client device and the trust center have a certified signing key (e.g., an Elliptic Curve Digital Signature Algorithm (ECDSA) signing key) from a certificate authority (CA) recognized by each other. Prior to accepting a session, the trust center is given an out-of-band AUTHCODE. The TLS protocol to be used during a joining phase is modified to utilize the AUTHCODE. In this scenario it is assumed that the legitimate trust center and each legitimate client device, as well as any rogue client device has, or is otherwise capable of having, a valid certificate containing a public key suitable for ECDSA signing, and is in possession of a corresponding private key. It is also assumed that all joining client devices have an associated AUTHCODE. The AUTHCODE may be provided on or with the client device in various ways, including, being printed on the exterior of the device (e.g., on the back of a housing), in associated packaging material, etc. The AUTHCODE is a randomly generated value that is meant to be provided to the trust center out-of-band and thus not transmitted over network being joined.

0027Referring now to <figref idref="DRAWINGS">FIG. 1</figref> a networked environment <b>10</b> including a local network <b>12</b> is shown. Access to the local network <b>12</b> for at least some devices, is managed by a trust center <b>14</b>. It can be appreciated that the trust center <b>14</b> may represent any router, server, or other network controller or access device responsible for permitting or denying access to the local network <b>12</b> for client devices. In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, two types of client devices are shown, registered client devices <b>16</b> and joining client devices <b>18</b>. Registered client devices <b>16</b> include client devices that have successfully joined the local network <b>12</b> by registering with the trust center <b>14</b>. Joining client devices <b>18</b> include client devices that are attempting to join the local network <b>12</b> by registering with the trust center <b>14</b>. It can be appreciated that joining client devices <b>18</b> may include both legitimate and rogue client devices.

0028The registered client devices <b>16</b> and joining client devices <b>18</b> each include an AUTHCODE <b>20</b> that can be ascertained from the device itself, e.g., from an exterior portion thereof. In order to have the AUTHCODE <b>20</b> used in at least one TLS operation, an out-of-band channel <b>22</b> is established between the joining client device <b>18</b> and the trust center <b>14</b>. The out-of-band channel <b>22</b> is shown as being within the networked environment <b>10</b>, however, the out-of-band channel <b>22</b> may also be established outside of the network environment <b>10</b>. The out-of-band channel <b>22</b> may include, for example, a user interface provided by the trust center <b>14</b> which enables manual entry of the AUTHCODE <b>20</b> into the trust center <b>14</b> or a database or memory controlled by or otherwise accessible to the trust center <b>14</b>. The out-of-band channel <b>22</b> may also be established using a telephone or web-based connection with an administrator <b>26</b> associated with the trust center <b>14</b> thus enabling the AUTHCODE <b>20</b> to be provided by a user of the joining client device <b>18</b> when attempting to add the joining client device <b>18</b> to the local network <b>12</b>. In this way, the administrator <b>26</b> may push the AUTHCODE <b>20</b> down to the trust center <b>14</b> via an external network such as the wide network <b>24</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. The administrator <b>26</b> or trust center <b>14</b> or both the administrator <b>26</b> and trust center <b>14</b> may also communicate with a certificate authority (CA) <b>28</b> over the wide network <b>24</b> for obtaining certificates used, for example, in the TLS protocol. Where certificates are used, the registered and joining client devices <b>16</b>, <b>18</b> also include certified signing keys and thus may also be communicable with the CA <b>28</b> over the wide network <b>24</b>. It can be appreciated that in other examples, the client devices <b>16</b>, <b>18</b> may not utilize certificates obtained from a CA <b>28</b>. For example, the client devices <b>16</b>, <b>18</b> may utilize self-signed certificates or unsigned public keys, and the AUTHCODE <b>20</b> may be used to authenticate such client devices <b>16</b>, <b>18</b> to the trust center <b>14</b>.

0029An example of a networked environment <b>10</b> is shown in <figref idref="DRAWINGS">FIG. 2</figref>. <figref idref="DRAWINGS">FIG. 2</figref> illustrates a household environment <b>10</b>′ that includes a home area network (HAN) <b>12</b>′, e.g., for a smart home system or advanced metering infrastructure (AMI). The HAN <b>12</b>′ in this example is controlled by a managed service portal <b>14</b>′, which permits utility registered client devices <b>16</b>′ to communicate with the HAN <b>12</b>′ and permits or denies access to utility joining client devices <b>18</b>′. The client devices <b>16</b>′, <b>18</b>′ may include, for example, electronic thermostats, large home appliances, HVAC systems, etc. The client devices <b>16</b>′, <b>18</b>′ include AUTHCODEs <b>20</b> and provide the AUTHCODEs <b>20</b> to the managed service portal <b>14</b>′ via an out-of-band channel <b>22</b>′, similar to that described above. The managed service portal <b>14</b>′ communicates with a utility backend server <b>26</b>′ via a utility AMI network <b>24</b>′. The utility backend server <b>26</b>′ is responsible for communicating with the managed service portal <b>14</b>′ and passes information regarding utility joining devices <b>18</b>′ and initiates the joining period for adding such joining devices <b>18</b>′. The utility backend server <b>26</b>′ may also communicate with a CA <b>28</b>′ in order to obtain certified signing keys for the managed service portals <b>14</b>′ that are used by the utility. The managed service portals <b>14</b>′ may also be installed with certificates already stored therein via a procurement practice. The utility backend server <b>26</b>′ may then look up signing/identity information of the utility joining device <b>18</b>′ joining the managed service portal <b>14</b>′ to ensure the certificate has not been revoked.

0030An example of a configuration for a client device <b>16</b>, <b>18</b> is shown in <figref idref="DRAWINGS">FIG. 3</figref>. The client device <b>16</b>, <b>18</b> includes a body, housing or other physical portion providing an exterior surface <b>30</b> on which the AUTHCODE <b>20</b> may be printed or otherwise made visible to a user. The client device <b>16</b>, <b>18</b> also includes a local network interface <b>32</b> to enable a processor <b>34</b> to communicate with the local network <b>12</b>, e.g., using a TLS protocol <b>36</b>. The TLS protocol <b>36</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> represents any computer executable instructions that operate the processor <b>34</b> to enable the client device <b>16</b>, <b>18</b> to participate in TLS operations, such as a TLS handshake, a TLS application phase, etc. The client device <b>16</b>, <b>18</b> also includes a memory <b>38</b> for storing data. In this example, the memory <b>38</b> stores a private/public key pair (c, C) of the client device <b>16</b>, <b>18</b>, and a public key T of the trust center <b>14</b>. The memory <b>38</b> also stores an electronic version or representation of the AUTHCODE <b>40</b> to enable the AUTHCODE <b>20</b> printed on the exterior surface <b>30</b> of the client device <b>16</b>, <b>18</b> to be used in TLS operations.

0031<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example of a configuration for the trust center <b>14</b>. The trust center <b>14</b> in this example includes a processor <b>50</b>, a local network interface <b>52</b> for communicating via the local network <b>12</b>, and a wide network interface <b>54</b> for communicating via the wide network <b>24</b>. It can be appreciated that the local network interface <b>52</b> and wide network interface <b>54</b> are shown as separate components for illustrative purposes only and that a single network interface module may be used. The processor <b>50</b> has access to the TLS protocol <b>56</b> and has access to a memory <b>58</b>. The memory <b>58</b> stores a private/public key pair (t, T) of the trust center <b>14</b>. The memory <b>58</b> also stores public keys C of the client devices <b>16</b>, <b>18</b>, which are typically provided to the trust center <b>14</b> during execution of the security negotiation protocol, e.g., using a certificate. The trust center <b>14</b> also includes or otherwise has access to a client device AUTHCODE database <b>60</b> for storing electronic versions or representations of AUTHCODES <b>40</b> of the registered client devices <b>16</b> and those joining client devices <b>18</b> that have utilized the out-of-band channel <b>22</b>.

0032Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, the TLS protocol may be modified using the AUTHCODE <b>40</b> by providing the AUTHCODE <b>20</b> from the client device <b>16</b>, <b>18</b> to the trust center <b>14</b> at <b>500</b> using the out-of-band channel <b>22</b>. For example, when a user wishes to add a new joining client device <b>18</b> to the local network <b>12</b>, a user interface provided by the trust center <b>14</b> may be accessed and the representation of the AUTHCODE <b>40</b> entered into the user interface. The joining client device <b>18</b> may then initiate a TLS session with the trust center <b>14</b> at <b>502</b>. The AUTHCODE <b>40</b> stored by the joining client device <b>18</b> is then used in one or more TLS operations at <b>504</b>, examples of which are provided below. Assuming the trust center <b>14</b> has successfully obtained and utilized the same AUTHCODE <b>40</b> stored in the AUTHCODE database <b>60</b>, the joining client device <b>18</b> is permitted to access the local network <b>12</b> at <b>506</b> using the established secure channel, and thereafter the trust center <b>14</b> treats the joining client device <b>18</b> as a joined client device <b>16</b> thus providing access to, for example, network resources, etc. Similarly, the joined client device <b>16</b> now has assurance that the joined client device <b>16</b> has joined the correct trust center <b>14</b>.

0033<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of a set of operations that may be performed in enabling a trust center <b>14</b> and joining client device <b>18</b> to participate in a TLS handshake. At <b>600</b>, the CA <b>28</b> generates a certificate for the trust center <b>14</b> and provides the certificate to the trust center <b>14</b> at <b>602</b>, and the trust center obtains the certificate at <b>604</b>. It can be appreciated that operations <b>600</b>-<b>604</b> are optional depending on whether certificates are used and the certificate being issued to the trust center <b>14</b> may be provided using any suitable certificate fulfillment process, which may include a certificate revocation check or verification of the certificate. The joining client device <b>18</b> is introduced into the networked environment <b>10</b> at <b>606</b> and the AUTHCODE <b>20</b> provided on the exterior surface <b>30</b> of the joining client device <b>18</b> is determined at <b>608</b>. The out-of-band channel <b>22</b> is established at <b>610</b>, which is enabled by the trust center <b>14</b> at <b>612</b>. For example, the trust center <b>14</b> may provide a browser-based user interface to enable the AUTHCODE <b>20</b> to be entered. The AUTHCODE <b>20</b> is provided at <b>614</b> and received by the trust center <b>14</b> at <b>616</b>. The representation of the AUTHCODE <b>40</b> is stored in the AUTHCODE database <b>60</b> by the trust center <b>14</b> at <b>618</b>. The trust center <b>14</b> then initiates the allow joining phase for the joining client device <b>18</b> associated with the stored AUTHCODE <b>40</b> at <b>620</b>. Once the allow joining phase has been initiated, the joining client device <b>18</b> may initiate a TLS session at <b>622</b> and participate in a TLS handshake to register the joining client device <b>18</b>. The trust center <b>14</b> also participates in the TLS handshake at <b>624</b>.

0034<figref idref="DRAWINGS">FIG. 7</figref> illustrates a set of computer executable operations that may be performed by a joining client device <b>18</b> or the trust center <b>14</b> in using the AUTHCODE <b>40</b> provided to the trust center <b>14</b> via the out-of-band channel <b>22</b>. At <b>700</b> a stored AUTHCODE <b>40</b> associated with the joining client device <b>18</b> that has initiated the TLS session, is obtained from memory <b>38</b>, <b>60</b>. The AUTHCODE <b>40</b> is used in one or more TLS operations at <b>702</b> and the TLS handshake is completed at <b>704</b>.

0035It can be appreciated that there exist various TLS-based mechanisms for performing the TLS handshake. As such, when applied to applications using TLS or SSL, there are various ways in which the AUTHCODE <b>40</b> may be used in addressing the aforementioned steering problem. The following provides several examples in which the AUTHCODE <b>40</b> is used in one or more TLS operations to encourage the correct joining client device <b>18</b> to communicate and register with the correct trust center <b>14</b> and thus join the correct local network <b>12</b>. In the following examples, it may be assumed that the TLS protocol being used includes a key exchange algorithm such as those described in the Elliptic Curve Cryptography (ECC) Cipher Suites for TLS RFC 4492 document. The following examples may utilize the Ephemeral Elliptic Curve Diffie Hellman with ECDSA (ECDHE_ECDSA) key exchange algorithm. However, it can be appreciated that the principles discussed herein also apply to other key exchange algorithms such as ECDH_ECDSA, ECDH_RSA, ECDHE_RSA, etc. wherein the client devices <b>16</b>, <b>18</b> and trust center <b>14</b> can derive a final session key from the AUTHCODE <b>40</b>.

0036Referring now to <figref idref="DRAWINGS">FIG. 8</figref>, an example is shown wherein the random value included in a ClientHello message used during a TLS handshake is substituted by the joining client device <b>18</b> with the AUTHCODE <b>40</b>. As is well known in the art, the ClientHello message in a TLS handshake is sent during the negotiation phase and is sent by the client to specify the highest TLS protocol version the client supports, and to provide a random number, a list of suggested cipher suites, and compression methods. For the example shown in <figref idref="DRAWINGS">FIG. 8</figref>, it may be assumed that when performing ECDHE_ECDSA in TLS, the ClientHello.random value does not contribute to the overall security of the TLS session. It has been recognized that the ClientHello.random value can be repurposed as evidence of knowledge of the AUTHCODE <b>40</b>, and further that the AUTHCODE <b>40</b> can be substituted for the ClientHello.random value in the generation of the master_secret and key_block operations during the TLS handshake.

0037Assuming that both the joining client device <b>18</b> and the trust center <b>14</b> have the AUTHCODE <b>40</b>, i.e. AUTHCODE <b>20</b> has been transmitted or otherwise provided to the trust center <b>14</b> via the out-of-band channel <b>22</b>, after the joining client device <b>18</b> initiates the TLS session, the joining client device <b>18</b> transforms the AUTHCODE <b>40</b> at <b>800</b> using a HASH function, e.g., the cryptographic hash utilized by the TLS session. The joining client device <b>18</b> then generates a ClientHello message at <b>802</b> using the hash of the AUTHCODE <b>40</b> as the ClientHello.random value and sends the ClientHello message to the trust center <b>14</b> at <b>804</b>. The trust center <b>14</b> receives the ClientHello message at <b>806</b> and compares the ClientHello.random value in the message to a hash of the AUTHCODE <b>40</b> generated by the trust center <b>14</b> at <b>808</b>.

0038The trust center <b>14</b> determines if there is a match at <b>810</b>. If the compared values differ, the TLS session is halted with an error at <b>812</b> and the process is terminated. If the compared values match, the trust center <b>14</b> executes the remaining portions of the TLS handshake at <b>814</b> using the AUTHCODE <b>40</b> internally during computation of the master_secret and key_block. The joining client device <b>18</b> also executes the remaining TLS handshake operations at <b>816</b> using the AUTHCODE <b>40</b> instead of the ClientHello.random value internally during the computation of the master_secret and key_block. Accordingly, the TLS handshake will complete successfully and enter the application phase at <b>818</b> and <b>820</b> only if the trust center <b>14</b> knows the AUTHCODE <b>40</b> and uses the AUTHCODE <b>40</b> in performing the master_secret and key_block computations as noted above.

0039Referring now to <figref idref="DRAWINGS">FIG. 9</figref>, an example is shown wherein the random value included in a ServerHello message used during a TLS handshake is substituted by the trust center <b>14</b> with the AUTHCODE <b>40</b>. As is well known in the art, the ServerHello message in a TLS handshake is sent as a response to the ClientHello message during the negotiation phase and is sent by the server to specify the chosen TLS protocol version, and to provide a random number, a cipher suite, and compression method from the choices offered by the client. For the example shown in <figref idref="DRAWINGS">FIG. 9</figref>, it may be assumed that when performing ECDHE_ECDSA in TLS, the ServerHello.random value does not contribute to the overall security of the TLS session. It has been recognized that the ServerHello.random value can be repurposed as evidence of knowledge of the AUTHCODE <b>40</b>, and further that the AUTHCODE <b>40</b> can be substituted for the ServerHello.random value in the generation of the master_secret and key_block operations during the TLS handshake.

0040Assuming that both the joining client device <b>18</b> and the trust center <b>14</b> have the AUTHCODE <b>40</b>, i.e. AUTHCODE <b>20</b> has been transmitted or otherwise provided to the trust center <b>14</b> via the out-of-band channel <b>22</b>, after the joining client device <b>18</b> initiates the TLS session, the joining client device <b>18</b> sends a ClientHello message to the trust center <b>14</b> at <b>900</b>, which is received by the trust center <b>14</b> at <b>902</b>. The trust center <b>14</b> transforms the AUTHCODE <b>40</b> at <b>904</b> using a HASH function, e.g., the cryptographic hash utilized by the TLS session. The trust center <b>14</b> then generates a ServerHello message at <b>906</b> using the hash of the AUTHCODE <b>40</b> as the ServerHello.random value and sends the ServerHello message to the joining client device <b>18</b> at <b>908</b>. The joining client device <b>18</b> receives the ServerHello message at <b>910</b> and compares the ServerHello.random value in the message to a hash of the AUTHCODE <b>40</b> generated by the joining client device <b>18</b> at <b>912</b>.

0041The joining client device <b>18</b> determines if there is a match at <b>914</b>. If the compared values differ, the TLS session is halted with an error at <b>916</b> and the process is terminated. If the compared values match, the joining client device <b>18</b> executes the remaining portions of the TLS handshake at <b>918</b> using the AUTHCODE <b>40</b> internally during computation of the master_secret and key_block. The trust center <b>14</b> also executes the remaining TLS handshake operations at <b>920</b> using the AUTHCODE <b>40</b> as the ServerHello.random value internally during the computation of the master_secret and key_block. Accordingly, the TLS handshake will complete successfully and enter the application phase at <b>922</b> and <b>924</b> only if the joining client device <b>18</b> knows the AUTHCODE <b>40</b> and substitutes the AUTHCODE <b>40</b> into the master_secret and key_block computations as noted above.

0042Referring now to <figref idref="DRAWINGS">FIG. 10</figref>, it is also recognized that the AUTHCODE <b>40</b> can be used to create a second base point for an ECDHE computation without affecting the overall security of the TLS session. The second base point may therefore be used to form the pre_master_secret in the TLS handshake. In the example shown in <figref idref="DRAWINGS">FIG. 10</figref>, a negotiated ECDHE value Q may be modified by an additional scalar multiplication, namely: AUTHCODE*Q, wherein AUTHCODE is interpreted as an integer modulo the order of the base point of the elliptic curve group in which the TLS session is operating.

0043The joining client device <b>18</b> and trust center <b>14</b> execute one or more initial TLS handshake operations at <b>1000</b> and <b>1002</b> respectively, according to the TLS algorithm being used. For example, the joining client device <b>18</b> and trust center <b>14</b> may exchange ClientHello and ServerHello messages, certificate and certificate request messages, etc. At <b>1004</b> the joining client device <b>18</b> modifies the secret elliptic curve point Q by computing Q′=AUTHCODE*Q. As noted above, the AUTHCODE <b>40</b> is interpreted as an integer modulo the order of the elliptic curve group in which the TLS session is operating. The joining client device <b>18</b> then forms the pre_master_secret at <b>1006</b> using the x-coordinate of Q′ and executes any remaining TLS handshake operations at <b>1008</b> wherein the TLS handshake will complete successfully only if the trust center <b>14</b> also knows the AUTHCODE <b>40</b> and modifies the shared secret elliptic curve point Q in a similar fashion.

0044As such, at <b>1010</b> the trust center <b>14</b> modifies the secret elliptic curve point Q by computing Q′=AUTHCODE*Q. As noted above, the AUTHCODE <b>40</b> is interpreted as an integer modulo the order of the elliptic curve group in which the TLS session is operating. The trust center <b>14</b> then forms the pre_master_secret at <b>1012</b> using the x-coordinate of Q′ and executes any remaining TLS handshake operations at <b>1014</b> wherein the TLS handshake will complete successfully only if the joining client device <b>18</b> also knows the AUTHCODE <b>40</b> and modifies the shared secret elliptic curve point Q in a similar fashion.

0045Assuming the TLS handshake is successful, the joining client device <b>18</b> and trust center <b>14</b> enter the TLS application phase at <b>1016</b> and <b>1018</b> respectively.

0046As defined in, for example, RFC 5705, additional cryptographic keys may be extracted from a negotiated TLS session. Referring to <figref idref="DRAWINGS">FIG. 11</figref>, it is recognized that the keying material exporters for TLS methods can be modified to provide a solution to the steering problem by having the client and server prove knowledge of the AUTHCODE <b>40</b> by exchanging output of the PRF( )function after negotiating a TLS session. At <b>1100</b> and <b>1102</b> the joining client device <b>18</b> and trust center <b>14</b> respectively participate in the establishment of a TLS session by performing a TLS handshake, e.g., using the ECDHE_ECDSA key exchange algorithm. At <b>1104</b> the joining client device <b>18</b> generates the export operation defined in RFC 5705 by adding the AUTHCODE <b>40</b> into the PRF( )function as either part of the “label” value or part of the “context” value. As is well known in the art, if no context is provided, the PRF( ) function computes: PRF(master_secret, label, client_random+server_random) [length], wherein PRF( )is a TLS pseudorandom function in used in the session. If context is provided, the PRF( )function computes: PRF(master_secret, label, client_random+server_random+context_value_length+context_value) [length] The output of PRF( )is a pseudorandom bit string of [length] bytes generated from the master secret.

0047The joining client device <b>18</b> parses the output into two distinct data elements at <b>1106</b> as: SERVER_PROOF∥CLIENT_PROOF=PRF(master_secret, label, client_random+server_random+context_value_length+context value)[length] and sends CLIENT_PROOF at <b>1108</b>. Meanwhile, the trust center <b>14</b> also generates the export operation defined in RFC 5705 by adding the AUTHCODE <b>40</b> into the PRF( )function as either the “label” value or “context” value at <b>110</b>, labels the output at <b>1112</b> as: SERVER_PROOF∥CLIENT_PROOF=PRF(master_secret, label, client_random+server_random+context_value_length+context value)[length].

0048The trust center <b>14</b> receives CLIENT_PROOF at <b>1114</b> and, after receiving CLIENT_PROOF, compares the received CLIENT_PROOF to the CLIENT_PROOF value computed using the relationship discussed above at <b>1116</b>. The trust center <b>14</b> determines at <b>1118</b> whether or not these values match. If the compared values differ, the TLS session is halted with an error at <b>1120</b> and it is assumed that the joining client device <b>18</b> is incorrect. If the compared values match, the trust center <b>14</b> determines that the correct client has joined at <b>1122</b> and sends SERVER_PROOF to the joining client device <b>18</b> at <b>1124</b>.

0049The joining client device <b>18</b> receives SERVER_PROOF at <b>1126</b> and, after receiving SERVER_PROOF, compares the received SERVER_PROOF to the SERVER_PROOF value computed as discussed above at <b>1128</b>. The joining client device <b>18</b> determines at <b>1130</b> whether or not these values match. If the compared values differ, the TLS session is halted with an error at <b>1132</b> and it is assumed that the joining client device <b>18</b> has joined the wrong network. If the compared values match, the joining client device <b>18</b> determines that it has joined the correct local network <b>12</b> at <b>1134</b>.

0050It can be appreciated that the principles discussed above can be applied to other security negotiation protocols, including various TLS- and SSL-based key agreement schemes, e.g., TLS_RSA_WITH_RC4_—128_SHA, TLS_RSA_WITH_AES_—256_CBC_SHA, etc. Additionally, the AUTHCODE <b>40</b> may also be mixed into either the master_secret or key_block computations by, for example, appending or exclusive-ORing the AUTHCODE <b>40</b> to the master_secret before deriving the key_block as described in section 6.3 of RFC 2246.

0051It can also be appreciated that due to the nature of the tasks required for printing, reading, and entering codes, it may not be practical to have the AUTHCODE <b>40</b> include sufficient entropy or randomness, which may result in the space of valid AUTHCODES <b>40</b> being an exhaustible set. In such cases, an attacker could perform a dictionary attack by populating a database of values corresponding to HASH(AUTHCODE), and wait for a ClientHello message and look up the correct AUTHCODE for the detected hash value. This can be partially thwarted by salting the HASH output. For example, the ClientHello.random value could be broken into two sections, ClientHello.random=SALT∥HASH(SALT∥AUTHCODE), where SALT is a randomly generated value of sufficient size, e.g., large enough to prevent a dictionary of values “SALT∥HASH(SALT∥AUTHCODE)” from being created, for all values of (SALT, AUTHCODE). For example, setting SALT to be an 80-bit random value may be sufficient for several applications. While this salting technique may protect against a dictionary attack, the lower entropy AUTHCODE <b>40</b> in such situations may still be vulnerable to a brute force attack where the attacker observes a legitimate join and the value ClientHello.random=SALT∥HASH (SALT∥AUTHCODE), and goes offline to compute HASH(SALT∥AUTHCODE) until the correct AUTHCODE <b>40</b> is found. It has been recognized that the methods shown in <figref idref="DRAWINGS">FIGS. 8 to 11</figref> may be vulnerable to one or both of the dictionary and brute force attacks when the AUTHCODE <b>40</b> has insufficient randomness.

0052To address these possible attacks, an additional modification to the TLS protocol, and an additional post TLS session establishment verification will now be described, which can be based on password-based key agreement schemes as described in IEEE 1363.2 and secure remote password usage.

0053Referring now to <figref idref="DRAWINGS">FIG. 12</figref>, a method of verifying the AUTHCODE <b>40</b> over an established TLS session during a join process is shown. The method illustrated in <figref idref="DRAWINGS">FIG. 12</figref> establishes a TLS connection between the joining client device <b>18</b> and the trust center <b>14</b> at <b>1200</b> and <b>1202</b> respectively, then performs a password-based key agreement protocol with key confirmation, e.g., EC-SPEKE as specified in IEEE 1363.2.

0054At <b>1204</b> the joining client device <b>18</b> generates a base point Q on an elliptic curve by computing: Q=f (HASH(ClientID∥“.”∥ (ClientHello.random∥ServerHello.random∥AUTHCODE))), where f is a suitable function that takes the output of the HASH and maps it to an elliptic curve point on the desired curve. The joining client device <b>18</b> then generates a random value a and computes Q_A=aQ at <b>1206</b>. Q_Ais then sent to the trust center <b>14</b> at <b>1208</b>. The trust center <b>14</b> also generates Q in same way as the joining client device <b>18</b> at <b>1210</b>, generates a random value b and computes Q_B=bQ at <b>1212</b>. The trust center <b>14</b> receives Q_Aat <b>1214</b> and computes K=KDF(bQ_A) at <b>1216</b>. It can be appreciated that KDF is a suitable key derivation function, such as the KDFs described in IEEE 1363.2. The trust center <b>14</b> then generates the block SERVER_PROOF∥CLIENT_PROOF=PRF (K, (other information, e.g., ClientHello.random, ServerHello.random, etc.)). For example, the block may include the following format: SERVER_PROOF∥CLIENT_PROOF=PRF(master_secret, label, client_random+server_random+context_value_length+context value)[length] as used above. The trust center <b>14</b> sends Q_Band SERVER_PROOF to the joining client device <b>18</b> at <b>1236</b>.

0055The joining client device <b>18</b> receives Q_Band SERVER_PROOF at <b>1222</b> and generates K=KDF(aQ_B) at <b>1224</b>. The joining client device <b>18</b> then generates the block SERVER_PROOF∥CLIENT_PROOF=PRF (K, (other information, e.g., ClientHello.random, ServerHello.random, etc.)) at <b>1226</b>. For example, the block may include the following format: SERVER_PROOF∥CLIENT_PROOF=PRF(master_secret, label, client_random+server_random+context_value_length+context value)[length] as used above. The joining client device <b>18</b> compares the received SERVER_PROOF with that computed from the block at <b>1228</b>. The joining client device <b>18</b> determines at <b>1230</b> whether or not these values match. If not, the session is halted and indicating an error at <b>1232</b>. If the SERVER_PROOF values match, the joining client device <b>18</b> sends CLIENT_PROOF to the trust center <b>14</b> at <b>1234</b>, which is received by the trust center <b>14</b> at <b>1238</b>. The trust center <b>14</b> compares the received CLIENT_PROOF with that computed from the block at <b>1240</b> and determines at <b>1242</b> whether or not these values match. If not, the connection is dropped indicating an error at <b>1244</b>. If the CLIENT_PROOF values match, the joining client device <b>18</b> is allowed to join the local network <b>12</b> at <b>1246</b>.

0056Referring now to <figref idref="DRAWINGS">FIG. 13</figref> a method of verifying the AUTHCODE during the establishment of a TLS session during a join process. It has been recognized that the base point being used in the ECDH scheme of the TLS session can be modified in order to verify the AUTHCODE and may use a password-based key agreement protocol to directly establish the TLS session key. The TLS session is successful only if the AUTHCODE <b>40</b> used by both endpoints is the same.

0057As shown in <figref idref="DRAWINGS">FIG. 13</figref>, after participating in establishing a TLS session at <b>1300</b> and <b>1302</b> respectively, the joining client device <b>18</b> and the trust center <b>14</b> may generate a new base point Q at <b>1304</b> and <b>1308</b> respectively. The new base point is to be used in an ECDH operation where Q=f (HASH(AGREED_UPON_STRING∥“.” (ClientHello.random)∥(ServerHello.random∥AUTHCODE))), where f is a suitable function that takes the output of HASH and generates an elliptic curve point on the TLS-negotiated curve.

0058The client used the base point Q as the base point in an ECDHE key exchange at <b>1306</b> and the trust center <b>14</b> likewise uses Q at <b>1310</b>.

0059It can be appreciated that the above-described principles may also be used with Datagram TLS (DTLS) given the similarities between the two solutions. The DTLS protocol secures UDP network communications and was designed to be similar to TLS, in order to keep most protocol messages the same, allowing many of the same TLS cipher suites to be used with DTLS. Some machine-to-machine networks such as those shown in <figref idref="DRAWINGS">FIGS. 1 and 2</figref> may use UDP and DTLS. One example application layer protocol designed for such environments is CoAP, which aims to provide an HTTP-like protocol over UDP, and is secured with DTLS. When CoAP is secured with a “certificate mode”, i.e. security is provided with certificates, the steering problem described above may be present. As such, the principles discussed herein may be applied to address such a steering problem.

0060Similarly, as noted above, the AUTHCODE <b>40</b> may also be used in other security negotiation protocols such as IPSec. For example, the key agreement protocol used in IPSec may be modified by modifying the internet key exchange (IKE) to include the AUTHCODE in the key derivation step (described in section 2.13 of RFC 4306, for IKE v2).

0061Accordingly, there is provided a method of enabling a client device to connect to a network, the method comprising: obtaining an authorization code via a communication channel different from the network, the authorization code corresponding to the client device; and after detecting initiation of a security negotiation protocol by the client device, using the authorization code in at least one security negotiation operation.

0062There is also provided a method of connecting to a network, the method comprising: the client device initiating a security negotiation protocol with a server device for the network; and using an authorization code in at least one security negotiation operation, the authorization code having been provided to the server device via a communication channel different from the network, the authorization code corresponding to the client device.

0063There is also provided a method of enabling a client device to connect to a network, the method comprising: providing an authorization code to the client device via a communication channel different from the network, the authorization code corresponding to the client device; and after detecting initiation of a security negotiation protocol by the client device, using the authorization code in at least one security negotiation operation.

0064There are also provided computer readable media comprising instructions for performing the above methods, and client and server devices configured for performing the above methods.

0065It will be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the **, any component of or related to the **, etc., or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.

0066The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the principles discussed above. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

0067Although the above principles have been described with reference to certain specific examples, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.