Patent Description:
It is with respect to these and other considerations that the present improvements have been needed.

<CIT> discloses a system in which a representation of first data comprising a password is generated at a first computing device as an image or audio signal. The image or audio signal is transmitted from the first computing device to the second computing device. The password is determined from the image or audio signal at the second computing device. A key exchange is performed between the first computing device and the second computing device wherein a key is derived at each of the first and second computing devices.

In <CIT> an activation barcode is received from a server by reading an image comprising the activation barcode via a computing device. The image is displayed on a display associated with the computing device. The activation barcode encodes activation data comprising an activation password. The activation barcode is decoded at the mobile device to obtain the activation password, and an authentication is performed using the activation password after a device activation request is transmitted to the server, such that the mobile device is activated to operate with the server if the authentication is successful.

"Seeing-Is-Believing: Using Camera Phones for Human-Verifiable Authentication" discloses a system that utilizes 2D barcodes and camera-telephones to implement a visual channel for authentication and demonstrative identification of devices.

The invention is set forth in the independent claims. Embodiments of the invention are described in the dependent claims.

In an example not forming part of the wording of the claims, at least one computer-readable storage medium comprises instructions that, when executed, cause a system to receive encoded connection information from a close-range input device of a client mode electronic device; decode the encoded connection information into one or more connection elements; establish a communication connection with a server mode electronic device utilizing the connection elements; receive authentication information at the client mode electronic device via the communication connection; authenticate the server mode electronic device to the client mode electronic device utilizing the authentication information; and generate one or more authentication elements responsive to authentication of the server mode electronic device for presentation via a close-range output device coupled to the client mode electronic device, the one or more authentication elements configured to authenticate the client mode electronic device to the server mode electronic device, wherein one of:
the encoded connection information comprises a quick response code, wherein the encoded connection information comprises a bar code; the authentication information comprises a public-private encryption key pair; the encoded connection information comprises an Internet protocol address and a transmission control protocol port number associated with the server mode electronic device; the computer-readable storage medium comprises instructions that when executed cause the system to authenticate the server mode electronic device to the client mode electronic device utilizing the authentication information comprises receiving one or more authentication messages generated at the server mode electronic device, the one or more authentication messages comprising authentication information associated with the server mode electronic device, wherein the authentication information associated with the server mode electronic device comprises a self-signed certificate identified in the encoded connection information; or the one or more authentication elements comprises one or more word lists.

Various embodiments are generally directed to techniques for the authentication of electronic devices. Some embodiments are particularly directed to authentication of proximate electronic devices utilizing visual, demonstrative identification of one or more of the electronic devices. The devices may establish a connection utilizing authentication information accessed through a close-range input device, such as a camera or a near-field communication (NFC) reader. Messages may be exchanged between the devices through the connection, such as a wireless communication connection. The messages may contain security information and device identification information for device authentication. According to certain embodiments, authentication may further comprise demonstrative identification of the devices through human-readable verification elements. These authentication techniques operate to significantly increase the reliability and simplicity of electronic device authentication, thereby enhancing user productivity, convenience, and experience.

With general reference to notations and nomenclature used herein, the detailed description which follows may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

A procedure is here and is generally conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.

Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of one or more embodiments. Rather, the operations are machine operations. Useful machines for performing operations of various embodiments include general purpose digital computers or similar devices.

Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purpose or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer. The procedures presented herein are not inherently related to a particular computer or other apparatus. Various general purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given.

Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

As used hereinafter, "a" and "b" and "c" and similar designators as used herein are intended to be variables representing any positive integer. Thus, for example, if an implementation sets a value for a = <NUM>, then a complete set of electronic devices <NUM>-a may include electronic devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>. In some embodiments, the complete set of electronic devices <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> may include five different electronic devices, five different types of a same electronic device, five specific electronic devices <NUM> or any other suitable convention.

<FIG> illustrates a block diagram for a close-range mutual authentication system <NUM>. In one embodiment, the close-range mutual authentication system <NUM> may comprise a computer-based system comprising an electronic device <NUM>-a. The electronic device <NUM>-a may comprise, for example, a processor circuit <NUM>, a memory unit <NUM>, close-range input/output devices <NUM>-c, displays <NUM>-d, and one or more transceivers <NUM>-e. The electronic device <NUM>-a may further have comprise a mutual authentication application <NUM>. The memory unit <NUM> may store an unexecuted version of the mutual authentication application <NUM>, connection information <NUM>, and authentication information <NUM>. Although the close-range mutual authentication system <NUM> shown in <FIG> has a limited number of elements in a certain topology, it may be appreciated that the close-range mutual authentication system <NUM> may include more or fewer elements in alternate topologies as desired for a given implementation.

In various embodiments, the close-range mutual authentication system <NUM> may comprise two or more electronic devices <NUM>-a, such as electronic devices <NUM>-<NUM>, <NUM>-<NUM>. Some examples of an electronic device may include without limitation an ultra-mobile device, a mobile device, a personal digital assistant (PDA), a mobile computing device, a smart phone, a telephone, a digital telephone, a cellular telephone, eBook readers, a handset, a one-way pager, a two-way pager, a messaging device, a computer, a personal computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a mini-computer, a main frame computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, game devices, television, digital television, set top box, wireless access point, machine, or combination thereof.

In one embodiment, for example, the electronic device <NUM>-<NUM> may be implemented as a desktop computer having wireless communications capabilities. The electronic device <NUM>-<NUM> may be implemented as a mobile device having a portable power supply and wireless communications capabilities, such as a laptop computer, handheld computer, tablet computer, smart phone, gaming device, consumer electronic, or other mobile device. The embodiments are not limited to these examples, however, and any pair of electronic devices <NUM>-<NUM>, <NUM>-<NUM> may be used as desired for a given implementation. Further, although the electronic devices <NUM>-<NUM>, <NUM>-<NUM> are shown in <FIG> as homogeneous devices having similar device elements, it may be appreciated that the electronic devices <NUM>-<NUM>, <NUM>-<NUM> may comprise heterogeneous devices having different device elements.

In various embodiments, the close-range mutual authentication system <NUM> may comprise a processor circuit <NUM>. The processor circuit <NUM> can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (<NUM>) Duo®, Core (<NUM>) Quad®, Core i3®, Core i5®, Core i7®, Atom®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing circuit <NUM>.

In various embodiments, the close-range mutual authentication system <NUM> may comprise a memory unit <NUM>. The memory unit <NUM> may store, among other types of information, the mutual authentication application <NUM> and connection information <NUM>. The memory unit <NUM> may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.

