US20050010811A1 - Method and system to support network port authentication from out-of-band firmware - Google Patents

Method and system to support network port authentication from out-of-band firmware Download PDF

Info

Publication number
US20050010811A1
US20050010811A1 US10462996 US46299603A US2005010811A1 US 20050010811 A1 US20050010811 A1 US 20050010811A1 US 10462996 US10462996 US 10462996 US 46299603 A US46299603 A US 46299603A US 2005010811 A1 US2005010811 A1 US 2005010811A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
system
authentication
port
supplicant
method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10462996
Inventor
Vincent Zimmer
Michael Rothman
Greg Miller
Mark Doran
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • HELECTRICITY
    • H03BASIC ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same information or similar information or a subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction

Abstract

Methods and systems for performing network port authentication without requiring any operating system (OS) complicity are disclosed. Under one method, port authentication instructions are loaded into a protected memory space during a pre-boot of a supplicant system. In response to a port authentication request, the supplicant system's processor is switched to a hidden execution mode and executes the port authentication instructions to authenticate a network port hosted by an authenticator system to which the supplicant system is linked. One authentication process employs an authentication server that authenticates the supplicant via one of various authentication schemes, including an access challenge. Port authentication may also be performed via an out-of-band base management controller that operates independently from an operating system running on the supplicant.

