Secure wake on LAN with white list

Systems, methods, and other embodiments associated with secure Wake on LAN with white list are described. According to one embodiment, an apparatus includes memory and sleep manager logic. The memory is configured to store a white list. The white list includes credentials for entities that are authorized to wake a host device from a power-saving sleep mode. The sleep manager logic is configured to receive, from a requesting entity, a request to wake the host device and determine if credentials for the requesting entity are on the white list. The sleep manager logic is configured to wake the host device when credentials for the requesting entity are on the white list and refrain from waking the host device when credentials for the requesting entity are not on the white list.

BACKGROUND

Most network enabled computer devices (e.g., personal computers, laptops, TV sets, printers, smart phones, routers, and so on) are designed to enter a low power “sleep” state when the device is inactive for some period of time or under other circumstances set by a user. To cause a sleeping device to enter an active state, a user can “wake up” the device by physically interacting with the device in some manner (e.g., pressing a button, opening a laptop's lid, and so on). Some devices can be woken up via a request (e.g., a “wake-up packet” sometimes called a “magic packet”) that is received from another device in the local area network (LAN). This feature is called Wake on LAN (WOL).

SUMMARY

In general, in one aspect this specification discloses an apparatus that provides secure Wake on Lan with white list. The apparatus includes memory and sleep manager logic. The memory is configured to store a white list. The white list includes credentials for entities that are authorized to wake a host device from a power-saving sleep mode. The sleep manager logic is configured to receive, from a requesting entity, a request to wake the host device and determine if credentials for the requesting entity are on the white list. The sleep manager logic is configured to wake the host device when credentials for the requesting entity are on the white list and refrain from waking the host device when credentials for the requesting entity are not on the white list.

In general, in another aspect, this specification discloses a method for providing secure Wake on Lan with white list. The method includes receiving a request from a requesting entity to wake a host device and accessing a white list that includes credentials for entities that are authorized to wake the host device. The method includes determining if credentials for the requesting entity are on the white list; waking the host device when the credentials for the requesting entity are on the white list; and refraining from waking the host device when the credentials for the requesting entity are not on the white list.

In general, in another aspect, this specification discloses a device that provides secure Wake on Lan with white list. The device includes a network interface controller and a network CPU. The network interface controller includes security interface logic configured input a white list that includes credentials for entities that are authorized to wake the device from a power-saving sleep mode. The network CPU includes memory and sleep manager logic. The memory is configured to store a white list. The white list includes credentials for entities that are authorized to wake a host device from a power-saving sleep mode. The sleep manager logic is configured to receive, from a requesting entity, a request to wake the host device and determine if credentials for the requesting entity are on the white list. The sleep manager logic is configured to wake the host device when credentials for the requesting entity are on the white list and refrain from waking the host device when credentials for the requesting entity are not on the white list.

DETAILED DESCRIPTION

Basic WOL allows a device to be woken by any entity that knows the information about the device that is required for the wake-up packet (e.g., the device's MAC address). To provide additional security for WOL, some management solutions implement custom cryptographic communication protocols that are established for servers and clients in a particular network. The customized solutions to secure WOL is not well suited for many small (e.g., home) LANs. Another approach to providing secure WOL is to password protect a device's WOL feature by requiring a device's WOL password to be included the wake up packet. However, because the password is included in packets sent in the LAN, the password can be easily intercepted by a malicious device and used to wake up the device.

Described herein are examples of systems, methods, and other embodiments associated with providing secure WOL for a device by storing a white list in a sleeping device's memory. The white list includes credential for entities (e.g., users, companies, intelligent devices, and so on) that have been authorized to wake the device. The white list is accessible to a sleep manager application on the device that monitors packets on the LAN when the device is asleep. The sleep manager application wakes the device from the sleep state in response to a request (e.g., wake up packet) being received from an entity having credentials listed on the white list. In one embodiment, the white list stores one or more cryptographic authentication credentials (e.g., secure sockets layer (SSL) certificate, public encryption key, and so on) for each authorized entity that can be used to authenticate and establish a secure connection with the device.

For the purposes of this description, the term “credential” encompasses security credentials that are allocated to a unique entity in a secure manner and serve as proof of the entity's identity. Credentials include usernames, passwords, security certificates, encryption keys, authentication procedures, and so on. The term “entity” encompasses a real person, company, organization, virtual person, intelligent device, and so on.

With reference toFIG. 1, one embodiment of a system100is shown that includes a host network device110configured to provide secure WOL. In addition to the host network device110the system100includes network devices A-E. Network devices A, C, and E used by entities that are authorized to wake the host network device110. By way of example, the host network device110could be a laptop that belongs to a user (e.g., entity A) and the network device A could be the user's smart phone. The network device C could be the user's tablet and the network device E could be the laptop of the user's supervisor (e.g., entity E). Thus, the network devices A, C, and E have credentials identifying entities that are authorized to wake the host network device110.

The network devices B and D belong to entities that not authorized to wake the host network device110. The network devices B and D could be laptops belonging to the user's coworkers. Thus, the network devices B and D have credentials identifying entities that are not authorized to wake the host network device110. Other examples of network devices include personal computers, TV sets, network attached storage (NAS), printers, session initiation protocol (SIP)/Skype enabled smart phones, routers, “smart” appliances, or any device that has communication functionality that enables the device to belong to a network.

The host network device110includes a host CPU115and a network CPU120. The host CPU115executes processes to perform the host network device's function. If the host network device is a laptop, the host CPU115executes processes that implement the device's operating system and so on. The host CPU115will enter the power-saving sleep mode during periods of inactivity. The network CPU120executes processes that are necessary to handle network communication. Because it serves a limited, specialized purpose, the network CPU can have less processing power than the device CPU115. The network CPU120does not enter the sleep mode when the host CPU115enters the sleep mode. In one embodiment the network CPU120is an embedded processor in a network interface controller (NIC). The NIC can have a wired interface (e.g., Ethernet or power line) or a wireless interface (e.g., WiFi or Bluetooth) to the other network devices.

A white list is stored in memory associated with the network CPU120. In one embodiment illustrated in more detail inFIGS. 2 and 3, the white list is received from an authorization manager application when the host CPU115is entering the sleep mode. The white list lists credentials for entities that are authorized to wake the host network device110. InFIG. 1, the white list includes credentials for entities A and E.

Sleep manager logic130manages the host device's interaction with other devices while the host device110is asleep. In one embodiment, the sleep manager logic130is an application running on the network CPU120. When a request is received from a network device to wake the host network device110, the sleep manager logic130accesses the white list. The sleep manager logic130is configured to wake the host CPU115when a WOL request is received from an entity having credentials on the white list.

When a wake up request (e.g., wake up packet or magic packet) is received, the sleep manager logic130checks credentials of the entity that sent the wake up request. If the entity's credentials are on the white list, the sleep manager logic130wakes the host network device110. As shown inFIG. 1, when a wake up request (e.g., wake up packet or magic packet) is received from entity A via network device A, the sleep manager logic130wakes the host network device110. When a wake up request is received from entity B via network device B, the sleep manager logic130does not wake the host network device110.

FIG. 2illustrates one embodiment of a system200that includes a host network device210that provides secure WOL. The host network device210includes a host CPU215and authorization manager logic240. The authorization manager logic240controls access by entities to the host network device210. The authorization manager logic240maintains the white list by storing credentials for entities that are authorized to access the host network device210on the white list. While the host network device210is awake, the authorization manager logic240limits access to the host network device210to only those entities whose credentials are on the white list. The authorization manager logic240is supported by the host CPU215, which is separate from the network CPU120.

When the host CPU215is preparing to enter sleep mode, the authorization manager logic240transfers the white list to the network CPU120for access by the sleep manager logic130. In this manner, entities that are authorized to access the host network device210while the host network device210is awake will also be able to wake the host network device210from sleep mode.

In one embodiment, the credentials stored in the white list include one or more cryptographic authentication credentials that uniquely identify an entity and vouch for the entity's identity. For the purposes of this description, authentication credentials can include any information about an entity that is used to authenticate the identity of an entity prior to establishing a secure (encrypted) connection with the entity. The authentication credentials will include some type of cryptographic information such as encryption keys. Examples of authentication credentials include SSL certificates and public encryption keys that have been assigned to a network device by a certified authority.

The authorization manager logic240is configured to authenticate entities that have been authorized to access the host device210. In one embodiment, the authorization manager logic240is configured to request authentication credentials from an entity being added to the white list and to store the authentication credentials in the white list. The authorization manager logic240may require that an entity's device be physically connected to the host device to be authorized. The white list may be maintained in FLASH memory to facilitate quick storage of binary files that correspond to authentication credentials.

FIG. 3illustrates one embodiment of a system300that includes a host network device310that provides secure WOL. The host network device310includes a host CPU315and a network CPU120. The host CPU315executes processes to perform the host network device's function. If the host network device is a router, the host CPU315executes processes that parse packet headers and so on. The host CPU315will enter the power-saving sleep mode during periods of inactivity or device manufacturer prescribed power sleep periods. The network CPU120executes processes that are necessary to handle network communication. The network CPU120does not enter the sleep mode when the host CPU315enters the sleep mode.

A white list is stored in memory associated with the network CPU120. In contrast to the embodiment illustrated inFIG. 2the authorization manager logic140that maintains the white list resides in a different network device (e.g., network device A) from the host network device315. The embodiment illustrated inFIG. 3may be advantageous when the host device310does not have a user-friendly interface for compiling the white list by receiving credentials for entities that are being authorized to access the host device310. When the host CPU315is not in sleep mode, the authorization manager logic140manages access to the host device310. When the host CPU315is entering the sleep mode, the authorization manager logic140transfers the white list to the host device315for storage in memory associated with the network CPU120. After the white list is stored, the host CPU315is able to handle secure WOL.

The sleep manager logic130manages the host device's interaction with other devices while the host device310is asleep. When a request is received from a network device to wake the host network device310, the sleep manager logic130accesses the white list. The sleep manager logic130is configured to wake the host CPU315when a WOL request is received from a device having credentials for an entity on the white list.

FIG. 4illustrates one embodiment of a method400for providing secure WOL for a host device. The method400may be performed by the sleep manager logic130described with reference toFIGS. 1-3. The method includes, at410, receiving a request from a requesting entity to wake a host device. At420, the method includes accessing a white list that includes credentials for entities that are authorized to wake the host device. At430, a determination is made as to whether credentials for the requesting entity are on the white list. When the credentials for the requesting entity are on the white list, at440the host device is woken. When the credentials for the requesting entity are not on the white list, the method returns to410and the host device is not woken.

In one embodiment, prior to the method accessing the white list at420, an authentication procedure is performed to authenticate the requesting entity's identify (regardless of whether the requesting entity is on the white list). The method accesses the white list at420only when the requesting entity is authenticated.

In one embodiment, upon receiving the request to wake the host device, the method includes requesting an authentication credential from the requesting entity and matching the authentication credential to authentication credentials stored on the white list. In one embodiment, the method includes receiving the white list from authorization manager logic that uses the white list to manage access to the host device when the host device is not in the sleep mode.

FIG. 5illustrates one embodiment of a network device500that provides secure WOL. The device500includes a network interface controller (NIC)510and a security interface logic530. The security interface logic530is configured input a white list that lists credentials for entities that are authorized to wake the device500from a power-saving sleep mode. In one embodiment, the security interface logic530includes a shared or common register or memory. The NIC510includes a network CPU120that includes memory configured to store the white list and sleep manager logic130. The sleep manager logic130is configured to receive a request from a requesting entity (not shown) to wake the device500; determine if credentials for the requesting entity are on the white list; wake the device500when the credentials for the requesting entity are on the white list; and refrain from waking the device500when the credentials for the requesting entity are not on the white list.

In one embodiment, the device500includes a host CPU515that includes authorization manager logic240configured to generate the white list. The authorization manager logic240manages the white list and is able to add or remove credentials for the authorized entities on the white list. The authorization manager logic240uses the white list to manage access to the device500when the device is not in the sleep mode. When the host CPU515is preparing to enter the sleep mode, the authorization manager logic240transfers a copy of the white list to the sleep manager logic130by way of the secure interface logic530.

When the Transport Layer Security (TLS) protocol is in use by the network, the sleep manager logic130acts as a server in relation to the TLS connections. The sleep manager logic130accepts a connection from an entity and requests a security certificate from the entity. The sleep manager logic130establishes a master key and verifies the entity. The entity signs the last message, which is a hash of all messages, with the secret key of its certificate. The sleep manager logic130verifies the signature using the entity's public key. If the signature is proper, a second verification is performed by hashing all the messages exchanged. If the second signature is proper, the TLS connection is maintained.

“Computer storage medium” as used herein is a non-transitory medium that stores instructions and/or data. A computer storage medium may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and so on. Volatile media may include, for example, semiconductor memories, dynamic memory, and so on. Common forms of a computer storage media may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other electronic media that can store computer instructions and/or data. Computer storage media described herein are limited to statutory subject matter under 35 U.S.C §101.

“Logic” as used herein includes a computer or electrical hardware component(s), firmware, a non-transitory computer storage medium that stores instructions, and/or combinations of these components configured to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. Logic may include a microprocessor controlled by an algorithm, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions that when executed perform an algorithm, and so on. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logics are described, it may be possible to incorporate the multiple logics into one physical logic component. Similarly, where a single logic unit is described, it may be possible to distribute that single logic unit between multiple physical logic components. Logic as described herein is limited to statutory subject matter under 35 U.S.C §101.

While for purposes of simplicity of explanation, illustrated methodologies are shown and described as a series of blocks. The methodologies are not limited by the order of the blocks as some blocks can occur in different orders and/or concurrently with other blocks from that shown and described. Moreover, less than all the illustrated blocks may be used to implement an example methodology. Blocks may be combined or separated into multiple components. Furthermore, additional and/or alternative methodologies can employ additional actions that are not illustrated in blocks. The methods described herein are limited to statutory subject matter under 35 U.S.C §101.