Connection information <NUM> may comprise any electronic information capable of storing information associated with establishing a connection with an electronic device <NUM>-a. For example, the connection information <NUM> may include, without limitation, a TCP port number and an IP address. In one embodiment, the connection information <NUM> may further comprise one or more security elements, such as a certificate, including a self-signed certificate, a random number, a hash value, or some combination thereof. According to certain embodiments, the connection information <NUM> may be encoded such that an electronic device <NUM>-a receiving the connection information <NUM> may be required to decode the connection information <NUM> in order to utilize any information contained therein. In another embodiment, the connection information <NUM> may be encoded into one or more forms conducive to access by a close-range input/output device <NUM>-c. For instance, the connection information <NUM> may be encoded into a quick response (QR) code, bar code, graphic, or electronic file which may be accessed by a camera, QR reader, bar code reader, or NFC reader.

Authentication information <NUM> may comprise any electronic information capable of storing information associated with an electronic device <NUM>-a. According to certain embodiments, the authentication information <NUM> may be utilized by electronic devices <NUM>-a to identify or authenticate another electronic device <NUM>-a. For example, authentication information <NUM> may comprise digital certificates, random numbers, hash values, public and/or private encryption keys, signatures, security elements, and combinations thereof. The authentication information <NUM> may be generated by an electronic device <NUM>-a without outside information, such as a self-signed digital certificate, or utilizing information obtained from another electronic device <NUM>-a. For instance, electronic device <NUM>-<NUM> may receive a hash value from electronic device <NUM>-<NUM>, and may generate an encryption key utilizing the hash value.

In various embodiments, the close-range mutual authentication system <NUM> may comprise one or more close-range input/output devices. The close-range input/output devices <NUM>-c may operate to obtain information from proximate electronic devices <NUM>-a. Non-limiting examples of close-range input/output devices <NUM>-c include a camera, QR reader/writer, bar code reader, and a display <NUM>-d coupled with an electronic device <NUM>-a. For instance, the close-range input/output devices <NUM>-c may receive input from another electronic device <NUM>-a if the close-range input/output devices <NUM>-c touch (e.g., NFC reader), observe (e.g., camera, QR reader, bar code reader), or are within a specified distance (e.g., proximity of less than three feet). In this manner, the close-range mutual authentication system <NUM> may achieve one layer of security for device authentication because authentication may not be initiated unless the electronic devices <NUM>-a are physically accessible to each other. In addition, for mobile computing devices, such as smart phones, authentication may be facilitated in that users desiring to share information on their mobile devices may initiate the process simply by arranging their devices proximate to each other and exchanging initial connection information.

The electronic devices <NUM>-<NUM>, <NUM>-<NUM> may each implement a display <NUM>-d. The display <NUM>-d may comprise any digital display device suitable for the electronic devices <NUM>-<NUM>, <NUM>-<NUM>. For instance, the displays <NUM>-d may be implemented by a liquid crystal display (LCD) such as a touch-sensitive, color, thin-film transistor (TFT) LCD, a plasma display, a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a cathode ray tube (CRT) display, or other type of suitable visual interface for displaying content to a user of the electronic devices <NUM>-<NUM>, <NUM>-<NUM>. The displays <NUM>-d may further include some form of a backlight or brightness emitter as desired for a given implementation.

The electronic devices <NUM>-<NUM>, <NUM>-<NUM> may each implement one or more wireless transceivers <NUM>-e. Each of the wireless transceivers <NUM>-e may be implemented as physical wireless adapters or virtual wireless adapters, sometimes referred to as "hardware radios" and "software radios. " In the latter case, a single physical wireless adapter may be virtualized using software into multiple virtual wireless adapters. A physical wireless adapter typically connects to a hardware-based wireless access point. A virtual wireless adapter typically connects to a software-based wireless access point, sometimes referred to as a "SoftAP. " For instance, a virtual wireless adapter may allow ad hoc communications between peer devices, such as a smart phone and a desktop computer or notebook computer. Various embodiments may use a single physical wireless adapter implemented as multiple virtual wireless adapters, multiple physical wireless adapters, multiple physical wireless adapters each implemented as multiple virtual wireless adapters, or some combination thereof. The embodiments are not limited in this case.

The wireless transceivers <NUM>-e may comprise or implement various communication techniques to allow the electronic devices <NUM>-<NUM>, <NUM>-<NUM> to communicate with other electronic devices. For instance, the wireless transceivers <NUM>-e may implement various types of standard communication elements designed to be interoperable with a network, such as one or more communications interfaces, network interfaces, network interface cards (NIC), radios, wireless transmitters/receivers (transceivers), wired and/or wireless communication media, physical connectors, and so forth. By way of example, and not limitation, communication media includes wired communications media and wireless communications media. Examples of wired communications media may include a wire, cable, metal leads, printed circuit boards (PCB), backplanes, switch fabrics, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communications media may include acoustic, radio-frequency (RF) spectrum, infrared and other wireless media.

In various embodiments, the electronic devices <NUM>-a may implement different types of wireless transceivers <NUM>-e. Each of the wireless transceivers <NUM>-e may implement or utilize a same or different set of communication parameters to communicate information between various electronic devices. In one embodiment, for example, each of the wireless transceivers <NUM>-e may implement or utilize a different set of communication parameters to communicate information between the electronic device <NUM>-a and a remote device. Some examples of communication parameters may include without limitation a communication protocol, a communication standard, a radio-frequency (RF) band, a radio, a transmitter/receiver (transceiver), a radio processor, a baseband processor, a network scanning threshold parameter, a radio-frequency channel parameter, an access point parameter, a rate selection parameter, a frame size parameter, an aggregation size parameter, a packet retry limit parameter, a protocol parameter, a radio parameter, modulation and coding scheme (MCS), acknowledgement parameter, media access control (MAC) layer parameter, physical (PHY) layer parameter, and any other communication parameters affecting operations for the wireless transceivers <NUM>-e.

In various embodiments, the wireless transceivers <NUM>-e may implement different communication parameters offering varying bandwidths, communications speeds, or transmission range. For instance, a first wireless transceiver <NUM>-<NUM> may comprise a short-range interface implementing suitable communication parameters for shorter range communications of information, while a second wireless transceiver <NUM>-<NUM> may comprise a long-range interface implementing suitable communication parameters for longer range communications of information.

In various embodiments, the terms "short-range" and "long-range" may be relative terms referring to associated communications ranges (or distances) for associated wireless transceivers <NUM>-e as compared to each other rather than an objective standard. In one embodiment, for example, the term "short-range" may refer to a communications range or distance for the first wireless transceiver <NUM>-<NUM> that is shorter than a communications range or distance for another wireless transceiver <NUM>-e implemented for the electronic device <NUM>-a, such as a second wireless transceiver <NUM>-<NUM>. Similarly, the term "long-range" may refer to a communications range or distance for the second wireless transceiver <NUM>-<NUM> that is longer than a communications range or distance for another wireless transceiver <NUM>-e implemented for the electronic device <NUM>-a, such as the first wireless transceiver <NUM>-<NUM>.