Description

    FIELD OF THE INVENTION
  • The field of invention relates generally to network security and, more specifically but not exclusively relates to a technique for performing network port authentication via out-of-band firmware.
  • BACKGROUND INFORMATION
  • IEEE (Instituted of Electronic and Electrical Engineers) 802 Local Area Networks (LANs) are often deployed in environments that permit unauthorized devices to be physically attached to the LAN infrastructure, or permit unauthorized users to attempt to access the LAN through equipment already attached. Examples of such environments include corporate LANs that provide LAN connectivity in areas of a building that are accessible to the general public, and LANs that are deployed by one organization in order to offer connectivity services to other organizations (for example, as may occur in a business park or a serviced office building). In such environments, it is desirable to restrict access to the services offered by the LAN to those users and devices that are permitted to make use of those services. Furthermore, unauthorized users may cause harm to components coupled to the LAN infrastructure, such as application and data servers.
  • In view of the foregoing LAN vulnerabilities, the IEEE promulgated a standard (IEEE 802.1x, approved Jun. 14, 2001) covering port-based network access control. Port-based network access control makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases in which the authentication and authorization process fails. A port in this context is a single point of attachment to the LAN infrastructure. Examples of ports in which the use of authentication can be desirable include the Ports of MAC Bridges (as specified in IEEE 802.1D), the ports used to attach servers or routers to the LAN infrastructure, and associations between stations and access points in IEEE 802.11 Wireless LANs.
  • Authenticated network access mechanisms in accordance with IEEE 802.1x have been implemented at the operating system (OS) level, such as for the Microsoft Windows XP operating system, LINUX operating systems, and various UNIX-based operating systems. However, this does not solve the security problem for computing platforms that run operating systems without built-in 802.1x support. Add-on drivers, which typically are employed to extend the capabilities of a shrink-wrapped OS, are generally limited for network access purposes without having corresponding network access support already designed into the OS. Furthermore, since OS-based network port security capabilities don't exist prior to operating system runtime, they are not available for operations such as network-based operating system loading.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified:
  • FIG. 1 is a flowchart illustrating operations and logic performed during a network port authentication process in accordance with one embodiment of the invention.
  • FIG. 2 is a is a schematic diagram illustrating a scheme for loading various event handlers into a hidden memory space and executing the handlers in response to a SMI or PMI (xMI) event;
  • FIG. 3 is a schematic flow diagram illustrating an EAPOL-based authentication process in accordance with one embodiment of the invention;
  • FIG. 4 is a block schematic diagram illustrating an embodiment of the invention in which a base management controller is employed for port authentication;
  • FIG. 5 is a flowchart illustrating operations corresponding to a mixed authentication scheme in which firmware may be used for port authentication during pre-boot, while an operating system is employed for port authentication during OS-runtime; and
  • FIG. 6 is a schematic diagram illustrating a computer system for practicing embodiments of the invention.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • Embodiments of methods and apparatus and systems to support network port authentication from out-of-band firmware are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
  • Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
  • Throughout this specification, several terms of art are used. These terms are to take on their ordinary meaning in the art from which they come, unless specifically defined herein or the context of their use would clearly suggest otherwise. An “Authenticator” is an entity at one end of a point-to-point LAN segment that facilitates authentication of the entity attached to the other end of the link. An “Authentication Server” is an entity that provides an authentication service to an authenticator. This service determines, from the credentials provided by the supplicant, whether the supplicant is authorized to access the services provided by the authenticator. A “Network Access Port” or simply “Port” is a point of attachment in a system to a LAN. It can be a physical port, for example, a single LAN MAC (Media Access Control) attached to a physical LAN segment, or a logical port, for example, an IEEE 802.11 association between a station and an access point.
  • A “Port Access Entity” (PAE) is the protocol entity associated with a Port. It can support the protocol functionality associated with the authenticator, the supplicant, or both. A “Supplicant” is an entity at one end of a point-to-point LAN segment that is being authenticated by an authenticator attached to the other end of that link. Under conventional point-to-point link terminology, a Supplicant is the equivalent to a “peer.” A “System” is a device that is attached to a LAN by one or more ports. Examples of Systems include end stations (e.g., computer systems), servers, MAC Bridges, switches, and routers.
  • In addition to the foregoing terms, several acronyms and abbreviations are also used herein. These include EAP (extensible authentication protocol), EAPOL (EAP over LAN's), and RADIUS (remote authentication dial in user service).
  • In accordance with aspects of the invention, embodiments of firmware-based network port access schemes are disclosed that support network port authentication during the system pre-boot. Furthermore, firmware-based techniques are also disclosed for providing network port authentication during operating system runtime without requiring any OS complicity. Thus, systems employing the firmware components disclosed herein are enabled to support network port authentication even though they may run operating systems that do not inherently provide this support. This enables IT managers and the like to provide enhanced LAN security without requiring OS upgrades to the systems connected to the LAN infrastructure.
  • With reference to the flowchart of FIG. 1, initialization and operating system runtime operations corresponding to a firmware-based port authentication scheme in accordance with one embodiment proceed as follows. First, a system initialization sequence is performed in response to a power on or reset event depicted in a start block 100. In a block 102, early system initialization if performed by loading and executed portions of the system firmware. During this timeframe, the input/output (I/O) complex is initialized, along with the system's main memory.
  • In one embodiment, a Trusted Computing Platform Alliance (TCPA) security scheme is employed to obtain authentication credentials. In accordance with this embodiment, a trusted platform module (TPM) is searched for in the host system. For example, integrated circuits have been recently introduced to support TPM functionality, such as National Semiconductor's LPC-based TCPA-compliant security controller (Model number PC21100). Optionally, a software-based TPM may be employed. In a decision block 104, a determination is made to whether a TPM is discovered. If it is, a command to make identity and enable key-pair for the pre-boot environment is issued in a block 106; otherwise block 106 is skipped.
  • TCPA is an industry consortium concerned with platform and network security. The TCPA main specification, Version 1.1b, February, 2002 (http://www.trustedcomputing.org), is a platform-independent industry specification that covers trust in computing platforms in general. TCPA implements a trusted platform subsystem that employs cryptographic methods when establishing trust. The trusted platform may be embodied as a device or devices, or may be integrated into some existing platform component or components. The trusted platform enables an authentication agent to determine the state of a platform environment and seal data particular to that platform environment. Subsequently, authentication data (e.g., integrity metrics) stored in a TPM may be returned in response to an authentication challenge to authenticate the platform.
  • A “trusted measurement root” measures certain platform characteristics, logs the measurement data, and stores the final result in a TPM (which contains the root of trust for storing and reporting integrity metrics. When an integrity challenge is received, the trusted platform agent gathers the following information: the final results from the TPM, the log of the measurement data from the trusted platform measurement store, and TCPA validation data that states the values that the measurements should produce in a platform that is working correctly. The operations of making an identity and enabling key-pair for the pre-boot environment enables TPM functionality to be employed for authentication purposes during and after pre-boot, such as discussed below with reference to FIG. 3.
  • Next, in a block 1008, firmware-based supplicant SMM (system management mode) code is loaded into SMRAM (system management RAM) and the SMRAM is looked. Further details of this operation are discussed below with reference to FIG. 2. Since the 386SL processor was introduced by the Intel® Corporation, SMM has been available on IA32 (Intel Architecture 32 bit) processors as an operation mode hidden to operating systems that executes code loaded by BIOS or firmware. SMM is a special-purpose operating mode provided for handling system-wide functions like power management, system hardware control, or proprietary OEM-designed code. The mode is deemed “hidden” because the operating system (OS) and software applications cannot see it, or even access it. IA32 processors are enabled to enter SMM via activation of an SMI (System Management Interrupt) signal. A similar signal called the PMI (Processor Management Interrupt) signal that is roughly analogous to the SMI signal is used for Itanium™-class processors. For simplicity, both SMI and PMI signals are sometimes referred to as xMI signals herein.
  • Additional firmware load and execution operations are performed to prepare the system for OS boot (not shown). Once the system is ready to boot an operating system, a determination is made in a decision block 110 to whether a network boot request is made. In brief, a network boot request corresponds to a situation in which the system is directed to boot from an operating system image that is stored on a network, rather than booting for a local OS image. If this is the case, a network port authentication to enable access to the network on which the network OS image is stored is performed.
  • This process begins in a block 112, wherein in xMI is invoked upon the system's processor. In response to the xMI, the processor stores its current context (i.e., information pertaining to current operations, including its current execution mode, stack and register information, etc.), and switches its execution mode to its system management mode. SMM handlers are then sequentially dispatched to determine if they are the appropriate handler for servicing the xMI event. This determination is made very early in the SMM handler code, such that there is little latency in determining which handler is appropriate. When this handler is identified, it is allowed to execute to completion to service the SMI event. Subsequent handlers may also be dispatched to provide related service functions. After the xMI event is serviced, an RSM (resume) instruction is issued to return the processor to its previous execution mode using the previously saved context data. The net result is that SMM operation is completely transparent to the operating system.
  • In this particular instance, the xMI event is invoked to perform network port authentication. Accordingly, in a block 114 supplicant SMM code, in the form of SMM handlers, is executed to perform EAP exchange operations to authenticate the port, as described below in further detail with reference to FIG. 3. Once authenticated, an operating system image is loaded from the network store in a block 116. In the event that a boot request is not made, the operating system is loaded in the normal manner from a local storage device, such as a disk drive with a boot partition (most common) or a CDROM drive. This completes the initialization sequence.
  • The operations and logic shown on the right-hand portion of FIG. 1 correspond to operations performed during operating system runtime. In accordance with aspects of the invention, a mechanism is provided to enable OS runtime port authentication in an OS agnostic manner. That is, the technique is effectuated without any operating system complicity, and, in fact, is performed in a manner transparent to the operating system. As a result, computer systems running operating systems that do not provide inherent support for port authentication are enabled to access secure network infrastructure.
  • In one embodiment, the mechanism is facilitated through use of the SMM mode in a manner similar to that discussed above during the pre-boot. However, since no OS complicity is to be involved, there needs to be a mechanism that kicks the processor into SMM. In one embodiment this is accomplished by employing a timer to generate periodic xMI assertions on the processor. In connection with the OS load, a timer 122 is setup to periodically assert xMl's.
  • In response to each timer-invoked xMI, the operations delineated by respective start and end loop blocks 124 and 125 are performed. First, in a block 126 an OS-runtime portion of the supplicant SMM code is dispatched to service the xMI. During execution of the supplicant SMM code, a determination is made in a decision block 128 to whether a new port connection has been established, or a port has been reconnected to another connection. If not, an RSM instruction is issued in a block 130 to return the processor to its previous execution context, and the processor returns to performing OS runtime operations until the next timer-invoked xMI occurs.
  • If the answer to decision block 128 is YES, operations in a block 132 are performed to ensure that there is no current network traffic present at the port. The reason for this is that the supplicant SMM code takes control of the port, and thus any OS-complicit network traffic will be lost once port control is handed off. Once it is determined that the network traffic on the port is clear, the Supplicant SMM code is executed to authenticate the port via the EAP exchange operations of FIG. 3 in a manner similar to block 114.
  • As discussed above, firmware-based supplicant SMM code is loaded into SMRAM in block 108. An exemplary scheme for loading xMI event handlers and subsequent access mechanism is illustrated in FIG. 2. The scheme employs an agent that registers drivers that runs in the EFI (Extensible Firmware Interface) boot-services mode (i.e., the mode prior to operating system launch) and is composed of a CPU-specific component that binds the drivers and a platform component that abstracts chipset control of the xMI (PMI or SMI) signals. The API's (application program interfaces) providing these sets of functionality are referred to as the SMM Base and SMM Access Protocol, respectively.
  • In conventional SMM implementations, SMM space is often locked by the platform software/firmware/BIOS via hardware mechanisms before handing off control; this grants firmware the ability to abstract the control and security of this binding. In contrast, the software abstraction via the SMM Access protocol obviates the need of users of this facility to know and understand the exact hardware mechanism, thus allowing drivers to be portable across many platforms.
  • The access scheme of FIG. 2 includes the following features: a library in SMM for the drivers' usage, including an I/O access abstraction and memory allocation services; a means to communicate with drivers and applications executing in non-SMM mode; an optional parameter for periodic activation at a given frequency; a means to authenticate the drivers on load into SMM; the ability to close the registration capability; the ability to run in a multi-processor environment where many processors receive the xMI activation; and finally, the capability to run legacy IA32 SMM code as a distinguished registered event handler. A characteristic of the system is that all event handlers run in the native processor mode of Itanium™ or in the case of IA32, the framework will put the processor into flat 32 mode prior to invoking the event handlers, while running the optional legacy IA32 handler(s) in real-mode (i.e., 16-bit mode).
  • The implementation of the FIG. 2 load and access scheme is enabled through use of an extensible firmware framework known as Extensible Firmware Interface (EFI) (specifications and examples of which may be found at http://developer.intel.com/technology/efi). EFI is a public industry specification (current version 1.10 released Jan. 7, 2003) that describes an abstract programmatic interface between platform firmware and shrink-wrap operation systems or other custom application environments. The EFI framework include provisions for extending BIOS functionality beyond that provided by the BIOS code stored in a plafform's BIOS device (e.g., flash memory). More particularly, EFI enables firmware, in the form of firmware modules and drivers, to be loaded from a variety of different resources, including primary and secondary flash devices, option ROMs, various persistent storage devices (e.g., hard disks, CD ROMs, etc.), and even over computer networks. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.
  • The process for producing the SMM extensibility framework is initiated in a block 210, wherein The SMM extensibility framework is instantiated. This includes installing an EFI SMM base protocol driver in a block 212. The EFI SMM base protocol, SMM_BASE, is a CPU-specific protocol that is published by the CPU driver or another agency that can abstract the ISA-specific details of an IA32 or Itanium processor. Once installed, SMM_BASE publishes an SMM handler register service in a block 214. Publication of the handler register service enables legacy and add-on drivers that are stored on various storage devices, including an EFI system partition 216, a BIOS flash chip 218 and on a storage device accessed via a network 220 to register SMM event handlers in a block 222. In addition to these types of storage devices, the drivers may be stored on other persistent storage devices that are accessible to the computer system in which the invention is implemented, including motherboard-based ROMs, option-ROMs contained on add-on peripheral cards, local hard disks and CD ROMs, which are collectively depicted by a firmware volume 223. (It is noted that EFI system partition 216, BIOS flash chip 218 and the remote storage device on which driver 6 resides also may comprise firmware volumes.) As depicted in FIG. 2, these drivers include a legacy driver 1 and an add-on driver 2 stored in EFI system partition 216, add-on drivers 3, 4, and 5, which are stored on BIOS flash chip 218, and an add-on driver 6 that is accessed from a remote storage device (e.g., file server) via network 220. As used herein, the term “add-on” corresponds to drivers and firmware files that were not provided with the original firmware of the computer system as provided by the original equipment manufacture (OEM) of that system.
  • In an optional mode, the EFI SMM base protocol driver may scan various firmware volumes to identify any drivers that are designated for servicing xMI events via SMM. In one embodiment, these drivers are identified by their file type, such as exemplified by a “DRIVER7.SMH” file 225 corresponding to an add-on driver 7.
  • During the installation of the EFI SMM base protocol driver, an SMM Nub 224 is loaded into SMRAM 226, which comprises an SMM-only memory space. SMM Nub 224 is responsible for coordinating all activities while control is transferred to SMM, including providing an SMM library 228 to event handlers that includes PCI and I/O services 230, memory allocation services 232, and configuration table registration 234.
  • Registration of an SMM event handler is the first step in enabling the handler to perform a particular xMI event servicing function it is designed to perform. An SMM event handler comprises a set of code (i.e., coded machine instructions) that when executed by the system processor (CPU) performs an event service function in a manner similar to an interrupt service routine. Typically, each SMM event handler will contain code to service a particular hardware component or subsystem, or a particular class of hardware. In the context of the present invention, supplicant SMM handlers are employed for network port authentication operations. In general, there may be some correspondence between a given driver and an SMM event handler. However, this is not a strict requirement, as the handlers may comprise a set of functional blocks extracted from a single driver file or object.
  • When the event handler for legacy driver 1 is registered, it is loaded into SMRAM 226 as a legacy handler 236. A legacy handler is an event handler that is generally provided with the original system firmware and represents the conventional mechanism for handling an xMI event. As each add-on SMM event handler is registered in block 222, it is loaded into an add-on SMM event handler portion 238 of SMRAM 226; once all of add-on event handlers are loaded, add-on SMM event handler portion 228 comprises a set of event handlers corresponding to add-on drivers 2-7, as depicted by a block 242. In addition, as each SMM event handler is registered, it may optionally be authenticated in a block 244 to ensure that the event handler is valid for use with the particular processor and/or firmware for the computer system. For example, an encryption method that implements a public key may be used. As SMM event handlers are registered, they are added to a list of handlers 246 maintained by SMM Nub 224.
  • Once all of the legacy and add-on SMM event handlers have been registered and loaded into SMRAM 226 and proper configuration data (metadata) is written to SMM Nub 224, the SMRAM is locked, precluding registration of additional SMM event handlers. This system is now ready to handle various xMI events via SMM.
  • The Ports of a System provides the means by which the system can access services offered by other systems reachable via a network (e.g., LAN), and provides the means by which the system can offer services to other systems reachable via the network. Port-based network access control allows the operations of a system's port(s) to be controlled in order to ensure that access to its services is only permitted by systems that are authorized to do so.
  • For the purpose of describing the operation of Port-based access control, a Port of a System (or more correctly, its Port Access Entity) is able to adopt one of two distinct roles within an access control interaction:
      • a) Authenticator: The Port that wishes to enforce authentication before allowing access to services that are accessible via that Port adopts the Authenticator role;
      • b) Supplicant: The Port that wishes to access the services offered by the Authenticator's system adopts the Supplicant role.
  • A further System role corresponds to c) Authentication Server: The Authentication Server performs the authentication function necessary to check the credentials of the Supplicant on behalf of the Authenticator and indicates whether the Supplicant is authorized to access the Authenticator's services.
  • A given system can be capable of adopting one or more of these roles; for example, an Authenticator and an Authentication Server can be collocated within the same System, allowing that System to perform the authentication function without the need for communication with an external server. However, the most common implementation will likely involve the use of an Authentication Server that is external to Systems that contain the Authenticators, such as shown in FIG. 3.
  • The Port Access Entity (PAE) operates the algorithms and protocols associated with the authentication mechanisms of a given System Port. In the Supplicant role, the PAE is responsible for responding to requests from an Authenticator for information that will establish its credentials. The PAE that performs the Supplicant roles in an authentication exchange is known as the Supplicant PAE. For simplicity and clarity, interactions described below with reference to FIG. 3 are discussed in terms of the communicating Systems rather than the PAEs of those systems.
  • Port Access Control provides an optional extension to the functionality of a System that offers a means of preventing unauthorized access by Supplicants to the services offered by that System. For example, if the System concerned is a MAC Bridge, control over access to the Bridge and the LAN to which it is connected can be desirable in order to restrict access to publicly accessible Bridge Ports, or within an organization, to restrict access to a departmental LAN to members of that department.
  • Access control is achieved by the System enforcing authentication of Supplicants that attach to the System's controlled Ports; from the result of the authentication process, the System can determine whether or not the Supplicant is authorized to access its services on that controlled Port. If the Supplicant is not authorized for access, the System sets the controlled Port state to unauthorized. In the unauthorized state, the use of the controlled Port is restricted in accordance with the value of the OperControlledDirections parameter associated with that controlled Port, preventing unauthorized data transfer between the Supplicant and the services offered by the System.
  • The IEEE 802.1x standard provides a protocol for communicating authentication information between a Supplicant, attached to a Port of an Authenticator System, and an Authentication Server, and for controlling the state of the Authenticator System's Port, depending on the outcome of the protocol exchange. This standard does not specify the nature of the authentication information that is exchanged, nor the basis upon which the Authentication Server makes its authentication decisions. Thus, one of many well-known authentication schemes may be deployed in conjunction with Port Authentication under IEEE 802.1x.
  • A Port Access Entity exists for each Port of a System that participates in Port-based access control. The PAE is able to operate in the role of a Supplicant or of an Authenticator or both. An Authenticator PAE is responsible for enforcing the authentication of a Supplicant PAE that attaches to its controlled Port and for controlling the authorization state of the controlled Port accordingly. In order to perform the authentication, the Authenticator PAE makes use of an Authentication Server. Communication between the Supplicant PAE and the Authenticator PAE, and between the Authenticator PAE and the Authentication Server (when the Authentication Server is not co-located with the Authenticator), is achieved by means of the protocols and procedures defined in IEEE 802.1x specification.
  • A Supplicant PAE is responsible for communicating the credentials of the Supplicant to the Authenticator PAE in response to requests from the Authenticator PAE. The Supplicant PAE may also initiate authentication exchanges and perform EAPOL-Logoff exchanges.
  • Authentication occurs primarily at System initialization time, or when a Supplicant System is connected to a Port of an Authenticator System. Until authentication has successfully completed, the Supplicant System only has access to the Authenticator System to perform authentication exchanges, or to access any services offered by the Authenticator's System that are not subject to the access control restrictions placed on the Authenticator's controlled Port. Once authentication has successfully completed, the Authenticator System allows full access to the services offered via the Authenticator System's controlled Port.
  • The operation of the authentication process makes use of the Extensible Authentication Protocol (EAP, specified in IETF RFC 2284) as the means for communicating authentication information between the Supplicant and the Authentication Server. EAP is a general protocol that supports multiple authentication mechanisms. For example, through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key Encryption, One Time Passwords, and others.
  • The Authenticator PAE controls the operational state of its controlled Port, but it does not interfere with the authentication exchanges between the Supplicant PAE and the Authentication Server. This separation between the Authenticator PAE and the authentication function permits the use of a backend Authentication Server that implements the various mechanisms needed to authenticate a Supplicant PAE. The Authenticator PAE simply controls the authorization state of its controlled Port based on the results of the authentication exchange. A full description of the authentication function can be found in IETF RFC 2869, and guidelines for the use of RADIUS in IEEE 802.1X can be found in Annex D of the IEEE Std 802.1X-2001 document.
  • FIG. 3 shows a network port authentication scheme that is implemented via authentication services provided by a RADIUS server in accordance with one embodiment. In the illustrated network infrastructure depicted at the top of FIG. 3, a Supplicant 300 is connected to an 802.1x switch 304 via an Ethernet cable 302. The 802.1x switch, functioning as an Authenticator, enables authorized systems coupled to the switch via a respective port to access network resources coupled to a secure subnet 306, such as an application server 308. Access to subnet 306 is managed by a RADIUS server 310, which comprises an Authentication Server. In effect, RADIUS server 310 interacts with 802.1x switch 304 to control access of systems external to secure subnet 306, such as supplicant 300, from accessing the secure subnet, by authenticating the switch ports to which those systems are connected.
  • Authentication can be initiated either by the Supplicant PAE or by the Authenticator PAE. The Supplicant-initiated port authentication process illustrated in FIG. 3 proceeds as follows. Initially, Supplicant 300 connects to subnet 302 an attempt is made by the supplicant to obtain network access to secure subnet 306 via 802.1x switch 304. Since the switch's network port to which Supplicant 300 is connected is not authenticated at this point, the access is blocked. However, Supplicant 300 is still enabled to access an Authenticator (802.1x switch 304).
  • In accordance with one embodiment, an encapsulation form of EAP (EAPOL) is used for all communication between the Supplicant PAE of Supplicant 300 and the Authenticator PAE of 802.1x switch 304. At present, EAPOL encapsulations are described for 802.3/Ethernet MACs and Token Ring/FDDI MACs. The EAPOL encapsulation used with 802.3/Ethernet MACs can be applied to other LAN technologies that share the same basic frame format as Ethernet (for example, IEEE Std 802.12 Demand Priority operating in IEEE Std 802.3 compatibility mode). Similarly, the EAP encapsulation used with Token Ring/FDDI MACs can be applied to other LAN technologies that share the same basic frame format as IEEE Std 802.5 Token Ring (for example, FDDI or IEEE Std 802.12 Demand Priority operating in IEEE Std 802.5 compatibility mode). Further details of EAPOL frames, PDU (physical data unit) fields and parameter definitions, addressing, and other related topics are contained in Section 7 of IEEE Std. 802.1x-2001.
  • In response to receiving data via EAPOL, the Authenticator PAE can then repackage the EAP protocol for onward transmission to the Authentication Server, if the server function is not co-located. Repackaging is necessary when the protocol employed for accessing the Authentication Server is different than EAPOL. For example, RADIUS offers one suitable means of providing this latter aspect of communication; however, this may be achieved by the use of other protocols, as well. The dashed lines on the right-hand side of FIG. 3 indicate the protocol used for communications between the 802.1x switch and the RADIUS server is different than the EAPOL protocol used between the Supplicant and the switch.
  • Returning to FIG. 3, Supplicant 300 initiates an authentication by sending an EAPOL-Start frame 314 to 802.1x switch 304. In response to receiving the start frame, the 802.1x switch sends back an EAP Identity Request. 316. Supplicant 300 then sends an Identity Response 318 back to the 802.1x switch 304.
  • At this point, the switch begins an authentication process with RADIUS server 310. First, a RADIUS access request 320 is sent from 802.1x switch 304 to RADIUS server 310. The RADIUS server responds by issuing an access challenge 322. This is repackaged into EAPOL form and forwarded to Supplicant 300 as an EAP request 324.
  • An access challenge (or authentication challenge) corresponds to a common technique for authenticating an unknown, non-trusted entity (in this case Supplicant 300). Rather than only permitting a predetermined authentication method, EAP allows the Authenticator PAE to request more information before determining the specific authentication mechanism. In EAP, the authenticator PAE sends one or more Requests to authenticate the Supplicant PAE. The Request has a type field to indicate what is being requested. Examples of Request types include Identity, MD5-challenge, One-Time Passwords, and Generic Token Card. The MD5-challenge type corresponds closely to the CHAP authentication protocol. Typically, the authenticator will send an initial Identity Request followed by one or more Requests for authentication information. However, an initial Identity Request is not required, and it may be bypassed in cases in which the identity is presumed. The Supplicant PAE sends a Response packet in reply to each Request. As with the request packet, the Response packet contains a type field that corresponds to the type field of the Request.
  • After a selected or default authentication scheme is identified, the authenticator entity issues a challenge to the non-trusted entity. The non-trusted entity must then reply with information corresponding to the challenge to prove that the entity is trustworthy.
  • In one embodiment, a public key technique in accordance with Transport Layer Security (TLS, RFC2716) is employed for the challenge-response operations. TLS requires the existence of some credentials on the client, such as a public-key certificate and the associated key-pair in the machine. In accordance with the discussion of the TPM above, the key-pair function is enabled in block 106. This deployment further relies on some Public Key Infrastructure (PKI) available to the authenticator and associated directory to associate client machines (i.e., Supplicants) with their key-pairs.
  • In response to EAP request 324, Supplicant 300 sends authentication credentials 326 to 802.1x switch 304. The switch then repackages the response and forwards the credentials to RADIUS server 310 via an Access Request 328. If authenticated via the credentials, the RADIUS server sends an Access-Accept to 802.1x switch 304, which then opens the Port to allow Supplicant 300 to access secure subnet 306. If the credentials are insufficient (i.e., the Supplicant cannot be authenticated), the Port is left blocked to the Supplicant).
  • In one embodiment Supplicant EAPOL operations shown on the left-hand side of flow diagram 312 are implemented via one or more supplicant SMM handlers. As discussed above, the SMM handlers may be dispatched and executed in response to an xMI event. In one embodiment, supplicant 300 is enabled to implement supplicant SMM handlers via a callable interface, which may be accessed via either firmware or software (e.g., the OS). In one embodiment, the callable interface comprises an ACPI (Advanced Configuration and Power Interface) 2.0 Fixed ACPI Description table (FACP) entry with the system port used to generate a synchronous xMI. This access facility employs an “Authenticate Port” xMI command entry. When invoking this service, the OS shall acquiesce and block its native networking driver from using the port.
  • With reference to FIG. 4, in another embodiment the Supplicant EAPOL operations are implemented via a Baseboard Management Controller (BMC) 400. BMCs provide out-of-band management support for computing platforms, such as computer servers. This enables management functions to be performed without requiring any OS complicity—in fact, management functions are still enabled even if the OS hangs.
  • Typically, BMC 400 will be mounted or otherwise communicatively coupled to a baseboard 402. Also coupled to the baseboard is a network interface controller (NIC) 404. BMC 406 has access to NIC 404 via TCO port 406. Machine-executable instructions (i.e., code) 408 comprising an algorithm for supporting the network port authentication operations discussed above may be stored in either BMC 400 or a non-volatile storage device 410.
  • In one embodiment, BMC 400 comprises an IPMI-compliant baseboard management controller. Accordingly, code 408 can be dispatched for execution via an IPMI message to the BMC to “request” authentication of the platform's port.
  • In accordance with another aspect of the invention, a “mixed” authentication scheme may be implemented, wherein firmware supports port authentication during pre-boot, while OS-runtime port authentication is provided by and 802.1x compliant operating system. This scheme is graphically illustrated in FIG. 5, wherein authentication credentials are retrieved and/or generated during pre-boot. For example, in cases in which credentials are stored in a TPM, the credentials may be retrieved from the TPM during pre-boot. The authentication credentials are then passed to the operating system upon load or in response to a port authentication request in a block 502, enabling the operating system to perform a port authentication process that employs the credentials.
  • EXEMPLARY COMPUTER SYSTEM FOR PRACTICING EMBODIMENTS OF THE INVENTION
  • With reference to FIG. 6, a generally conventional computer 600 is illustrated, which is suitable for use as supplicant systems, and authentication servers in connection with practicing embodiments of the invention. Examples of computers that may be suitable for supplicant systems as discussed above include PC-class systems operating the Windows NT or Windows 2000 operating systems, Sun workstations operating the UNIX-based Solaris operating system, and various computer architectures that implement LINUX operating systems. Computer 600 is also intended to encompass various server architectures, as well as computers having multiple processors.
  • Computer 600 includes a processor chassis 602 in which are mounted a floppy disk drive 604, a hard drive 606, a motherboard 608 populated with appropriate integrated circuits including memory 610 and one or more processors (CPUs) 611, as are generally well known to those of ordinary skill in the art. The computer also includes a boot firmware device 612 comprising a flash device in which a base portion of Firmware is stored. As discussed above, with reference to FIG. 2, firmware components, including SMM handlers, may be stored in boot firmware device 612, or may be loaded from other storage devices. In one embodiment, a TPM 613 in which authentication credentials are stored is coupled to motherboard 608. A power supply (not shown) is used to provide power to motherboard 608 and various peripheral devices discussed below. It will be understood that hard drive 606 may comprise a single unit, or multiple hard drives, and may optionally reside outside of computer 600. A monitor 614 is included for displaying graphics and text generated by software programs and program modules that are run by the computer. A mouse 616 (or other pointing device) may be connected to a serial port (or to a bus port or USB port) on the rear of processor chassis 602, and signals from mouse 616 are conveyed to the motherboard to control a cursor on the display and to select text, menu options, and graphic components displayed on monitor 614 by software programs and modules executing on the computer. In addition, a keyboard 618 is coupled to the motherboard for user entry of text and commands that affect the running of software programs executing on the computer. Computer 600 also includes a network interface card 620 or built-in network adapter for connecting the computer to a computer network, such as a local area network, wide area network, or the Internet.
  • Computer 600 may also optionally include a compact disk-read only memory (CD-ROM) drive 622 into which a CD-ROM disk may be inserted so that executable files and data on the disk can be read for transfer into the memory and/or into storage on hard drive 606 of computer 600. Other mass memory storage devices such as an optical recorded medium or DVD drive may be included. The machine instructions comprising the software that causes the CPU to implement the functions of the present invention that have been discussed above will likely be distributed on floppy disks or CD-ROMs (or other memory media) and stored in the hard drive until loaded into random access memory (RAM) for execution by the CPU. Optionally, all or a portion of the machine instructions may be loaded via a computer network.
  • Thus, embodiments of the invention may be used as or to support a machine-executable instructions executed upon some form of processing core (such as the CPU of a computer) or otherwise implemented or realized upon or within a machine-readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium can include such as a read only memory (ROM); a random access memory (RAM); a magnetic disk storage media; an optical storage media; and a flash memory device, etc. In addition, a machine-readable medium can include propagated signals such as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).
  • The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
  • These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.