In various embodiments, the terms "short-range" and "long-range" may be relative terms referring to associated communications ranges (or distances) for associated wireless transceivers <NUM>-e as compared to an objective measure, such as provided by a communications standard, protocol or interface. In one embodiment, for example, the term "short-range" may refer to a communications range or distance for the first wireless transceiver <NUM>-<NUM> that is shorter than <NUM> meters or some other defined distance. Similarly, the term "long-range" may refer to a communications range or distance for the second wireless transceiver <NUM>-<NUM> that is longer than <NUM> meters or some other defined distance.

In one embodiment, for example, the wireless transceiver <NUM>-<NUM> may comprise a radio designed to communicate information over a wireless personal area network (WPAN) or a wireless local area network (WLAN). The wireless transceiver <NUM>-<NUM> may be arranged to provide data communications functionality in accordance with different types of lower range wireless network systems or protocols. Examples of suitable WPAN systems offering lower range data communication services may include a Bluetooth system as defined by the Bluetooth Special Interest Group, an infra-red (IR) system, an Institute of Electrical and Electronics Engineers (IEEE) <NUM> system, a DASH7 system, wireless universal serial bus (USB), wireless high-definition (HD), an ultra-side band (UWB) system, and similar systems. Examples of suitable WLAN systems offering lower range data communications services may include the IEEE <NUM>. xx series of protocols, such as the IEEE <NUM>. 11a/b/g/n series of standard protocols and variants (also referred to as "WiFi"). It may be appreciated that other wireless techniques may be implemented, and the embodiments are not limited in this context.

In one embodiment, for example, the wireless transceiver <NUM>-<NUM> may comprise a radio designed to communicate information over a wireless local area network (WLAN), a wireless metropolitan area network (WMAN), a wireless wide area network (WWAN), or a cellular radiotelephone system. The wireless transceiver <NUM>-<NUM> may be arranged to provide data communications functionality in accordance with different types of longer range wireless network systems or protocols. Examples of suitable wireless network systems offering longer range data communication services may include the IEEE <NUM>. xx series of protocols, such as the IEEE <NUM>. 11a/b/g/n series of standard protocols and variants, the IEEE <NUM> series of standard protocols and variants, the IEEE <NUM> series of standard protocols and variants (also referred to as "Mobile Broadband Wireless Access"), and so forth. Alternatively, the wireless transceiver <NUM>-<NUM> may comprise a radio designed to communication information across data networking links provided by one or more cellular radiotelephone systems. Examples of cellular radiotelephone systems offering data communications services may include GSM with General Packet Radio Service (GPRS) systems (GSM/GPRS), CDMA/<NUM>×RTT systems, Enhanced Data Rates for Global Evolution (EDGE) systems, Evolution Data Only or Evolution Data Optimized (EV-DO) systems, Evolution For Data and Voice (EV-DV) systems, High Speed Downlink Packet Access (HSDPA) systems, High Speed Uplink Packet Access (HSUPA), and similar systems. It may be appreciated that other wireless techniques may be implemented, and the embodiments are not limited in this context.

Although not shown, the electronic device <NUM>-a may further comprise one or more device resources commonly implemented for electronic devices, such as various computing and communications platform hardware and software components typically implemented by a personal electronic device. Some examples of device resources may include without limitation a co-processor, a graphics processing unit (GPU), a chipset/platform control hub (PCH), an input/output (I/O) device, computer-readable media, display electronics, display backlight, network interfaces, location devices (e.g., a GPS receiver), sensors (e.g., biometric, thermal, environmental, proximity, accelerometers, barometric, pressure, etc.), portable power supplies (e.g., a battery), application programs, system programs, and so forth. Other examples of device resources are described with reference to exemplary computing architectures shown by <FIG>. The embodiments, however, are not limited to these examples.

In the illustrated embodiment shown in <FIG>, the processor circuit <NUM> may be communicatively coupled to the wireless transceivers <NUM>-e and the memory unit <NUM>. The memory unit <NUM> may store a mutual authentication application <NUM> arranged for execution by the processor circuit <NUM> to authenticate electronic devices <NUM>-a. The mutual authentication application <NUM> may generally provide features to securely authenticate electronic devices <NUM>-a in proximity to each other utilizing out-of-band communications. More particularly, the mutual authentication application <NUM> may allow a user of an electronic device <NUM>-<NUM> to access connection information <NUM> for connecting to electronic device <NUM>-<NUM> utilizing a close-range input/output device <NUM>-c, and to exchange authentication messages <NUM>-b containing authentication information <NUM> for authenticating to the electronic device <NUM>-<NUM>. Responsive to the electronic device <NUM>-<NUM> authenticating to the electronic device <NUM>-<NUM>, one or more authentication elements <NUM>-f may be presented on a display <NUM>-<NUM>, <NUM>-<NUM> coupled to the electronic device <NUM>-<NUM>, electronic device <NUM>-<NUM>, or both. Users of electronic devices <NUM>-<NUM>, <NUM>-<NUM> may access the authentication elements <NUM>-f and may indicate validation of the authentication to the electronic device <NUM>-<NUM>, <NUM>-<NUM>. In this manner, electronic device <NUM>-<NUM> may be authenticated to electronic device <NUM>-<NUM>. In one embodiment, the authentication elements <NUM>-f may be human-readable, such as words, pictures, numbers, or combinations thereof.

When the mutual authentication application is active on the electronic devices <NUM>-<NUM>, <NUM>-<NUM>, the electronic device <NUM>-<NUM> may be referred to as being in a "server mode" and the electronic device <NUM>-<NUM> may be referred to as being in a "client mode. " The terms "server mode" and "client mode" are for reference purposes and do not necessarily represent a server - client relationship between electronic devices <NUM>-<NUM>, <NUM>-<NUM> as known to those having ordinary skill in the art.

Particular aspects, embodiments and alternatives of the close-range mutual authentication system <NUM> and the mutual authentication application <NUM> may be further described with reference to <FIG>.

<FIG> illustrates an embodiment of an operating environment <NUM> for the close-range mutual authentication system <NUM>. More particularly, the operating environment <NUM> may illustrate a more detailed block diagram for the mutual authentication application <NUM>.

As shown in <FIG>, the mutual authentication application <NUM> may comprise various components <NUM>-g. As used in this application, the term "component" is intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the unidirectional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

In the illustrated embodiment shown in <FIG>, the mutual authentication application <NUM> may comprise a device connection component <NUM>-<NUM>, an authentication information component <NUM>-<NUM>, a device authentication component <NUM>-<NUM>, and a user verification component <NUM>-<NUM>. Although the mutual authentication application <NUM> shown in <FIG> has only four components in a certain topology, it may be appreciated that the mutual authentication application <NUM> may include more or less components in alternate topologies as desired for a given implementation.

The device connection component <NUM>-<NUM> may generally encode connection information on the server mode electronic device <NUM>-<NUM> and decode connection information <NUM> on the client mode electronic device <NUM>-<NUM>. According to certain embodiments, the device connection component <NUM>-<NUM> may generally operate to encode connection information <NUM> in a manner that the encoded connection information <NUM> may only be accessible to an electronic device <NUM>-<NUM> in close range with the electronic device <NUM>-<NUM>. For instance, the device connection component <NUM>-<NUM> may encode connection information <NUM> at the electronic device <NUM>-<NUM> for presentation on the display <NUM>-<NUM>. In one embodiment, for example, the device connection component <NUM>-<NUM> may encode the connection information as a QR code presented on the display <NUM>-<NUM>. The electronic device <NUM>-<NUM> may access the QR code when it is proximate to the electronic device such that a close-range input/output device <NUM>-c accessible by the electronic device <NUM>-<NUM> may access the QR code, such as a QR code reader in the form of a camera. In another embodiment, the device connection component <NUM>-<NUM> may encode the connection information <NUM> and transfer the encoded connection information <NUM> to a NFC writer. The electronic device <NUM>-<NUM> may access the encoded connection information <NUM> via a close-range input/output device <NUM>-c configured to communicate with a NFC writer, such as a NFC reader.

The device connection component <NUM>-<NUM> may operate with various connection information elements, including, without limitation, transmission control protocol TCP port numbers, Internet protocol (IP) addresses, media access control (MAC) addresses, serial numbers, hash values, and combinations thereof. In one embodiment, the device connection component <NUM>-<NUM> operates to generate connection information <NUM> configured from multiple elements, such as a hash value, an IP address, and a TCP port number. For example, the device connection component <NUM>-<NUM> may encode the hash value, IP address, and TCP port number into a QR code for presentation on the display <NUM>-<NUM> of the server mode electronic device <NUM>-<NUM>. In one embodiment, the hash value may be obtained from applying a hash function on a random number generated at the electronic device <NUM>-a and a digital certificate associated with the electronic device <NUM>-a. The client mode electronic device <NUM>-<NUM> may access the encoded connection information <NUM> and the device connection component <NUM>-<NUM> may operate to decode the connection information <NUM> into its constituent elements. The device connection component <NUM>-<NUM> may operate to establish a connection between the electronic devices <NUM>-<NUM>, <NUM>-<NUM> utilizing the decoded connection information <NUM>. For example, the device connection component <NUM>-<NUM> may communicatively connect electronic device <NUM>-<NUM> to electronic device <NUM>-<NUM> using the IP address and TCP port number information included in the connection information <NUM>.

The authentication information component <NUM>-<NUM> may generally manage authentication information <NUM> between server mode and client mode devices (e.g., electronic devices <NUM>-<NUM>, <NUM>-<NUM>) for the mutual authentication application <NUM>. The authentication information component <NUM>-<NUM> may coordinate the generation of authentication information <NUM> and messaging between the server mode and client mode devices <NUM>-<NUM>, <NUM>-<NUM>. The messaging between server mode and client mode devices <NUM>-<NUM>, <NUM>-<NUM> may operate to exchange the authentication information between the server mode and client mode devices <NUM>-<NUM>, <NUM>-<NUM>, for example, utilizing one or more authentication messages <NUM>-b. The authentication information component <NUM>-<NUM> may generate and operate with various forms of authentication information <NUM>. Non-limiting examples of authentication information include random numbers, device identifiers, public/private key pairs, session keys (e.g., random session key), certificates (e.g., self-signed digital certificates such as an X. <NUM> certificate), digital signatures, pseudorandom function (prf) values, human-readable information (e.g., word lists, pictures, etc.), and combinations and hash values thereof. Embodiments are not limited in this context.

In one embodiment, responsive to the client mode electronic device <NUM>-<NUM> establishing a connection with the server mode electronic device <NUM>-<NUM>, the authentication information component <NUM>-<NUM> may send an authentication message <NUM>-b from the client mode electronic device <NUM>-<NUM> to the server mode electronic device <NUM>-<NUM>. For example, the authentication message <NUM>-b may be a start-secure-pairing message comprising certain elements of authentication information <NUM>. For instance, the start-secure-pairing message may include a random number, an encryption key, a signature, and a certificate associated with the client mode electronic device <NUM>-<NUM>. The server mode electronic device <NUM>-<NUM> may receive the authentication message <NUM>-b and the authentication information component <NUM>-<NUM> may operate to decode, derive, extract, or otherwise obtain authentication information <NUM> contained within the authentication message <NUM>-b. Illustrative and non-restrictive examples of authentication message <NUM>-b include accept-secure-pairing and confirm-secure-pairing messages. Authentication information <NUM> and the exchange of authentication message <NUM>-b are described in more detail with respect to <FIG>.

The device authentication component <NUM>-<NUM> may generally manage the authentication of electronic devices <NUM>-a for the mutual authentication application <NUM>. For instance, the device authentication component <NUM>-<NUM> may utilize the authentication information <NUM> and the authentication messages <NUM>-b to authenticate the identity of an electronic device <NUM>-a. For example, the device authentication component <NUM>-<NUM> may operate to determine the type of authentication message <NUM>-b and to ensure that it is of an expected type. As described above, the authentication information component <NUM>-<NUM> may operate to send a start-secure-pairing authentication message <NUM>-b from the client mode electronic device <NUM>-<NUM> to the server mode electronic device <NUM>-<NUM> responsive to a connection being established between the devices <NUM>-<NUM>, <NUM>-<NUM>. The device authentication component <NUM>-<NUM> may determine whether an authentication message <NUM>-b is valid. For example, if the device authentication component <NUM>-<NUM> receives another message type (e.g., an accept-secure-pairing authentication message <NUM>-b) when the device authentication component <NUM>-<NUM> is expecting a start-secure-pairing message, the device authentication component may determine that the authentication message <NUM>-b is invalid. According to certain embodiments, if the message is not valid, it may be discarded. In another example, if an authentication message <NUM>-b comprises authentication information <NUM> that the device authentication component <NUM>-<NUM> cannot validate (e.g., a signature of a self-signed certificate does not verify), then the authentication message <NUM>-b may be discarded. If the authentication message <NUM>-b and the authentication information <NUM> contained therein are authenticated by the device authentication component <NUM>-<NUM>, then the server mode electronic device <NUM>-<NUM> may be authenticated to the client mode electronic device <NUM>-<NUM>.

The user verification component <NUM>-<NUM> may generally manage the authentication of electronic devices <NUM>-a utilizing authentication elements <NUM>-f. For example, the user verification component <NUM>-<NUM> may generate one or more authentication elements <NUM>-f for presentation on a display <NUM>-c, such as display <NUM>-<NUM> and display <NUM>-<NUM>. A user may read or view the authentication elements <NUM>-f from display <NUM>-<NUM> to determine whether one or more of the authentication elements <NUM>-f match one or more authentication elements <NUM>-f presented on display <NUM>-<NUM>. If there is a match, a user may indicate through the user verification component an authentication acceptance <NUM>. For instance, in response to an authentication acceptance <NUM>, a user may make an input selection at an electronic device <NUM>-a indicating that the authentication of one of the electronic devices <NUM>-a.