Claims (30)

  1. 1. A method comprising:
    loading port authentication firmware instructions in a supplicant system; and
    authenticating a network port hosted by an authenticator system to which the supplicant system is linked via execution of the port authentication firmware instructions on the supplicant system.
  2. 2. The method of claim 1, wherein the network port is authenticated during a pre-boot phase.
  3. 3. The method of claim 2, further comprising loading an operating system image into the supplicant system over a network that is accessed via the network port that is authenticated.
  4. 4. The method of claim 1 wherein the network port is authenticated during an operating system (OS)-runtime phase.
  5. 5. The method of claim 4, wherein network port authentication is performed by executing the port authentication firmware using a hidden execution mode that is transparent to an operating system running on the supplicant system during the OS-runtime phase
  6. 6. The method of claim 5, wherein the hidden execution mode is a system management mode (SMM).
  7. 7. The method of claim 6, wherein the firmware instructions are embodied as one or more SMM handlers.
  8. 8. The method of claim 7, further comprising:
    asserting one of an SMI (system management interrupt) or PMI (Processor Management Interrupt) on a processor of the supplicant on a periodic basis;
    dispatching said one or more SMM handlers to handle the SMI or PMI event via operations including,
    determining if a network port needs to be authenticated; and, in response thereto,
    authenticating the network port.
  9. 9. The method of claim 1, wherein port authentication is performed using the EAPOL (extensible authentication protocol over local area network) protocol.
  10. 10. The method of claim 1, wherein the port is authenticated using an access/challenge scheme.
  11. 11. The method of claim 10, wherein the access/challenge scheme employs a Transport Layer Security (TLS) challenge response in which authentication is determined based on credentials provided by the supplicant system.
  12. 12. The method of claim 11, wherein the TLS challenge response employs credentials stored in a Trusted Platform Module (TPM), and wherein the method further comprises retrieving the credentials from the TPM.
  13. 13. The method of claim 1, wherein a determination of whether a port is authenticated is made by an authentication server that is linked in communication with the authenticator system.
  14. 14. The method of claim 1, further comprising providing an callable interface via which a port authentication process can be invoked.
  15. 15. A method comprising:
    executing instructions comprising port authentication code via a baseboard management controller (BMC) in a supplicant system to perform port authentication of a authenticator system port to which the supplicant system is linked in communication.
  16. 16. The method of claim 15, wherein the port authentication code is stored in a non-volatile storage device coupled to the BMC, the method further comprising loading the port authentication code into the BMC for execution.
  17. 17. The method of claim 15, wherein the port authentication is performed during an operating system runtime phase.
  18. 18. A method comprising:
    retrieving authentication credentials pertaining to a supplicant system during a pre-boot phase of the supplicant system;
    passing the authentication credentials to an operating system running on the supplicant system during an operating system runtime phase; and
    authenticating a network port to which the supplicant system is connected via use of the authentication credentials.
  19. 19. The method of claim 18, wherein the operating system is compliant with the IEEE 802.1x port-based network access control standard and authenticates the network port via an 802.1x authentication protocol.
  20. 20. The method of claim 19, wherein the network port is authenticated using a Transport Layer Security (TLS) challenge response in which authentication is determined based on the authentication credentials.
  21. 21. A machine-readable media on which firmware instructions are stored, which when executed by a supplicant system perform operations including:
    authenticating a network port hosted by an authenticator system to which the supplicant system is linked.
  22. 22. The machine-readable media of claim 21, wherein the media comprises a firmware storage device.
  23. 23. The machine-readable media of claim 21, wherein the firmware instructions comprise at least one system management mode (SMM) handler that is executed by a processor of the supplicant system while operating in SMM.
  24. 24. The machine-readable media of claim 21, wherein the network port is authenticated during a pre-boot phase of the supplicant system.
  25. 25. A supplicant system comprising:
    a processor;
    a network interface, coupled to the processor; and
    a flash device coupled to the processor, having firmware instructions stored therein that when executed on the processor perform operations including:
    authenticating a network port hosted by an authenticator system to which the supplicant system is linked in communication via the network interface.
  26. 26. The supplicant system of claim 25, further comprising a trusted platform module coupled to the processor, to store authentication credentials employed for authenticating the network port.
  27. 27. The supplicant system of claim 25, wherein the processor includes a hidden execution mode and the network port is authenticated during an operating system runtime phase via execution of firmware instructions under the hidden execution mode.
  28. 28. A supplicant system comprising:
    a baseboard management controller (BMC);
    a network interface, coupled to the baseboard management controller; and
    machine-executable instructions stored on the supplicant system, which when executed on the BMC perform operations including:
    authenticating a network port hosted by an authenticator system to which the supplicant system is linked in communication via the network interface.
  29. 29. The supplicant system of claim 28, further comprising a trusted platform module coupled to the BMC, to store authentication credentials employed for authenticating the network port.
  30. 30. The supplicant system of claim 28, wherein the machine-executable instructions are stored in one of the BMC or a non-volatile storage device coupled to that BMC.