According to certain embodiments, the user verification component <NUM>-<NUM> may generate the authentication elements <NUM>-f responsive to a user command or an authentication event, such as the server mode electronic device <NUM>-<NUM> being authenticated to the client mode electronic device <NUM>-<NUM>. In this manner, the client mode electronic device <NUM>-<NUM> may be mutually authenticated to the server mode electronic device <NUM>-<NUM> through an out-of-band channel consisting of a visual comparison of authentication elements <NUM>-f being presented on displays <NUM>-<NUM> and <NUM>-<NUM>. The authentication elements <NUM>-f may comprise various human-readable words, symbols, pictures, graphics, or combinations thereof. For example, the authentication elements <NUM>-f may comprise one or more word lists, wherein device users may read the word lists presented on displays <NUM>-<NUM> and <NUM>-<NUM> to determine whether a threshold number of authentication elements <NUM>-f match between those presented on display <NUM>-<NUM> and those displayed on <NUM>-<NUM>.

<FIG> illustrates an embodiment of an operating environment <NUM> for the close-range mutual authentication system <NUM>. More particularly, the operating environment <NUM> may illustrate the presentation of connection information <NUM> of a server mode electronic device <NUM>-<NUM>.

In the illustrated embodiment shown in <FIG>, the server mode electronic device <NUM>-<NUM> and the client mode electronic device <NUM>-<NUM> may initiate the mutual authentication application <NUM> when they are within close-range <NUM> of each other. According to certain embodiments, a close-range <NUM> may involve the devices being within a certain distance of each other such that the close-range input/output devices <NUM>-c may access information from a particular electronic device <NUM>-a. In the embodiment of <FIG>, the connection information <NUM> is presented in the form of a QR code on the display <NUM>-<NUM> of the server mode electronic device <NUM>-<NUM>, which in this case, is a smartphone device. The client mode electronic device <NUM>-<NUM>, which in this case is a tablet computing device, may access the connection information <NUM> utilizing a camera <NUM>-<NUM> accessible from the client mode electronic device <NUM>-<NUM>.

<FIG> illustrates an embodiment of an information flow <NUM>. The information flow <NUM> as shown in <FIG> represents an exemplary flow of information between a server mode electronic device <NUM>-<NUM> and a client mode electronic device <NUM>-<NUM> during authentication.

As shown in <FIG>, a server mode electronic device <NUM>-<NUM> and a client mode electronic device <NUM>-<NUM> are arranged within close-range <NUM> such that the client mode electronic device <NUM>-<NUM> may access the connection information <NUM> presented by the server mode electronic device <NUM>-<NUM> utilizing a close-range input/output device <NUM>-c. The connection information <NUM> may be generated by the server mode electronic device <NUM>-<NUM> to include various forms of information. For example, the server mode electronic device <NUM>-<NUM> may generate a random number r and a certificate certserver and may hash these values to produce a hash value h ← hash(r ∥ certserver). The connection information <NUM> may be formed by encoding h and certain connection information, such as an IP address ip, and a TCP port number. In one embodiment, h, ip, and p may be encoded according to the following: connection information <NUM> ← encode (h ∥ ip ∥ p). The encoded connection information <NUM> may be made available from the server mode electronic device <NUM>-<NUM>, for example, as a QR code, bar code, picture, or any other form of information accessible by a close-range input/output device.

As described above, the client mode electronic device <NUM>-<NUM> may access the encoded connection information <NUM> utilizing a close-range input/output device <NUM>-c. The device connection component <NUM>-<NUM> resident on the client mode electronic device <NUM>-<NUM> may decode the encoded connection information <NUM> into its component elements, such as h, ip, and p. In one embodiment, the device connection component <NUM>-<NUM> may generate additional values on the encoded connection information <NUM>, such as a hash of the encoded connection information: h' ← hash(encoded connection information <NUM>).

The device connection component <NUM>-<NUM> may use information contained within the connection information <NUM> to establish a connection between the client mode electronic device <NUM>-<NUM> and the server mode electronic device <NUM>-<NUM>. For example, the client mode electronic device <NUM>-<NUM> may establish a TCP connection with the server mode electronic device <NUM>-<NUM> to port p at IP address ip. After the connection has been established, the authentication information component <NUM>-<NUM> may operate to generate certain authentication elements on the client mode electronic device <NUM>-<NUM>. In one embodiment, the authentication elements may comprise one or more of the following: a random number r', a secret key skclient, a public/private encrypt/decrypt key pair ekclient/dkclient, signature sig<NUM> ← sign(skclient, r' ∥ ekclient), and a public key vkclient. The authentication information component <NUM>-<NUM> may operate to send a start-secure-pairing authentication message <NUM>-<NUM> from the client mode electronic device <NUM>-<NUM> to the server mode electronic device <NUM>-<NUM>. The start-secure-pairing authentication message <NUM>-<NUM> may comprise various authentication information <NUM> elements. In one embodiment, the start-secure-pairing authentication messages <NUM>-<NUM> may include r', ekclient, sig<NUM>, and self-signed certificate certclient authentication information <NUM> elements.

The mutual authentication application <NUM> operating on the server mode electronic device <NUM>-<NUM> may receive the start-secure-pairing authentication message <NUM>-<NUM>. In one embodiment, the device authentication component <NUM>-<NUM> may determine whether the authentication message <NUM>-<NUM> received at this stage of authentication is valid. For example, if the authentication message <NUM>-<NUM> is not a start-secure-pairing message, the authentication message <NUM>-<NUM> may be deemed invalid and discarded. In another embodiment, the device authentication component <NUM>-<NUM> may validate one or more authentication information <NUM> elements contained in the authentication message <NUM>-<NUM>. For instance, the device authentication component <NUM>-<NUM> may determine whether the self-signed certificate certclient may be verified, or whether sig<NUM> verifies using public key vkclient over the data r' ∥ ekclient. If the authentication information <NUM> included in the start-secure-pairing authentication message <NUM>-<NUM> cannot be verified, the authentication message <NUM>-<NUM> may be discarded by the mutual authentication application <NUM> operating on the server mode electronic device <NUM>-<NUM>.

Embodiments provide that one or more information elements may be extracted from any authentication information <NUM> included in an authentication message <NUM>-b, such as the start-secure-pairing authentication message <NUM>-<NUM>. For example, responsive to receiving a valid start-secure-pairing authentication message <NUM>-<NUM> at the server mode electronic device <NUM>-<NUM>, the authentication information component <NUM>-<NUM> resident on the server mode electronic device <NUM>-<NUM> may extract identification information from the certclient element, such as a client mode electronic device <NUM>-<NUM> identifier idclient contained with certclient. The authentication information component <NUM>-<NUM> may generate an accept-secure-pairing authentication message <NUM>-<NUM> at the server mode electronic device <NUM>-<NUM>. Authentication information <NUM> may be generated at the server mode electronic device <NUM>-<NUM> for inclusion in one or more authentication messages <NUM>-b, such as the accept-secure-pairing authentication message <NUM>-<NUM>. Illustrative and non-restrictive examples of such authentication information <NUM> include a random session key k, public key vkclient, an encryption value α generated by encrypting idclient ∥ k ∥ h under ekclient (e.g., α ← Encrypt(ekclient, idclient ∥ k ∥ h)), a server mode electronic device <NUM>-<NUM> secret key skserver, a server mode electronic device <NUM>-<NUM> identifier idserver, a signature sig<NUM> ← sign(skserver, r' ∥ r ∥ idserver ∥ α), and combinations thereof. In one embodiment, the accept-secure-pairing authentication message <NUM>-<NUM> may be transmitted from the server mode electronic device <NUM>-<NUM> to the client mode electronic device <NUM>-<NUM> over the connection established via the device connection component <NUM>-<NUM>, such as a TCP connection. The accept-secure-pairing authentication message <NUM>-<NUM> may be configured to transmit authentication information from the server mode electronic device <NUM>-<NUM> to the client mode device, including, without limitation, r', r, α, sig<NUM>, and certserver.

The mutual authentication application <NUM> operative on the client mode electronic device <NUM>-<NUM> may receive the accept-secure-pairing authentication message <NUM>-<NUM> and the device authentication component <NUM>-<NUM> may validate the message <NUM>-<NUM> and authentication information <NUM> contained therein. For example, if the authentication message <NUM>-<NUM> is not an accept-secure-pairing authentication message <NUM>-<NUM>, then the authentication message <NUM>-<NUM> may be discarded. According to certain embodiments, the authentication component <NUM>-<NUM> may operate to verify authentication information <NUM> included in the accept-secure-pairing authentication message <NUM>-<NUM>. Non-limiting examples of authentication information <NUM> verification include the following: whether r' from the accept-secure-pairing authentication message <NUM>-<NUM> matches the r' value sent in the start-secure-pairing authentication message <NUM>-<NUM>; whether the signature of the self-signed certificate certserver verifies; whether sig<NUM> verifies using vkclient over the data r' ∥ r ∥ idserver ∥ α; and combinations thereof.

In one embodiment, the authentication information component <NUM>-<NUM> operates to extract or recover certain authentication information <NUM> elements based on authentication information <NUM> included in the accept-secure-pairing authentication message <NUM>-<NUM>. For instance, the authentication information component <NUM>-<NUM> may decrypt α utilizing dkclient to recover idclient ∥ k ∥ h" (e.g., idclient ∥ k ∥ h" ← Decrypt(dkclient, α)). The device authentication component <NUM>-<NUM> may verify the authentication information recovered from decrypting α utilizing dkclient. For example, if idclient is not the device identity from certclient, then the accept-secure-pairing authentication message <NUM>-<NUM> may be discarded. In another example, the accept-secure-pairing authentication message <NUM>-<NUM> may be discarded if h" ≠ h, where A is the value recovered by decoding the device connection information <NUM>, as described above, and if h ≠ hash(r ∥ certserver). In one embodiment, if the device authentication component <NUM>-<NUM> operative on the client mode electronic device <NUM>-<NUM> determines that h" = h, then the device authentication component <NUM>-<NUM> authenticates the server mode electronic device <NUM>-<NUM> on the client mode electronic device <NUM>-<NUM>. If the authentication information <NUM> is not verified, the accept-secure-pairing authentication message <NUM>-<NUM> may be discarded.

The mutual authentication application <NUM> may operate to confirm authentication between the server mode electronic device <NUM>-<NUM> and the client mode electronic device <NUM>-<NUM>. Confirmation of device authentication may be initiated by the authentication information component <NUM>-<NUM> generating a confirm-secure-pairing authentication message <NUM>-<NUM> for transmission to the server mode electronic device <NUM>-<NUM>. In one embodiment, the authentication information component <NUM>-<NUM> may operate to generate authentication information to be transmitted with the confirm-secure-pairing authentication message <NUM>-<NUM>. For example, one or more pseudorandom function (prf) values or signatures may be generated as part of authentication confirmation, including, without limitation, the following values: m ← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>); h<NUM>← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>); ak ← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>); ek ← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>); and sig<NUM> ← sign(skclient, r ∥ idclient ∥ m). In one embodiment, the authentication information component <NUM>-<NUM> may generate a confirm-secure-pairing authentication message <NUM>-<NUM> having authentication information <NUM> comprising r, idclient, m, and sig<NUM>.

The confirm-secure-pairing authentication message <NUM>-<NUM> may be received at the server mode electronic device <NUM>-<NUM>, wherein the device authentication component <NUM>-<NUM> operative on the server mode electronic device <NUM>-<NUM> may verify the authentication message <NUM>-<NUM>. For example, if the authentication message <NUM>-<NUM> is not a confirm-secure-pairing authentication message <NUM>-<NUM>, the authentication message <NUM>-<NUM> may be discarded. The device authentication component <NUM>-<NUM> may operate on the server mode electronic device <NUM>-<NUM> to authenticate any authentication information <NUM> transmitted within the confirm-secure-pairing authentication message <NUM>-<NUM>. For example, the device authentication component <NUM>-<NUM> may verify the following authentication information <NUM>: whether r is the same r used to compute h; whether idclient is the idclient in certclient; whether sig<NUM> verifies over r ∥ idclient ∥ m using vkclient. In one embodiment, the authentication information component <NUM>-<NUM> may operate to calculate m ← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>) and the device authentication component <NUM>-<NUM> may operate to verify that m' = m.

In one embodiment, if the confirm-secure-pairing authentication message <NUM>-<NUM> and the authentication information <NUM> contained therein are authenticated, the authentication information component <NUM>-<NUM> may operate to generate certain authentication information <NUM> elements. For instance, the authentication information component <NUM>-<NUM> may generate a session authentication key ak ← prf(k, r ∥ r' ∥ certclient ∥ certserver ∥ <NUM>) and an encryption key ek ← prf(k, r' ∥ r ∥ certclient ∥ certserver ∥ <NUM>) that may be used to secure the transfer of information between the server mode electronic device <NUM>-<NUM> and the client mode electronic device <NUM>-<NUM>. In one embodiment, the authentication information component <NUM>-<NUM> may operate to generate authentication information <NUM> to generate a key h<NUM> utilized to create one or more authentication elements <NUM>-f.