US10462996 2003-06-16 2003-06-16 Method and system to support network port authentication from out-of-band firmware Abandoned US20050010811A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10462996 US20050010811A1 (en) 2003-06-16 2003-06-16 Method and system to support network port authentication from out-of-band firmware

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10462996 US20050010811A1 (en) 2003-06-16 2003-06-16 Method and system to support network port authentication from out-of-band firmware
EP20040753416 EP1634170B1 (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan
US10561049 US7934209B2 (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan
CN 200480016970 CN1809813B (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan
PCT/US2004/016585 WO2005002060A3 (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan

Publications (1)

Publication Number Publication Date
US20050010811A1 true true US20050010811A1 (en) 2005-01-13

Family

ID=33551376

Family Applications (2)

Application Number Title Priority Date Filing Date
US10462996 Abandoned US20050010811A1 (en) 2003-06-16 2003-06-16 Method and system to support network port authentication from out-of-band firmware
US10561049 Active 2027-10-22 US7934209B2 (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10561049 Active 2027-10-22 US7934209B2 (en) 2003-06-16 2004-05-26 Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan

Country Status (4)

Country Link
US (2) US20050010811A1 (en)
EP (1) EP1634170B1 (en)
CN (1) CN1809813B (en)
WO (1) WO2005002060A3 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050229249A1 (en) * 2004-04-09 2005-10-13 Piwonka Mark A Systems and methods for securing ports
US20060206286A1 (en) * 2005-03-11 2006-09-14 Dell Products L.P. Method to reduce IPMB traffic and improve performance for accessing sensor data
US20070006294A1 (en) * 2005-06-30 2007-01-04 Hunter G K Secure flow control for a data flow in a computer and data flow in a computer network
US20070002899A1 (en) * 2005-06-30 2007-01-04 Anant Raman Methodology for network port security
US20070172063A1 (en) * 2006-01-20 2007-07-26 Microsoft Corporation Out-Of-Band Authentication for Automated Applications ("BOTS")
US20080098392A1 (en) * 2006-10-19 2008-04-24 Wipfel Robert A Verifiable virtualized storage port assignments for virtual machines
US20080244688A1 (en) * 2007-03-29 2008-10-02 Mcclain Carolyn B Virtualized federated role provisioning
US20090180471A1 (en) * 2005-12-19 2009-07-16 Subash Bohra System and method for port mapping in a communications network switch
US20090212844A1 (en) * 2008-02-26 2009-08-27 Dell Products L.P. Information Handling System Port Security
US20090245514A1 (en) * 2007-11-30 2009-10-01 Sony Corporation Forensic decryption tools
US20090260081A1 (en) * 2008-04-14 2009-10-15 Tecsys Development, Inc. System and Method for Monitoring and Securing a Baseboard Management Controller
US20100088499A1 (en) * 2005-12-20 2010-04-08 Zimmer Vincent J Seamless data migration
US20100153697A1 (en) * 2008-12-17 2010-06-17 Jeremy Ford Methods and systems for embedded user authentication and/or providing computing services using an information handling system configured as a flexible computing node
US20100235648A1 (en) * 2009-03-10 2010-09-16 Quy Hoang Methods and systems for binding a removable trusted platform module to an information handling system
US7991932B1 (en) 2007-04-13 2011-08-02 Hewlett-Packard Development Company, L.P. Firmware and/or a chipset determination of state of computer system to set chipset mode
US20140364130A1 (en) * 2006-06-09 2014-12-11 Trapeze Networks, Inc. Untethered access point mesh system and method
US9838942B2 (en) 2006-06-09 2017-12-05 Trapeze Networks, Inc. AP-local dynamic switching

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050091191A1 (en) * 2003-09-24 2005-04-28 Greg Miller System and method for managing and utilizing information
US8041742B1 (en) 2004-12-20 2011-10-18 American Megatrends, Inc. Method, system, and apparatus for providing generic database services within an extensible firmware interface environment
US7873807B1 (en) * 2006-07-28 2011-01-18 American Megatrends, Inc. Relocating a program module from NVRAM to RAM during the PEI phase of an EFI-compatible firmware
US7925875B2 (en) * 2006-12-31 2011-04-12 Sandisk Corporation Systems and methods for identifying and booting a computer architecture
US20080162916A1 (en) * 2006-12-31 2008-07-03 Sandisk Corp. Portable Multi-Platform Booting
US20090083725A1 (en) * 2007-09-20 2009-03-26 Zhenghong Wang Firmware upgrading method for an interface card
US8809705B2 (en) * 2007-12-04 2014-08-19 General Electric Company Device and method for switching electrical energy
DE102008010556A1 (en) * 2008-02-22 2009-09-03 Robert Bosch Gmbh Method and device for storing information data
CN101339597B (en) * 2008-08-28 2011-10-05 飞天诚信科技股份有限公司 Method, system and equipment for upgrading read-write machine firmware
US8438423B1 (en) * 2009-03-31 2013-05-07 American Megatrends, Inc. Invalid setup recovery
US8526290B2 (en) * 2009-08-17 2013-09-03 Mediatek Inc. Data compression/decompression method, data decompression method, and optical disc drive utilizing the method
JP5626786B2 (en) * 2010-11-09 2014-11-19 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation Software development support method and software development support system and software development support program
US9378560B2 (en) * 2011-06-17 2016-06-28 Advanced Micro Devices, Inc. Real time on-chip texture decompression using shader processors
US8924737B2 (en) 2011-08-25 2014-12-30 Microsoft Corporation Digital signing authority dependent platform secret
US8866649B2 (en) * 2011-09-14 2014-10-21 Netapp, Inc. Method and system for using non-variable compression group size in partial cloning
US9529708B2 (en) 2011-09-30 2016-12-27 Intel Corporation Apparatus for configuring partitions within phase change memory of tablet computer with integrated memory controller emulating mass storage to storage driver based on request from software
WO2013048491A1 (en) 2011-09-30 2013-04-04 Intel Corporation Apparatus, method and system that stores bios in non-volatile random access memory
WO2013048483A1 (en) * 2011-09-30 2013-04-04 Intel Corporation Platform storage hierarchy with non-volatile random access memory having configurable partitions
WO2013048485A1 (en) 2011-09-30 2013-04-04 Intel Corporation Autonomous initialization of non-volatile random access memory in a computer system
EP2807565A4 (en) * 2012-01-29 2015-12-02 Thomson Licensing Method for flash compressed instruction caching for limited ram/flash device architectures
US9128798B2 (en) * 2012-10-17 2015-09-08 Movimento Group Module updating device
US20140215170A1 (en) * 2013-01-31 2014-07-31 Futurewei Technologies, Inc. Block Compression in a Key/Value Store
US20140282447A1 (en) * 2013-03-13 2014-09-18 Vmware, Inc. Persistent variables in programming languages
WO2014150478A1 (en) * 2013-03-15 2014-09-25 Insyde Software Corp. System and method for managing and diagnosing a computing device equipped with unified extensible firmware interface (uefi)-compliant firmware
US20160246510A1 (en) * 2013-10-30 2016-08-25 Intel Corporation Platform non-volatile storage management and platform configuration
US9703346B2 (en) 2014-06-23 2017-07-11 Intel Corporation Firmware interface with backup non-volatile memory storage
US9710185B2 (en) * 2014-07-10 2017-07-18 Samsung Electronics Co., Ltd. Computing system with partial data computing and method of operation thereof
US9658860B2 (en) * 2014-08-05 2017-05-23 Dell Products L.P. System and method for optimizing bootup performance
US9684667B2 (en) * 2014-08-05 2017-06-20 Dell Products L.P. System and method of optimizing the user application experience
US10007606B2 (en) 2016-03-30 2018-06-26 Intel Corporation Implementation of reserved cache slots in computing system having inclusive/non inclusive tracking and two level system memory

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5706460A (en) * 1991-03-19 1998-01-06 The United States Of America As Represented By The Secretary Of The Navy Variable architecture computer with vector parallel processor and using instructions with variable length fields
US5867712A (en) * 1993-04-05 1999-02-02 Shaw; Venson M. Single chip integrated circuit system architecture for document instruction set computing
US5752066A (en) * 1992-01-06 1998-05-12 International Business Machines Corporation Data processing system utilizing progammable microprogram memory controller
GB2276257B (en) 1993-03-19 1997-05-28 Icl Systems Ab A method and arrangement relating to computer systems
DE69435090D1 (en) * 1993-12-01 2008-05-29 Marathon Techn Corp A computer system with control units and computer elements
US5621885A (en) * 1995-06-07 1997-04-15 Tandem Computers, Incorporated System and method for providing a fault tolerant computer program runtime support environment
US5761536A (en) * 1996-08-21 1998-06-02 International Business Machines Corporation System and method for reducing memory fragmentation by assigning remainders to share memory blocks on a best fit basis
JP3773607B2 (en) * 1996-11-28 2006-05-10 Necエレクトロニクス株式会社 Flash eeprom built-in micro computer
CN1186277A (en) 1996-12-25 1998-07-01 苏守成 File encryption method and apparatus
US5999989A (en) * 1997-06-17 1999-12-07 Compaq Computer Corporation Plug-and-play
US5901310A (en) * 1997-09-11 1999-05-04 Ati Technologies, Inc. Storing firmware in compressed form
US6205548B1 (en) * 1998-07-31 2001-03-20 Intel Corporation Methods and apparatus for updating a nonvolatile memory
US6661845B1 (en) * 1999-01-14 2003-12-09 Vianix, Lc Data compression system and method
CA2267484C (en) 1999-03-30 2002-03-05 Object Technology International Inc. Reclaiming memory from deleted applications
US6681310B1 (en) * 1999-11-29 2004-01-20 Microsoft Corporation Storage management system having common volume manager
JP3838840B2 (en) * 2000-01-06 2006-10-25 Necエレクトロニクス株式会社 Computer
US7151800B1 (en) * 2000-01-15 2006-12-19 Sony Corporation Implementation of a DV video decoder with a VLIW processor and a variable length decoding unit
US6622302B1 (en) * 2000-06-30 2003-09-16 Lsi Logic Corporation Methods and apparatus for dynamic version transition of management applications and attached subsystems
US6832373B2 (en) * 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US7093244B2 (en) * 2001-04-18 2006-08-15 Domosys Corporation Method of remotely upgrading firmware in field-deployed devices
US6959337B2 (en) * 2001-04-23 2005-10-25 Hewlett-Packard Development Company, L.P. Networked system for assuring synchronous access to critical facilities
JP2002358207A (en) 2001-05-31 2002-12-13 Yamaha Corp Firmware built-in apparatus and boot program for same
US7299463B2 (en) * 2001-09-28 2007-11-20 Intel Corporation Method for atomically updating a plurality of files
US7193541B2 (en) * 2001-12-04 2007-03-20 Sun Microsystems, Inc. Representation of sign in encoding scheme
US7206953B1 (en) * 2001-12-17 2007-04-17 Adaptec, Inc. Asynchronous fault-tolerant enclosure services interface
US7562208B1 (en) * 2002-02-07 2009-07-14 Network Appliance, Inc. Method and system to quarantine system software and configuration
US7392518B1 (en) * 2002-02-21 2008-06-24 3Com Corporation Robust remote flash ROM upgrade system and method
US7028215B2 (en) * 2002-05-03 2006-04-11 Hewlett-Packard Development Company, L.P. Hot mirroring in a computer system with redundant memory subsystems
JP4329311B2 (en) * 2002-06-28 2009-09-09 富士ゼロックス株式会社 Image forming apparatus and method, and image forming system
US7222258B2 (en) * 2002-12-18 2007-05-22 Intel Corporation Compressing a firmware image
US7747994B1 (en) * 2003-06-04 2010-06-29 Hewlett-Packard Development Company, L.P. Generator based on multiple instruction streams and minimum size instruction set for generating updates to mobile handset
US7222339B2 (en) * 2003-06-13 2007-05-22 Intel Corporation Method for distributed update of firmware across a clustered platform infrastructure
US7886093B1 (en) * 2003-07-31 2011-02-08 Hewlett-Packard Development Company, L.P. Electronic device network supporting compression and decompression in electronic devices
WO2005024628A3 (en) * 2003-09-03 2005-05-26 Bitfone Corp Tri-phase boot process in electronic devices
US20050120081A1 (en) * 2003-09-26 2005-06-02 Ikenn Amy L. Building control system having fault tolerant clients
US20050144612A1 (en) * 2003-12-31 2005-06-30 Shin-Ping Wang Firmware updating method and application utilizing the same
US20050273584A1 (en) * 2004-06-07 2005-12-08 Wisecup George D Locating environment variables in non-volatile memory
US7389490B2 (en) * 2004-07-29 2008-06-17 International Business Machines Corporation Method, system and program product for providing a configuration specification language supporting selective presentation of configuration entities
JP4778247B2 (en) * 2005-03-17 2011-09-21 富士通株式会社 Remote boot method, mechanism and program
US7558804B1 (en) * 2005-08-26 2009-07-07 American Megatrends, Inc. Method, apparatus, and computer-readable medium for space-efficient storage of variables in a non-volatile computer memory
US7805245B2 (en) * 2007-04-18 2010-09-28 Honeywell International Inc. Inertial measurement unit fault detection isolation reconfiguration using parity logic

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050229249A1 (en) * 2004-04-09 2005-10-13 Piwonka Mark A Systems and methods for securing ports
US7552475B2 (en) * 2004-04-09 2009-06-23 Hewlett-Packard Development Company, L.P. Systems and methods for securing ports
US20060206286A1 (en) * 2005-03-11 2006-09-14 Dell Products L.P. Method to reduce IPMB traffic and improve performance for accessing sensor data
US7269534B2 (en) 2005-03-11 2007-09-11 Dell Products L.P. Method to reduce IPMB traffic and improve performance for accessing sensor data
US20070002899A1 (en) * 2005-06-30 2007-01-04 Anant Raman Methodology for network port security
US7733906B2 (en) * 2005-06-30 2010-06-08 Intel Corporation Methodology for network port security
US20070006294A1 (en) * 2005-06-30 2007-01-04 Hunter G K Secure flow control for a data flow in a computer and data flow in a computer network
US7969966B2 (en) 2005-12-19 2011-06-28 Alcatel Lucent System and method for port mapping in a communications network switch
US20090180471A1 (en) * 2005-12-19 2009-07-16 Subash Bohra System and method for port mapping in a communications network switch
US20100088499A1 (en) * 2005-12-20 2010-04-08 Zimmer Vincent J Seamless data migration
US7734934B2 (en) * 2005-12-20 2010-06-08 Intel Corporation Seamless data migration
US20070172063A1 (en) * 2006-01-20 2007-07-26 Microsoft Corporation Out-Of-Band Authentication for Automated Applications ("BOTS")
US9232451B2 (en) * 2006-06-09 2016-01-05 Trapeze Networks, Inc. Untethered access point mesh system and method
US20140364130A1 (en) * 2006-06-09 2014-12-11 Trapeze Networks, Inc. Untethered access point mesh system and method
US9838942B2 (en) 2006-06-09 2017-12-05 Trapeze Networks, Inc. AP-local dynamic switching
US20080098392A1 (en) * 2006-10-19 2008-04-24 Wipfel Robert A Verifiable virtualized storage port assignments for virtual machines
US7793101B2 (en) 2006-10-19 2010-09-07 Novell, Inc. Verifiable virtualized storage port assignments for virtual machines
US20080244688A1 (en) * 2007-03-29 2008-10-02 Mcclain Carolyn B Virtualized federated role provisioning
US8156516B2 (en) 2007-03-29 2012-04-10 Emc Corporation Virtualized federated role provisioning
US7991932B1 (en) 2007-04-13 2011-08-02 Hewlett-Packard Development Company, L.P. Firmware and/or a chipset determination of state of computer system to set chipset mode
US8953795B2 (en) * 2007-11-30 2015-02-10 Sony Corporation Forensic decryption tools
US20090245514A1 (en) * 2007-11-30 2009-10-01 Sony Corporation Forensic decryption tools
US7984285B2 (en) * 2008-02-26 2011-07-19 Dell Products L.P. Information handling system port security
US20090212844A1 (en) * 2008-02-26 2009-08-27 Dell Products L.P. Information Handling System Port Security
US8332669B2 (en) 2008-02-26 2012-12-11 Dell Products L.P. Information handling system port security
US20090260081A1 (en) * 2008-04-14 2009-10-15 Tecsys Development, Inc. System and Method for Monitoring and Securing a Baseboard Management Controller
US8732829B2 (en) * 2008-04-14 2014-05-20 Tdi Technologies, Inc. System and method for monitoring and securing a baseboard management controller
US8001581B2 (en) * 2008-12-17 2011-08-16 Dell Products L.P. Methods and systems for embedded user authentication and/or providing computing services using an information handling system configured as a flexible computing node
US20100153697A1 (en) * 2008-12-17 2010-06-17 Jeremy Ford Methods and systems for embedded user authentication and/or providing computing services using an information handling system configured as a flexible computing node
US20100235648A1 (en) * 2009-03-10 2010-09-16 Quy Hoang Methods and systems for binding a removable trusted platform module to an information handling system
US8245053B2 (en) * 2009-03-10 2012-08-14 Dell Products, Inc. Methods and systems for binding a removable trusted platform module to an information handling system

Also Published As

Publication number Publication date Type
EP1634170A2 (en) 2006-03-15 application
US20070033322A1 (en) 2007-02-08 application
US7934209B2 (en) 2011-04-26 grant
EP1634170B1 (en) 2013-04-10 grant
WO2005002060A3 (en) 2005-12-01 application
WO2005002060A2 (en) 2005-01-06 application
CN1809813A (en) 2006-07-26 application
CN1809813B (en) 2013-10-30 grant

Similar Documents

Publication Publication Date Title
US6185678B1 (en) Secure and reliable bootstrap architecture
Lange et al. L4Android: a generic operating system framework for secure smartphones
US7376968B2 (en) BIOS integrated encryption
US7552419B2 (en) Sharing trusted hardware across multiple operational environments
US7380136B2 (en) Methods and apparatus for secure collection and display of user interface information in a pre-boot environment
US7493487B2 (en) Portable computing environment
US20010044904A1 (en) Secure remote kernel communication
US20140137180A1 (en) Hypervisor-Based Enterprise Endpoint Protection
US8561138B2 (en) System and method to provide added security to a platform using locality-based data
US20060020781A1 (en) Method and apparatus for providing secure virtualization of a trusted platform module
US20070204153A1 (en) Trusted host platform
US20080077993A1 (en) Methods and arrangements to launch trusted, co-existing environments
US9230085B1 (en) Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
US7725703B2 (en) Systems and methods for securely booting a computer with a trusted processing module
US20090064292A1 (en) Trusted platform module (tpm) assisted data center management
US20060256107A1 (en) Methods and apparatus for generating endorsement credentials for software-based security coprocessors
US20060256105A1 (en) Method and apparatus for providing software-based security coprocessors
US20060256106A1 (en) Method and apparatus for migrating software-based security coprocessors
US20050246521A1 (en) Method and system for providing a trusted platform module in a hypervisor environment
US20100161998A1 (en) Associating a Signing key with a Software Component of a Computing Platform
US20060256108A1 (en) Method and apparatus for remotely provisioning software-based security coprocessors
US20120017271A1 (en) Domain-authenticated control of platform resources
US20120084570A1 (en) Remote Resources Single Sign On
US20140298420A1 (en) Validating the Identity of a Mobile Application for Mobile Application Management
US20080046548A1 (en) Network booting using a platform management coprocessor

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTEL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ZIMMER, VINCENT J.;ROTHMAN, MICHEAL A.;MILLER, GREG L.;AND OTHERS;REEL/FRAME:014207/0022;SIGNING DATES FROM 20030613 TO 20030616