The mutual authentication application <NUM> operative on the server mode electronic device <NUM>-<NUM> and client mode electronic device <NUM>-<NUM> may initiate user verification of device authentication. At this stage of the authentication process, the server mode electronic device <NUM>-<NUM> may be authenticated to the client mode electronic device <NUM>-<NUM>. The server mode electronic device <NUM>-<NUM> may only establish that it has established a session with the device that sent the start-secure-pairing authentication message <NUM>-<NUM>, and not that it is actually the client mode electronic device <NUM>-<NUM>. As such, embodiments provide for user verification of device authentication, including authentication of the client mode electronic device <NUM>-<NUM> at the server mode electronic device <NUM>-<NUM>.

In one embodiment, the client mode electronic device <NUM>-<NUM> may generate one or more authentication elements <NUM>-f utilizing h<NUM>. For example, the user verification component <NUM>-<NUM> operative on the client mode device may generate one or more random word lists <NUM>-<NUM> - <NUM>-n. Random word list <NUM>-<NUM> may be based on h<NUM> and the remaining word lists may be based on one or more randomly generated numbers as follows: random word list <NUM>-<NUM> ← Dictionary (h<NUM>), random word list <NUM>-n ← Dictionary(hn). In this example, the function Dictionary(x) may operate to generate a word list from a dictionary object accessible by the user verification component <NUM>-<NUM> based on the parameter x. The user verification component <NUM>-<NUM> may present the random word lists <NUM>-<NUM> - <NUM>-n on the display <NUM>-<NUM> coupled to the client mode electronic device <NUM>-<NUM>. In one embodiment, the random word lists <NUM>-<NUM> - <NUM>-n may be shuffled, for example, to compel a user to read all of the random word lists <NUM>-<NUM> - <NUM>-n. At the same time, the user verification component <NUM>-<NUM> operative on the server mode device may generate one or more corresponding authentication elements <NUM>-f. For example, the user verification component <NUM>-<NUM> may generate a random word list <NUM>-<NUM>← Dictionary(h<NUM>') for presentation on display <NUM>-<NUM> coupled to server mode electronic device <NUM>-<NUM>.

Server mode device user <NUM>-<NUM> and client mode device user <NUM>-<NUM> may each read the authentication elements <NUM>-f presented on their respective displays <NUM>-<NUM>, <NUM>-<NUM> to each other, which, in this case is random word lists <NUM>-<NUM>, <NUM>-<NUM> - <NUM>-n, for authentication element verification <NUM>. If one of the authentication elements <NUM>-f presented at the client mode electronic device <NUM>-<NUM> matches a authentication element <NUM>-f presented on the server mode electronic device <NUM>-<NUM>, then the client mode electronic device <NUM>-<NUM> may be authenticated to the server mode electronic device <NUM>-<NUM>. Otherwise, the authentication may be rejected (e.g., certclient is a forgery). If the client mode electronic device <NUM>-<NUM> is authenticated at the server mode electronic device <NUM>-<NUM>, the server mode device user <NUM>-<NUM> may indicate to the user verification component <NUM>-<NUM>, for example, through an input gesture, that user verification <NUM> is successful. In this manner, the client mode electronic device <NUM>-<NUM> may be authenticated to the server mode electronic device <NUM>-<NUM> utilizing the user verification <NUM> out-of-band communications. Generating authentication elements <NUM>-f, such as one or more human-readable random word lists, and having device users <NUM>-<NUM>, <NUM>-<NUM> read them aloud to each other may operate to prove to the device users <NUM>-<NUM>, <NUM>-<NUM> that their devices <NUM>-<NUM>, <NUM>-<NUM> are communicating with an intended device.

Included herein is a set of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

<FIG> illustrates one embodiment of a logic flow <NUM>. The logic flow <NUM> may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow <NUM> may illustrate operations performed by the close-range mutual authentication system <NUM> and, more particularly, a client mode electronic device <NUM>-<NUM> of a close-range mutual authentication system <NUM>.

In the illustrated embodiment shown in <FIG>, the logic flow <NUM> may receive encoded connection information at a close-range input device of a client mode electronic device from a server mode electronic device at block <NUM>. For example, the client mode electronic device <NUM>-<NUM> may be arranged in close-proximity <NUM> with the server mode electronic device <NUM>-<NUM> presenting encoded connection information <NUM>, such as on a display or a NFC reader. A close-range input/output device <NUM>-c coupled to the client mode electronic device <NUM>-<NUM> may access the connection information <NUM>. In one embodiment, the connection information <NUM> may be encoded as a QR code which may be accessed by a camera close-range input/output device <NUM>-c.

The logic flow <NUM> may decode the encoded connection information into one or more connection elements at block <NUM>. For example, a device connection information component <NUM>-<NUM> may receive the encoded connection information <NUM> and may operate to decode the connection information into any component parts, such as an IP address and a TCP port number.

The logic flow <NUM> may establish a communication connection with the server mode electronic device at block <NUM>. For example, the device connection component <NUM>-<NUM> operative on the client mode electronic device <NUM>-<NUM> may establish a connection utilizing the decoded connection information <NUM>.

The logic flow <NUM> may receive authentication information at the client mode electronic device via the communication connection at block <NUM>. For example, the client mode electronic device <NUM>-<NUM> may receive one or more authentication messages <NUM>-b from the server mode electronic device <NUM>-<NUM>. According to certain embodiments, the one or more authentication messages <NUM>-b may comprise authentication information, such as a self-signed certificate of the sending device (e.g., server mode electronic device <NUM>-<NUM>).

The logic flow <NUM> may authenticate the server mode electronic device to the client mode electronic device utilizing the authentication information at block <NUM>. For example, the device authentication component <NUM>-<NUM> may operate to authenticate any authentication information <NUM> sent by the server mode electronic device <NUM>-<NUM>. In this manner, the device authentication component <NUM>-<NUM> may verify the identity of the server mode electronic device <NUM>-<NUM> attempting to have secure communications with the client mode electronic device <NUM>-<NUM>.

The logic flow <NUM> may generate authentication elements responsive to authentication of the server mode electronic device for presentation on a display of the client mode electronic device at block <NUM>. For example, the user verification component <NUM>-<NUM> may operate to generate authentication elements <NUM>-f, such as one or more word lists, for presentation on a display <NUM>-<NUM> coupled to the client mode electronic device <NUM>-<NUM>.

<FIG> illustrates one embodiment of a logic flow <NUM>. The logic flow <NUM> may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow <NUM> may illustrate operations performed by the close-range mutual authentication system <NUM> and, more particularly, a server mode electronic device <NUM>-<NUM> of a close-range mutual authentication system <NUM>.

In the illustrated embodiment shown in <FIG>, the logic flow <NUM> may generate encoded connection information at a close-range output device of a server mode electronic device at block <NUM>. For example, the device connection component <NUM>-<NUM> operating on the server mode electronic device <NUM>-<NUM> may generate connection information <NUM> comprising, inter alia, information for an electronic device <NUM>-a to establish a connection with the server mode electronic device <NUM>-<NUM>. The device connection component <NUM>-<NUM> may encode the connection information <NUM>, for example, as a QR code, and present the encoded connection information <NUM> on a close-range input/output device <NUM>-c, such as a display <NUM>-<NUM> or a NFC writer.

The logic flow <NUM> may transmit authentication messages comprising authentication information associated with the server mode electronic device to a client mode electronic device at block <NUM>. For example, the authentication information component <NUM>-<NUM> may operate to generate one or more authentication messages <NUM>-b comprised of authentication information. The authentication messages <NUM>-b may be transmitted to an electronic device <NUM>-a having an established connection with the server mode electronic device <NUM>-<NUM>.

The logic flow <NUM> may receive authentication messages confirming authentication of the server mode electronic device at the client mode electronic device at block <NUM>. For example, the device authentication component <NUM>-<NUM> operative on the client mode electronic device <NUM>-<NUM> may authenticate the server mode electronic device <NUM>-<NUM> based on the authentication information <NUM> communicated in the one or more authentication messages <NUM>-b. The server mode electronic device <NUM>-<NUM> may receive a confirmation authentication message <NUM>-<NUM> confirming authentication of the server mode electronic device <NUM>-<NUM> at the client mode electronic device <NUM>-<NUM>.

The logic flow <NUM> may generate one or more authentication elements for presentation on a display of the server mode electronic device, the one or more authentication elements configured to authenticate the client mode electronic device to the server mode electronic device at block <NUM>. For example, the user verification component <NUM>-<NUM> may generate authentication elements <NUM>-f, including, without limitation, one or more human-readable word lists, graphics, or pictures. The authentication elements <NUM>-f may be presented on a display <NUM>-<NUM> for access by a server mode electronic device user <NUM>-<NUM>.

The logic flow <NUM> may authenticate the client mode electronic device to the server mode electronic device responsive to receiving verified authentication input indicating verification of the authentication elements at block <NUM>. For example, a server mode electronic device user <NUM>-<NUM> and server mode electronic device user <NUM>-<NUM> may verify that at least one authentication elements <NUM>-f presented at the server mode electronic device <NUM>-<NUM> matches at least one authentication elements <NUM>-f presented at the client mode electronic device <NUM>-<NUM>. In response to authentication elements <NUM>-f verification, a user <NUM>-<NUM>, <NUM>-<NUM> may communicate the verification to the electronic devices <NUM>-<NUM>, <NUM>-<NUM> resulting in authentication of the client mode electronic device <NUM>-<NUM> at the server mode electronic device <NUM>-<NUM>.

<FIG> illustrates an embodiment of an exemplary computing architecture <NUM> suitable for implementing various embodiments as previously described. In one embodiment, the computing architecture <NUM> may comprise or be implemented as part of an electronic device <NUM>-a.

As used in this application, the terms "system" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the unidirectional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> comprises a processing unit <NUM>, a system memory <NUM> and a system bus <NUM>. The processing unit <NUM> can be any of various commercially available processors, such as those described with reference to the processor circuit <NUM> shown in <FIG>.

The computing architecture <NUM> may comprise or implement various articles of manufacture. An article of manufacture may comprise a computer-readable storage medium to store logic. Examples of a computer-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be at least partly implemented as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

The computer <NUM> may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) <NUM>, a magnetic floppy disk drive (FDD) <NUM> to read from or write to a removable magnetic disk <NUM>, and an optical disk drive <NUM> to read from or write to a removable optical disk <NUM> (e.g., a CD-ROM or DVD). The HDD <NUM>, FDD <NUM> and optical disk drive <NUM> can be connected to the system bus <NUM> by a HDD interface <NUM>, an FDD interface <NUM> and an optical drive interface <NUM>, respectively. The HDD interface <NUM> for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE <NUM> interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units <NUM>, <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM>, and program data <NUM>. In one embodiment, the one or more application programs <NUM>, other program modules <NUM>, and program data <NUM> can include, for example, the various applications and/or components of the system <NUM>.

A user can enter commands and information into the computer <NUM> through one or more wire/wireless input devices, for example, a keyboard <NUM> and a pointing device, such as a mouse <NUM>. Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processing unit <NUM> through an input device interface <NUM> that is coupled to the system bus <NUM>, but can be connected by other interfaces such as a parallel port, IEEE <NUM> serial port, a game port, a USB port, an IR interface, and so forth.

When used in a WAN networking environment, the computer <NUM> can include a modem <NUM>, or is connected to a communications server on the WAN <NUM>, or has other means for establishing communications over the WAN <NUM>, such as by way of the Internet. The modem <NUM>, which can be internal or external and a wire and/or wireless device, connects to the system bus <NUM> via the input device interface <NUM>. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, can be stored in the remote memory/storage device <NUM>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

The computer <NUM> is operable to communicate with wire and wireless devices or entities using the IEEE <NUM> family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE <NUM> over-the-air modulation techniques). This includes at least WiFi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. WiFi networks use radio technologies called IEEE <NUM>. 11x (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A WiFi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE <NUM>-related media and functions).

Claim 1:
A computer-implemented method, comprising:
receiving encoded connection information (<NUM>) at a close-range input device (<NUM>-c) being a near field communication input device of a client mode electronic device (<NUM>-<NUM>) from a server mode electronic device (<NUM>-<NUM>), wherein the encoded connection information (<NUM>) comprises a quick response code encoding a hash value, an Internet protocol address, and a transmission control protocol port number, wherein the hash value is obtained from applying a hash function on a random number generated by the server mode electronic device (<NUM>-<NUM>) and a digital certificate associated with the server mode electronic device (<NUM>-<NUM>);
decoding the encoded connection information (<NUM>) into one or more connection elements;
establishing a communication connection with the server mode electronic device (<NUM>-<NUM>) utilizing the connection elements;
receiving authentication information (<NUM>) at the client mode electronic device (<NUM>-<NUM>) via the communication connection;
authenticating the server mode electronic device (<NUM>-<NUM>) to the client mode electronic device (<NUM>-<NUM>) utilizing the authentication information (<NUM>); and
generating one or more human-readable authentication elements (<NUM>-f) responsive to authentication of the server mode electronic device (<NUM>-<NUM>) for presentation via a display of a close-range output device (<NUM>-c) of the client mode electronic device (<NUM>-<NUM>) and a display of the server mode electronic device (<NUM>-<NUM>), the one or more human-readable authentication elements (<NUM>-f) configured to confirm authentication of the client mode electronic device (<NUM>-<NUM>) to the server mode electronic device (<NUM>-<NUM>), wherein the one or more human readable authentication elements comprise one or more word lists.