U.S. patent number 7,669,235 [Application Number 10/853,931] was granted by the patent office on 2010-02-23 for secure domain join for computing devices.
This patent grant is currently assigned to Microsoft Corporation. Invention is credited to Galen C. Hunt, Jeff Simon.
United States Patent |
7,669,235 |
Hunt , et al. |
February 23, 2010 |
Secure domain join for computing devices
Abstract
A technique is provided for acquiring security domain access
credentials on a computing device. The security domain access
credentials are acquired by storing a persistent identity on the
computing device, and deriving data that includes the security
domain access credentials from the persistent identity. The derived
data is transferred to a security domain to allow the computing
device to join the security domain.
Inventors: |
Hunt; Galen C. (Bellevue,
WA), Simon; Jeff (Redmond, WA) |
Assignee: |
Microsoft Corporation (Redmond,
WA)
|
Family
ID: |
35188437 |
Appl.
No.: |
10/853,931 |
Filed: |
May 25, 2004 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20050246771 A1 |
Nov 3, 2005 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
10837419 |
Apr 30, 2004 |
|
|
|
|
Current U.S.
Class: |
726/18 |
Current CPC
Class: |
H04L
9/3273 (20130101); H04L 61/2015 (20130101); H04L
63/0823 (20130101); H04L 9/3263 (20130101); H04L
2209/56 (20130101); H04L 2209/60 (20130101) |
Current International
Class: |
G06F
21/00 (20060101) |
Field of
Search: |
;713/172,175
;726/6,18,19 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
1368694 |
|
Sep 2002 |
|
CN |
|
1375685 |
|
Oct 2002 |
|
CN |
|
1180886 |
|
Feb 2002 |
|
EP |
|
1307018 |
|
May 2003 |
|
EP |
|
8297567 |
|
Nov 1996 |
|
JP |
|
11007407 |
|
Dec 1999 |
|
JP |
|
11340980 |
|
Dec 1999 |
|
JP |
|
2000293497 |
|
Oct 2000 |
|
JP |
|
2001339437 |
|
Dec 2001 |
|
JP |
|
2001526814 |
|
Dec 2001 |
|
JP |
|
2002084302 |
|
Mar 2002 |
|
JP |
|
2002354006 |
|
Dec 2002 |
|
JP |
|
2003532784 |
|
Nov 2003 |
|
JP |
|
2005155729 |
|
Jun 2005 |
|
JP |
|
10-2002-0026751 |
|
Apr 2002 |
|
KR |
|
10-2004-0008275 |
|
Jan 2004 |
|
KR |
|
WO9853410 |
|
Nov 1998 |
|
WO |
|
WO9930514 |
|
Jun 1999 |
|
WO |
|
WO9963439 |
|
Dec 1999 |
|
WO |
|
WO0022526 |
|
Apr 2000 |
|
WO |
|
WO0031945 |
|
Jun 2000 |
|
WO |
|
WO0073929 |
|
Dec 2000 |
|
WO |
|
WO0230044 |
|
Apr 2002 |
|
WO |
|
WO 0237748 |
|
May 2002 |
|
WO |
|
WO02085051 |
|
Oct 2002 |
|
WO |
|
WO03027876 |
|
Apr 2003 |
|
WO |
|
WO03039104 |
|
May 2003 |
|
WO |
|
Other References
Clifford, Kahn, "Report on DIMAC Workshop on Trust Management"
Online!, Mar. 10, 2003, Retrieved from the Internet: URL:
http://web.archive.ort/web/20030310045643/http://ieee-security.org/Cipher-
/ConfReports/conf-rep-DIMACst.html>, pp. 2-3. cited by other
.
Wen-Chen Wang, "How a SCVP client authenticates the SCVP server",
Online! Sep. 12, 2003, Retrieved from the Internet:
URL:http://www.imc.org/ietf-pkix/old-archive-03/msg01323.html>,
p. 1. cited by other .
Schneier, Bruce, "Applied Cryptography Protocols, Algorithms and
Source Code in C, Second Edition", 1996, John Wiley & Sons,
Inc., New York, p. 461, pp. 466-468, pp. 513-514. cited by other
.
"C.O.B.A.S Centralized Out-Of-Band Authentication System", QT
Worldtel Inc., Sep. 8-9, 2003, pp. 14. cited by other .
"Enhanced IP Services for Cisco Networks", retrieved on Jun. 19,
2007, at
<<http://proquest.safaribooksonline.com/1578701066>>,
Sep. 23, 1999, pp. 11. cited by other .
"Pretty Good Privacy PGP for Personal Privacy, Version 5.0 For
Windows 95 Windows NT", Pretty Good Privacy Inc., 1997, pp. 137.
cited by other .
Moore, D.A., "Network Interoperability Program", MILCOM 97
Proceedings, vol. 3, pp. 1152-1155, 1997. cited by other .
Maughan et al., "Security Associations: Building Blocks for Secure
Communications", IEEE--Symposium on Computers and Communications,
pp. 157-163, 1995. cited by other .
Araki, "Linux Security Diary, Use VLAN in Linux" , Linux Japan,
Itsutsubashi Research Co.,ltd., vol. 3, No. 11,Nov. 1, 2008, pp.
110-113 (CSDB: National Academy Paper 200300158009. cited by other
.
Bagrodia, et al., "A Scalable Distributed Middleware Service
Architecture to Support Mobile Internet Applications," Wireless
Networks V.9 N 4 Jul. 2003 Kluwer Academic Publishers
Manufacturered int he Netherlands; pp. 311-320. cited by other
.
Burns, et al., "Allocation and Data Placement Using Virtual
Contiguity", pp. 1-6. cited by other .
Chao, "Next Generation Routers," Proceedings of the IEEE. vol. 90
No. 9 Sep. 2002. cited by other .
Chen, et al., "Performance Prediction of Component-based
Applications", available at least as early as Jan. 10, 2007, at
<<http://www.ug.it.usyd.edu.au/.about.iango/papers/jss.sub.--paper.-
sub.--draft.sub.--0503.pdf>>, pp. 1-12. cited by other .
Chunxiao, et al., Configure and move the e-Commerce Business Model
by Utilizing XML, Applications of Computer Systems, No. 2, p. 8-11.
cited by other .
Dekhil, et al., "Generalized Policy Model for Application and
Service Management", Hewlett-Packard Laboratories, Software
Technology Lab, 3 pages. cited by other .
Frolund, et al., "Design-Time Simulation of a Large-Scale,
Distrubuted object System" ACM 1998, pp. 374-400. cited by other
.
Garschhammer, et al., "Towards generic Service Management Concepts
A Service Model Based Approach", 14 pages. cited by other .
Harbour, et al., "MAST An Open Environment for Modeling, Analysis,
and Design of Real-Time Systems", available at least as early as
Jan. 10, 2007, at
<<http://citeseer.ist.psu.edu/cache/papers/cs/30959/http:z-
SzzSzwww.ctr.unican.eszSzpublicationszSzmgh-jlm-jjg-jcp-jmd-2002a.pdf/mast-
-an-open-environment.pdf>>, pp. 1-16. cited by other .
Hardwick, et al., "Modeling the Performance of E-Commerce Site",
Jan. 6, 2007, at
<<http://www.cs.cmu.edu/.about.jch/publications/hardwick01-
modeling.html>>, Journal of Computer Resource Management,
2002, pp. 1-11. cited by other .
Howard et al., "Designing Secure Web-Based Applications for
Microsoft Windows 2000", 2000. cited by other .
"Integrated Secruity Management", OpenPMF(Policy Managment
Framework), 2 pages. cited by other .
Kounev, "A Capacity Planning Methodology for Distributed E-Commerce
Applications", Jan. 2, 2001, pp. 1-13. cited by other .
Liu et al., "Visualization in Network Topology Optimization", ACM,
1992, pp. 131-138. cited by other .
Mahon, "OpenView PolicyXpert: Heterogeneous Configuration and
Control", OpenView Policy-Based Network Management, Feb. 1999, 4
pages. cited by other .
Miyamoto, et al., "VLAN Management System on Large-scale Network,"
Journal of Information Processing Society of Japan, vol. 41, No.
12, pp. 3234-3244, the Information Processing Society of Japan,
Dec. 15, 2000. (CSDB: National Academy Paper 200200108005). cited
by other .
Nerurkar, "Security Analysis and Design", Dr. Dobb's Journal, Nov.
2000, pp. 50-56. cited by other .
Nestor, "Security Modeling Using Hierarchical State Machines", IEEE
1991, pp. 110-119. cited by other .
Norton, "Simalytic Hybrid Modeling Planning the Capacity of
Client/Server Applications", available at least as early as Jan.
10, 2007, at
<<http://citeseer.ist.psu.edu/cache/papers/cs/12830/http:zSzzSzwww.-
simalytic.comzSzRESUMEzSz..zSzIMACS97x.pdf/simalytic-hybrid-modeling-plann-
ing.pdf>>, Colorado Technical University, 1997, pp. 1-7.
cited by other .
Shi et al., "An Effective Model for Composition of Secure Systems",
The Journal of Systems and Software, 1998, pp. 233-244. cited by
other .
Somers, "Hybrid: Unifying Centralised and Distributed Network
Management using Intelligent Agents" IEEE Network Operations and
Management Symposium Kyoto Apr. 15-19, 1996. pp. 34-43. cited by
other .
Sultan, et al., "Migratory TCP: Connection Migration for Service
Continuity," in the Internet Proceedings 22nd Intl. Conference on
Distributed Computing Systems; Jul. 2002; pp. 469-740. cited by
other .
Vadim, "On Virtual Data Centers and Their Operating Environments",
at
<<http://www.hpl.hp.com/techreports/2001/HPL-2001-44.html>>,
Mar. 8, 2001, pp. 1-20. cited by other .
Yuhui, e-Commerce Based on ERP for Enterprize by Utilizing DNA and
XML, Computer Engineering, vol. 27, No. 6, p. 165,166,182. cited by
other .
Cardelli, L., "Type Systems," CRC Handbook of Computer Science and
Engineering, 2nd Edition, Ch. 97, Wednesday, Feb. 25, 2004, 8:00pm
CRC Press.,
http://research.microsoft.com/Users/luca/Papers/TypeSystems.pdf.
cited by other .
"Core Principles of the Dynamic Systems Initiative: Leveraging
System Knowledge, Captured in Software Models, to Address
Challenges Across the IT Life Cycle," Windows Server System,
http://www.microsoft.com/windowsserversystem/dsi/dsicore.mspx.
cited by other .
Menezes, et al., "Handbook of Applied Cryptography", CRC Press,
1996, Chapters 8 & 12, pp. 283-319 and 489-541. cited by other
.
Iwasaki, Hideki "IP Troubles Q & A--The Prevention of Network
Troubles and the Risk Management", Computer & Network LAN,
Japan Ohmsha, Ltd., vol. 18, No. 8, (Jul. 14, 2000), pp. 29-39.
cited by other .
Translated copy of the Japanese Office Action mailed on Jan. 26,
2007 for Japanese Patent Application No. 2001-326848, a counterpart
foreign application of US Patent No. 6,886,038. cited by other
.
Translated copy of the Japanese Office Action mailed on Dec. 14,
2007 for Japanese Patent Application No. 2001-326848, a counterpart
foreign application of US Patent No. 6,886,038. cited by other
.
Kitjongthawonkul, S., et al., "Modeling Information Systems Using
Objects, Agents, and Task-Based Problem Solving Adapters," Proc.
10th Australasian Conference on Information Systems, 1999,
http://www.vuw.ac.nz/acis99/Papers/PaperKitjongthawonkul-077.pdf.
cited by other .
Meader, P., "Build Distributed Apps a New Way," VSLive!ShowDaily,
San Francisco, Mar. 25, 2004,
http://www.ftponline.com/reports/vslivesf/2004/whitehorse2/. cited
by other .
Meader, P., "Model Apps More Effectively," VSLive!ShowDaily, San
Francisco, Mar. 24, 2004,
http://www.ftponline.com/reports/vslivesf/2004/whitehorse/. cited
by other .
"System Definition Model," Windows Server System Home,
http://www.microsoft.com/windowsserversystem/dsi/sdm.mspx. cited by
other .
"The Age Changed by Information Network and System: The Internet
Releasing Enterprises and Society A? The New Century created by an
E Service and a Terabit Network Service: Disappearance of
Enterprise Servers, Service Components behind the Internet", Nikkei
Internet Technology, Japan, Nikkei BUsiness Publications, Inc. No.
30, (Dec. 22, 1999), pp. 76-81. cited by other .
Tofts, C., "HOLOS--A Simulation and Multi Mathematical Modelling
Tool," Hewlett-Packard Company, 2001,
http://www.hpl.hp.com/techreports/2001/HPL-2001-276.pdf. cited by
other .
PCT Search Report for PCT Application No. PCT/US2006/038856, mailed
Feb. 20, 2007 (9 pages). cited by other .
Office Action for Russian Application No. 2004117219, mailed on
Oct. 6, 2008 (5 pages). cited by other .
Official Notice of Rejection for Japanese Patent Application No.
2001-326848, mailed on Jan. 26, 2007 (3 pages). cited by
other.
|
Primary Examiner: Barron, Jr.; Gilberto
Assistant Examiner: Lemma; Samson B
Attorney, Agent or Firm: Lee & Hayes, PLLC
Parent Case Text
This is a continuation of application Ser. No. 10/837,419, filed
Apr. 30, 2004, entitled "Isolated Persistent Identity Storage For
Authentication of Computing Devices" to inventors Hunt et al.
Claims
The invention claimed is:
1. A method comprising: acquiring security domain access
credentials on a computing device by: storing a persistent identity
on the computing device, deriving data that includes the security
domain access credentials from the persistent identity, and
transferring the derived data to a security domain to allow the
computing device to join the security domain; wherein the
persistent identity is stored in a secure identity processing area
(SIPA), and wherein the SIPA is located in the computing device;
wherein a trust relationship that allows a secure domain join of
the computing device to the security domain is established between
a persistent account stored in a security domain and the persistent
identity in the SIPA; wherein the SIPA and a secure data center
allow the computing device to obtain a cryptographically
authenticated operating system at least partially in response to
the security domain access credentials.
2. The method of claim 1, wherein an operating system of the
computing device receives the derived data by communicating with a
processor that is located within the SIPA.
3. The method of claim 1, wherein an operating system of the
computing system establishes an identity of the computing device to
the security domain at least partially in response to the security
domain access credentials.
4. The method of claim 1, further comprising at least one operating
system executing on the computing device, wherein an identity of
the operating system is generated based on the persistent
identity.
5. The method of claim 1, wherein the data derived from the
persistent identity includes a cryptographic function, and wherein
the persistent identity challenges security domain data received
from the security domain.
6. The method of claim 5, wherein the data derived from the
persistent identity includes data encrypted with a public key that
is associated with the persistent identity and the cryptographic
functions include decrypting a portion of the challenge data with a
private key of the persistent identity.
7. The method of claim 1, further comprising at least one operating
system executing on the computing device, wherein the operating
system contains an identity associated with the operating system,
and wherein the identity is established in a computer account that
is contained in the security domain.
8. An apparatus comprising: a computing device configured to
acquire security domain access credentials, wherein the computing
device stores a persistent identity, further wherein the computing
device derives data that includes the security domain access
credentials from the persistent identity, further wherein the
computing device transfers the derived data to a security domain
that allows the computing device to join the security domain;
wherein a secure identity processing area (SIPA) stores the
persistent identity, wherein the SIPA is located in the computing
device; wherein the SIPA and the secure data center allow the
computing device to obtain a cryptographically authenticated
operating system at least partially in response to the security
domain access credentials.
9. The apparatus of claim 8, wherein a trust relationship that
allows a secure domain join of the computing device to the security
domain is established between a persistent account stored in a
security domain and the persistent identity in the SIPA.
10. The apparatus of claim 8, wherein an operating system of the
computing device receives the derived data by communicating with a
processor that is located within the SIPA.
11. The apparatus of claim 8, wherein an operating system of the
computing system establishes an identity of the computing device to
the security domain at least partially in response to the security
domain access credentials.
12. The apparatus of claim 8, further comprising at least one
operating system executing on the computing device, wherein an
identity of the operating system is generated based on the
persistent identity of the SIPA.
13. The apparatus of claim 8, wherein the data derived from the
persistent identity includes a cryptographic function, and wherein
the persistent identity challenges security domain data received
from the security domain.
14. The apparatus of claim 13, wherein the data derived from the
persistent identity includes data encrypted with a public key that
is associated with the persistent identity and the cryptographic
functions include decrypting a portion of the challenge data with a
private key of the persistent identity.
15. The apparatus of claim 8, further comprising at least one
operating system executing on the computing device, wherein the
operating system contains an identity associated with the operating
system, and wherein the identity is established in a computer
account that is contained in the security domain.
Description
BACKGROUND
Authenticating a new computing device with respect to an existing
network is challenging, labor intensive, and is often performed
manually by sending a trusted employee to the location of the
computing device. Typically, such authenticating is performed using
a shared secret that is made available to the trusted employee. The
trusted employee is then able to enter the shared secret when the
new computing device is coupled to the network, and also possibly
when re-configuring the computing device (e.g., when installing a
new operating system). For security purposes, the reliability of
the shared secret is only as good as the trust and reliability of
the trusted employee because the trusted employee can disclose the
shared secret to others either intentionally or accidentally.
Furthermore, sending a trusted employee to enter the shared secret
to each computing device when it is added to the network or
re-configured represents a time-consuming and expensive operation.
As electronic commerce and other operations that demand greater
security become more commonplace, increasing the reliability and
simplicity of authentication of newly added and/or re-configured
computing devices is desirable.
SUMMARY
This disclosure describes a technique for acquiring security domain
access credentials on a computing device. The security domain
access credentials are acquired by storing a persistent identity on
the computing device, and deriving data that includes the security
domain access credentials from the persistent identity. The derived
data is transferred to a security domain to allow the computing
device to join the security domain.
BRIEF DESCRIPTION OF THE DRAWINGS
The same numbers are used throughout the document to reference like
components and/or features.
FIG. 1 is an illustrative architecture of a secure data center
including a security domain and a number of computing devices, each
computing device including a secure identity processing area
(SIPA).
FIG. 2 is a more detailed example of a secure data center with a
security domain and a computing device, the computing device
including the SIPA.
FIG. 3 is a block diagram of one embodiment of a switch assembly
that is included in the security domain of FIGS. 1 and 2.
FIG. 4 is a block diagram of another embodiment of a switch
assembly that is included in the security domain of FIGS. 1 and
2.
FIG. 5 is a flow diagram of one embodiment of a generalized
authentication request.
FIG. 6a is a flow diagram of one embodiment of a resource request
as performed in a computing device in attempting to access a
resource in a security domain.
FIG. 6b is a flow diagram of one embodiment of a resource grant as
is performed in a security domain in response to the resource
request of FIG. 6a.
FIG. 7 is a flow diagram of one embodiment of authentication
challenge technique.
FIGS. 8a and 8b are a flow diagram of one embodiment of a computing
device authentication technique that is performed in a staging
area.
FIGS. 9a, 9b, and 9c are a flow diagram of one embodiment of a
computing device authentication technique that is performed in a
production network.
FIGS. 10a and 10b are a flow diagram of another embodiment of a
computing device authentication technique that is performed in a
production network.
FIG. 11 is a diagram of one embodiment of the authentication levels
relative to a security domain that may be attained by a computing
device containing the SIPA.
FIG. 12 is a block diagram of one embodiment of computing device
blob.
FIG. 13 is a block diagram of one embodiment of a persistent
isolated storage portion of a SIPA.
DETAILED DESCRIPTION
This disclosure describes a number of authentication techniques and
devices that authenticate at least one computing device with
respect to a security domain. The computing device is located
outside of the security domain prior to the authentication. As a
result of the authentication, the computing device joins the
security domain. A secure identity processing area (SIPA) is
included in each computing device, and each SIPA provides the
authentication using a persistent identity. The SIPA does not
require key information input from trusted individuals who are in
conventional systems provided with information relating to
cryptographic keys or certificates.
In one embodiment, a computing device having an un-configured SIPA
is placed in a staging area where the un-configured SIPA is
configured such that it can be disconnected from the staging area
and then integrated within a production area where it can be
authenticated with the security domain. In one embodiment, the SIPA
largely automates the authentication process of computing devices
joining the security domain.
Different aspects of the SIPA provide for a number of functions
including but not limited to: persisting an identity, providing a
secure bootstrap program to provide or update an operating system,
and/or securely joining a security domain in a manner that requires
no human intervention such as providing a shared secret or by the
person entering a pin code that is used by the SIPA to generate a
key pair. The operating system can have a number of configurations
and require certain levels of authentication. Portions of the
operating system, and associated application programs, may be
resident at different times in the CPU 132, the memory 134, and/or
other network or other locations. As such, the specific location or
operation of the operating system is not further described, and is
not shown in the figures. A number of types of operating system are
produced and made commercially available by Microsoft. The SIPA
further allows the computing device to be purposed or repurposed in
a manner that mitigates spoofing threats such as exist with the
conventional remote boot protocols.
Example SIPA Authentication with Respect to Security Domain
FIGS. 1 and 2 each show a data center 102 having a security domain
104 and at least one computing device 105. Although FIG. 2 shows a
single computing device 105 in order to avoid cluttering the
drawings, a number of computing devices may be in communication
with the security domain 104. The security domain 104 distinctly
interfaces with each computing device 105 via ports located in one
or more switches 109. While the computing devices in a production
area 103 are shown as being distinct from the security domain 104
in FIG. 1, the act of a computing device joining the security
domain results in a computing device such as a boot server 304
becoming a portion of the security domain as shown in FIG. 4. The
switches 109 can be coupled to the computing devices 105 with wired
and/or wireless couplings. Each computing device 105 includes a
SIPA 106 that provides a number of authentication functions to
allow the identity of the computing device 105 to be proven to the
security domain 104.
Each computing device 105 can be any of a variety of types of
computers including, but not limited to, desktop PCs, workstations,
mainframe computers, server computers, client computers, Internet
appliances, gaming consoles, handheld computers, cellular
telephones, personal digital assistants (PDAs), etc. The multiple
computing devices may have different purposes, hardware
configurations, application programs, operating systems, software
configurations, processors, manufacturers, etc.
The secure data center 102 includes a number of computing devices
105 that are within the production area 103. In one embodiment,
each computing device joins the security domain 104 upon
authentication. The computing devices 105 can be included in such
embodiments of the secure data centers 102 as, for example, a data
center such as an Internet data center (IDC), a server farm, a
client computer, an office or business environment, a home
environment, an educational or research facility, a retail or sales
environment, etc.
Conventional server farms include a large number of computing
devices 105 that are arranged as servers. Racks 116 within a
protected building often support a number of computing devices in
server farms. Individual computing devices 105 within the server
farms are often referred to as "blades", due largely to their
ability to slide into and out of the racks during positioning.
The components of the secure data center 102 provide authenticated
interfacing between the computing devices 105 and the security
domain 104. Certain hardware and software embodiments of the secure
data center 102 provide for mutual authentication or one-way
authentication between the SIPA 106 within the computing device 105
and the security domain 104 using an automated deployment service
119. Cryptographic functions as described in this disclosure can be
provided using hardware, firmware, and/or software that are
included in the SIPA 106.
The secure data center 102 of FIGS. 1 and 2 acts as an isolated
secure boot system. During a secure boot of the computing device
105, the security domain 104 becomes associated with the SIPA 106
of the computing device 105. The association between the security
domain 104 and the SIPA 106 provides cryptographic verification of
the SIPA 106 to authenticate the computing device 105. The
authentication occurs largely automatically within the secure data
center, and in certain embodiments there is no human intervention
and no human knowledge of private key information that is included
in the SIPA 106.
The secure data center 102 can authenticate a computing device that
is installing an operating system. The secure data center 102
allows a number of computing devices 105 to securely download at
least a portion of their operating system from an automated
deployment service 119 as shown in FIG. 2 that is located within
the security domain 104, as discussed in more detail below.
One embodiment of the secure data center 102 as shown in FIG. 1 is
segmented into the security domain 104 and the production area 103.
The security domain 104 represents those portions of the secure
data center 102 in which all of the devices are secured and/or
trusted. Any particular security mechanism that provides trust
and/or security, such as by using cryptographic authentication, can
be used to establish the security domain 104. The production area
103 represents those portions of the secure data center 102 where
at least some of the components or devices may not be
cryptographically authenticated.
The security domain (e.g., as maintained by the security domain
controller 115) contains a computing device related identity datum
that is stored in a persistent account 113. The security domain
controller 115 establishes the computing device's identity in the
security domain 104. The persistent account 113 of the security
domain and the persistent identity 154 of the SIPA 106 are relied
upon as described below when the computing device 105 including the
SIPA 106 joins the security domain.
The computing device 105 bootstraps at least a portion of the
operating system using the SIPA 106 to provide authentication to
the computing device 105. Each computing device 105 that is
undergoing such network bootstrap protocols as preboot may be
authenticated based on the operation using the SIPA 106. At the
onset of the SIPA's operation, the state of one embodiment of the
computing device 105 may be limited to hardware initialization
instructions such as provided by the Basic Input/Output System
(BIOS), a network bootstrap program such as the Preboot Execution
Environment (PXE), and authentication instructions provided by the
SIPA 106 identity each as described in this disclosure. The SIPA
106 and the secure data center 102 provide a mechanism for the
computing device 105 to obtain a cryptographically authenticated
operating system.
An alternative preboot embodiment that enhances a network bootstrap
protocol contains an Extensible Authentication Protocol (EAP) in
which the computing device 105 can perform an authentication
transaction (based for example on IEEE 802.1x communications)
without an operating system, or by using a partial or minimal
operating system.
The computing device 105 can download a minimal operating system
from the automated deployment service 119. The automated deployment
service 119 is in the security domain 104. A minimal operating
system that is used to bootstrap a normal operating system is also
referred to within this disclosure as a "minimal bootstrap". The
minimal operating system yields a minimal degree of authentication
for the SIPA. Immediately following the download, the computing
device 105 and the minimal operating system are both
unauthenticated with respect to the security domain. The minimal
bootstrap uses credentials in the SIPA in response to
authentication requests from the switch 109 that provides port
authentication to establish either a mutual authenticated identity
or a one-way authenticated identity.
The SIPA 106 uses established cryptographic operations to provide
authentication between its associated computing device 105 and the
security domain 104. Cryptographic operations that are performed
within the SIPA 106 include, but are not limited to: key
generation, encryption, and decryption. In one embodiment, the SIPA
106 replaces the identity of the operating system within the
computing device 105 to establish the identity of the computing
device with respect to the security domain 104. The identity of the
computing device 105 is characterized by the hardware and the
operating system of the computing device. This capability of
storing the identity of the computing device 105 in the SIPA 106
allows the computing device to be repurposed, which may include
modifying the operating system on the computing device 105 or
loading a different operating system on the computing device 105,
without changing its identity.
In one embodiment, the SIPA may be emulated or simulated by a
software-based operating system, a kernel, or a program. Within
this disclosure, the term "software" is intended to apply to
firmware as well. The software-based operating system, kernel, or
program derives its identity at least in part from the persistent
identity 154. In one embodiment, the security domain (including a
directory of resources in the security domain) uses cryptographic
techniques and cryptographic keys as provided by the SIPA to
separate the resources within the directory of resources.
The SIPA 106 provides mutual or one-way authentication between the
computing device 105 and the security domain 104 that establishes
the identity of the computing device independent of the state of
the operating system or the computing device. The SIPA 106 enables
a secure network bootstrap, enables a secure operating system
installation, and mitigates the vulnerabilities of such
non-authenticated protocols as the Preboot Execution Environment
(PXE).
Purposing of the computing device refers to the initial set-up or
configuration of the computing device. Purposing of the computing
device includes, for example, adding the operating system and/or
application programs to the computing device and initially
configuring the operating system and/or application programs.
Repurposing of the computing device refers to changing the set-up
or configuration of the computing device. Repurposing of the
computing device includes, for example, removing, replacing, adding
to, or changing the operating system and/or application programs
within the computing device. A computing device can be repurposed
at any point after being purposed (e.g., a computing device may be
repurposed one hour, one week, three years, etc. after being
purposed). During the purposing or repurposing of the computing
device, the operating system establishes an identity (or machine
account) of the computing device (based on the SIPA of the
computing device) to the security domain.
Certain embodiments of the SIPA within the computing device
establish mutual authentication such that each computing device is
able to provide a persistent identity to the security domain, and
vice versa. Other embodiments of the SIPA within the computing
devices performs one-way authentication. With one-way
authentication, each computing device provides a persistent
identity to the security domain. Whether the computing device
performs mutual or one-way authentication is a function of the SIPA
and its relation to the security domain. One-way authentication
need not import a domain public trusted certificate to the SIPA
within the computing device during the staging operations as
described within this disclosure, as is typically done for mutual
authentication.
Certain embodiments of the various components of the secure data
center 102 are described in greater detail with respect to FIG. 2.
The secure data center 102 includes the components of both the
security domain 104 and the computing device 105 with the SIPA 106.
In one embodiment, the security domain 104 includes a security
domain controller 115, a switch 109, an authentication server 108,
a boot server 116, an optional certificate authority 110, an
automated deployment service 119, and a firewall 112. The firewall
112 as shown in FIG. 2 allows the services in the secure data
center to be made available to computing devices, and acts to limit
access to data contained within the security domain 104 to
unintended remote third parties and rogue servers 199.
The components as described with respect to FIG. 2 that create and
service a security domain 104 include the security domain
controller 115 and the certificate authority 110. The certificate
authority 110 represents a third party that can provide
authentication between the computing device 105 and the security
domain 104. The certificate authority 110 may be at least partially
contained within the security domain 104, or alternatively may be
remote from secure data center 102. The certificate authority 110
issues certificates based on asymmetric cryptography, e.g., as part
of a public key infrastructure (PKI). In one aspect, the security
domain controller 115 uses a persistent account 113 to provide a
secure and trusted location to derive and store user and computing
device identities that are used for authentication. The
authentication server 108 authenticates the computing devices 105
using the security domain controller 115.
In one illustrative embodiment as described relative to FIG. 2,
each computing device 105 within the secure data center 102
includes a central processing unit (CPU) 132, a memory 134, an
input/output (I/O) portion 136, files and/or firmware 138, and a
SIPA 106. In one embodiment, the components 132, 134, 136, 138, and
106 are each attached to a motherboard contained within the
computing device. Files and/or firmware 138 can be configured to
allow the computing device 105 to solicit the network for a network
identity, and to form message transactions on a network.
Each computing device 105 can optionally download at least a
portion of its operating system using the automated deployment
service 119 and the security domain controller 115. The automated
deployment service 119, as shown in FIG. 2, manages the
configuration and installation of operating system software on the
computing devices 105. All of the computing devices 105 in the
secure data center 102 may utilize the same automated deployment
service 119. Alternatively, multiple automated deployment services
119 may distinctly manage different computing devices 105.
Different automated deployment services 119 may manage a particular
computing device at different levels of authentication.
In certain embodiments of the present disclosure, a computing
device 105 may be authenticated with the automated deployment
service 119 after being added to secure data center 102. During
operation, when a computing device 105 is added to the secure data
center 102, the newly added computing device 105 is automatically
configured to authenticate the computing device.
Within this disclosure, a bootstrap program is considered a program
that downloads all or a portion of the operating system. The
bootstrap program typically contains less code than the operating
system due to their relative operations and complexities. Certain
embodiments of authentication can be provided during booting,
rebooting, recovery, and other purposing processes that occur
during normal computing device operation in prior systems, but
without the authentication as provided in this disclosure.
Within this disclosure, a machine account may provide one
embodiment of a secure identity within the directory in the
security domain 104. The credentials within the SIPA (e.g., the
SIPA public key or the computing device public certificate 159 as
shown in FIG. 13) are used to establish a machine account in the
security domain based on a shared secret. The SIPA public key, or
the computing device public certificate 159 that encapsulates the
SIPA public key as shown in FIG. 13, is "mapped" to an database
account (not shown) in the security domain controller 115 as shown
in FIG. 2.
The computer account may be associated with instructions (e.g.,
policies) to install a particular type or version of operating
system or application program. According to one aspect of this
disclosure, an installation policy is stored in the automated
deployment service 119 of the security domain controller 115 that
conveys "managing" the computing device 105. The automated
deployment service 119 includes a database containing data relating
to the computing devices 105, the users, and policies. The security
domain controller 115 carries out the operations of authentication
of the automated deployment service 119, and as such the security
domain controller 115 can be considered as providing some of the
operations of the automated deployment services 119. In one
embodiment, the security domain 104 contains an identity datum in
the persistent account 113 for each participating computing device
105 that establishes the identity of that computing device.
FIG. 2 also illustrates two Virtual Local Area Networks (VLANs): a
production VLAN V.sub.1 and a private VLAN V.sub.2. Many types of
networks can be segregated into multiple VLANs for network
isolation. In this disclosure, messages between computing devices
are assumed to remain isolated on those VLANs that they are a
respective member, but not on additional network devices such as
switches, routers, or other network devices that are used to
transmit messages between multiple VLANs. As such, devices in a
VLAN can communicate freely with other nodes in the same VLAN, but
cannot talk directly to nodes outside the VLAN. Placing two or more
computers in a VLAN is the equivalent of connecting those computers
to the same physical network. VLANs can be implemented as
port-based VLANs or protocol-based VLANs. Port-based VLANs occur
within a single switch while protocol-based VLANs can span multiple
switches. An example of protocol-based VLANs is standardized
according to IEEE 802.1Q. The IEEE 802.1Q standard describes how
packets are marked and how VLANs are supported.
The private VLAN V.sub.2 is a limited virtual network that the
switch 109 permits messages to be sent across. In one embodiment,
the computing devices 105 that are not authenticated are attached
to ports that are members of the private VLAN V.sub.2. After
authentication, the switches 109 may be configured to move the port
and the computing device to a different VLAN, such as production
VLAN V.sub.1. In a preferred embodiment, anytime a link is
disconnected (e.g., a computing device is powered down or
disconnected from the switch 109), the port switches back to the
private VLAN V.sub.2.
Example Isolated Storage of Persistent Trusted Cryptographic
Information within SIPA
One embodiment of the SIPA 106 as described relative to FIG. 2
includes a private cryptographic processor 150 and an isolated
storage portion 152. One embodiment of the isolated storage portion
is described with respect to FIG. 13 below. The SIPA can be
configured to provide a variety of functional interfaces that
maintain at least a portion of a persistent identity 154 isolated
from other portions of the computing device and the secure data
center 102. The isolated storage portion 152 contains a persistent
identity 154 that persistently and privately contains one or more
keys 158.
Persistent identity 154 can take different forms in different
embodiments. In certain embodiments, persistent identity 154 is a
private key of a public/private key pair (in such embodiments,
key(s) 158 includes private key 157 of FIG. 13). In such
embodiments, isolated storage portion 152 also typically includes a
computing device public certificate 159 that includes the public
key of the public/private key pair, as illustrated in FIG. 13.
Alternatively, persistent identity 154 may be the public/private
key pair. In other embodiments, the persistent identity 154
includes some identifier other than part or all of a public/private
key pair, such as a symmetric key.
Isolated storage portion 152 also optionally contains a trusted
domain public certificate 156 containing a public key of the
security domain 104 (e.g., a public key of authentication server
108). The trusted domain public certificate 156 allows security
domain 104 to be authenticated to computing device 105 as discussed
in more detail below.
The computing device public certificate 159 containing the public
key of SIPA 106 is mapped to a computer account. In one embodiment,
this mapping occurs in the staging area prior to the computing
device 105 being placed into the production area 103 as shown in
FIG. 1.
At least some of the content of the isolated storage portion 152 is
not exposed beyond the SIPA 106. Particularly, at least the private
key 157 of the public/private key pair is not exposed beyond the
SIPA 106. The SIPA 106 is a physically and operationally distinct
cryptographic processing area from the CPU 132 and the memory 134
of the computing device. The private key 157 may be accessed and
used by the cryptographic processor 150, but not by any component
external to the SIPA 106 (e.g., the CPU 132 or the memory 134).
The cryptographic processor 150 (and not the CPU 132) is configured
to operate on the private key 157 or any sensitive cryptographic
information that is contained within the isolated storage portion
152. The term "isolated" in the phrase "isolated storage portion"
152 indicates that any data within this storage portion that is
associated with the SIPA private key 157 is structurally isolated
from, and acts independently from, the memory 134 in the computing
device 105. In certain embodiments, the entirety of isolated
storage portion 152 is structurally isolated from, and acts
independently from, the memory 134. Such structural isolation is
accomplished, for example, by having only cryptographic processor
150 being able to access the isolated memory. Any requests that
require access to information within the isolated memory (such as
encrypting data using private key 157) are directed to
cryptographic processor 150. Cryptographic processor 150 can access
the isolated portions of memory and perform the requested
operations, but will not reveal the contents of the isolated
portions of memory to any requester.
By designing the isolated storage portion 152 to maintain the SIPA
private key 157 physically separated from the memory 134 accessible
by the cryptographic processor 150, and physically protected, the
sensitive cryptographic information such as the private key 157
that is contained within the isolated storage portion 152, is
isolated from any other party or computer outside of the SIPA.
Undesired third parties (including but not limited to malicious
software, malicious operating systems, and malicious computing
devices) therefore have great difficulty in obtaining access to the
original information or data that was encrypted.
The SIPA 106 will support a SIPA driver for interfacing the SIPA to
the operating system of the computing device 105 and contain the
cryptography processor 150 that is capable of Rivest, Shamir,
Adleman (RSA) or other algorithms for supporting asymmetric
challenge-response, encryption, and decryption operations. In one
embodiment, the cryptographic processor 150 will support asymmetric
key pair generation. In other embodiments, the cryptographic
processing engine of the SIPA 106 is implemented with other
algorithms including symmetric algorithms. Many versions of both
asymmetric encryption and symmetric encryption are generally known
in cryptographic applications and will not be further described in
this disclosure.
The SIPA 106 may be implemented on the motherboard of the computing
device 105 in the form of, for example, a dedicated chip or a
baseboard management controller. In certain embodiments, the SIPA
106 sends data directly to and receives data directly from the CPU
132. For example, the CPU 132 may send a request to the SIPA 106
that particular data be encrypted using the private key 157, and
the SIPA 106 may return the encrypted data to the CPU 132. In other
embodiments, both the CPU 132 and the SIPA 106 may access a region
of the memory 134 to transmit results and/or requests.
The security behind asymmetric cryptographic operations within the
SIPA 106 relies on maintaining the private key 157 secret from
others. A third party obtaining the private key 157 from the SIPA
106 would compromise the authentication process. With the SIPA 106
configured as shown in FIG. 2, only the cryptographic processor 150
and not the CPU 132 performs processing on data that is associated
with the SIPA private key 157, which is contained within the
isolated storage portion 152 for the computing device 105. The
private key 157 is never exposed outside the cryptographic
processor 150. As such, no processor outside of the cryptographic
processor 150 can directly see, detect, analyze, discover, or use
the private key 157 based on the trusted domain public certificate
156 that is located within the isolated storage portion 152.
The isolated storage portion 152 is configured to be
tamper-resistant. The isolated storage portion 152 protects the
private key against attacks including physical removal and
replacement. In one embodiment, the isolated storage portion 152 is
remote from a "core area" on the motherboard that includes the I/O
136, the memory 134, and the CPU 132.
The SIPA 106 therefore allows for mutual authentication or one-way
authentication for computing devices 105 using a secured identity
that is authenticated through cryptographic algorithms. This mutual
authentication uses authentication techniques such as
public/private key pairs by which two communicating parties can
each: a) prove who they are to the other party, b) confirm that the
other party is whom they are claiming to be.
In certain embodiments, the SIPA 106 may be located adjacent to
such interfaces such as the input/output portion 136, which often
communicates using a high-speed bus. Programmatic isolation is
provided between the tamper-resistant isolated storage portion 152
of the SIPA 106 and the interfaces. A low-bandwidth on-chip
communication path can be provided to form a management channel
between a core of the motherboard and the SIPA 106.
Since the SIPA 106 authenticates the computing device 105, it is
important to ensure that the SIPA is not physically moved to
another computing device to provide incorrect authentication to the
wrong computing device. In certain embodiments to further
positively associate the SIPA with its computing device, the SIPA
106 is physically secured to the motherboard in some manner that
can be considered as permanent, e.g., by soldering. This physical
connection between the SIPA 106 and the computing device 105
establishes a substantially permanent identity of the SIPA 106
relative to each computing device 105. The SIPA thereby becomes
physically integrated within the motherboard in many embodiments of
the computing device 105. By integrating the SIPA 106 into the
computing device 105, removing the SIPA 106 from the motherboard
becomes so prohibitively difficult that it effectively destroys the
functioning of the SIPA and the identity of the computing device.
While this disclosure describes one embodiment in which the SIPA
106 is attached to the motherboard, it is envisioned that the SIPA
may alternatively be attached to some other component or piece of
the computing device 105, such as a component or piece that is
difficult to disassociate with the computing device.
It may also be desired in certain embodiments that supplemental
components are associated with the SIPA 106, in which the
supplemental components are attached to and integrated within the
motherboard of the computing device. The private key of the
computing device is not imported or exported beyond the
cryptographic processor 150 as shown in FIG. 13. One implementation
of the SIPA 106 permits the computing device key pair to be
regenerated. In certain optional embodiments, the computing device
key pair is "electronically programmed" in a one-time writable
memory. In an optional embodiment, the SIPA supports an interface
to export the computing device public key. The computing device key
pair is generated in isolation within the SIPA 106 and may be
re-initialized through, for example, a limited access hardware
jumper. The SIPA 106 further includes a results area, not shown,
that provides cryptographic analysis from, or allows messages that
are conveyed to the SIPA to be displayed.
In one embodiment, a hardware reset is available to the SIPA on the
motherboard. When the SIPA 106 "calls" or "executes" the hardware
reset function, the motherboard that contains the SIPA is forced to
reboot in an equivalent to power-off and power-on re-cycling.
Additionally, in one embodiment, the minimal bit length of the keys
158 is 1024 bits. Different bit lengths can be selected to provide
the desired cryptographic security. Longer bit lengths are
typically deemed as providing greater security, but also typically
require more computational power to use. The selected bit lengths
may relate to the application and current state of the art in
attempts to break the cryptographic SIPA private key 157.
Furthermore, in one embodiment, the computing device's
authenticated identity from the SIPA is used as the normal
operating system identity. The identity of the SIPA 106 persists
through the life-cycles of the computing device 105 that is
repetitively configured or repurposed using a new operating system,
new application software, and/or related new software data.
Example Computing Device Purposing
It is often desired to "purpose" or "repurpose" a particular
computing device 105 to perform a particular function. Such
purposing of the computing device often dictates an appropriate
operating system for the computing device (or particular settings
for the operating system). For instance, one computing device may
be purposed either as an authentication server, a boot server, a
web server, or another type of server. The purpose of a particular
computing device 105 such as a server is largely a function of its
resident software such as particular application programs and
operating systems.
A number of servers as shown in FIG. 2 that are in communication
with the switch 109 can be purposed to provide different functions.
For example, the authentication server 108 can be purposed to
provide authentication and secure boot protocol knowledge, and
switch management interface. Additionally, the boot server 116 can
be purposed to provide such network booting services as Dynamic
Host Configuration Protocol (DHCP), Preboot Execution (PXE), and
Trivial File Transfer Protocol (TFTP).
Repetitive bootstrapping of an operating system is desired in
certain embodiments, and in certain instances is required. In
routine situations, an operating system is re-started or rebooted
from warm reset of the operating system or cold restart of the
underlying hardware. In these situations, the operating system
reestablishes its identity with the secure domain. The SIPA and
methods described herein enable the operating system to transition
from/to on-line to/from off-line or to be replaced completely, but
in all cases the computing device retains its identity in the SIPA.
As such, the SIPA allows the computing device to be purposed and
repurposed.
Additionally, one or more computing devices 105 may be
re-configured (also referred to as repurposing) after being added
to security domain 104 within the secure data center 102. For
example, a particular computing device 105 may operate for a period
of time, e.g., on the order of minutes, hours, days, months, etc.,
performing one function, and then the security domain controller
may decide that a different function is desirable. Such a change of
function during reconfiguration may include, e.g., a change from
being a server computer to a workstation computer, from a web
server to a local file server, etc.
One embodiment of the SIPA 106 enabling secure network bootstrap
that provides a secure operating system installation through
repetitive cycles as a computing device 105 is repurposing.
Repurposing the computing device includes processes as restarting
the hardware, booting the operating system, installing application
programs, and tearing-down of the computing device.
When the computing device 105 bootstraps the operating system using
the bootstrap program, it downloads an operating system image that
is used to provide the operating system. The identity of each
computing device 105 is provided to the secure data center 102. The
secure data center 102 then admits the computing device 105, if
authenticated, by using the identity of the computing device to
allow the computing device and its operating system to join the
security domain 104 using a domain join.
A persistent operating system remains resident with the computing
device 105 such as a server even after it has been shut down. If
the operating system is not a persistent operating system, then a
new copy of the operating system has to be accessed each time the
computer is powered up. The operating system can be downloaded from
a local or remote storage. A considerable portion of the operating
system is downloaded or accessed each time the computing device is
initiated, rebooted, etc. Providing authentication techniques in
such systems that downloads a considerable portion of their
operating systems is challenging since the portion of the operating
system that is downloaded is often the portion that provides
authentication.
In one embodiment, computing devices may have firmware encoded to
be compatible with the Preboot Execution Environment (PXE). The
Preboot Execution Environment (PXE) Specification, version 2.1
(incorporated herein by reference) is an Intel standard that
provides for bootstrapping a client platform typically packaged in
firmware, hardware, or the Basic Input/Output System (BIOS). In one
embodiment, PXE is typically packaged in firmware such as a flash
chip. It can be extracted to another media such as a floppy disk;
many aspects of the present disclosure are directed to automation
that favors firmware. PXE is a protocol that is packaged as
extensions to the Dynamic Host Configuration Protocol (DHCP),
described in both RFCs 2131 and 3118. The DHCP protocol is based on
the Bootstrap Protocol (BOOTP). The Intel Binary Integrity Service
(incorporated herein by reference) represents a standard for adding
a cryptographic checksum of the first binary program downloaded in
the PXE protocol. Other boot protocols can be used instead of the
PXE. In one embodiment, the SIPA requires a network bootstrap, but
is not dependent on the PXE.
The secure data center 102 supports a number of protocols that are
associated with booting such as the Dynamic Host Configuration
Protocol (DHCP) and the Preboot Execution Environment (PXE)
protocol that, each operating by itself is subject to network
intrusion. The secure data center 102 and the SIPA 106 provide a
mechanism to provide an authentication mechanism, and thereby
reduce potential network intrusion. In one embodiment of the SIPA
106, the security domain 104 is accessible via the secure data
center 102 over a local area network. Certain other bootstrap
protocols may support TCP or other reliable transport protocols for
use with a wide area network.
Example Staging Area
In one embodiment as described with respect to FIG. 1, the secure
data center 102 is associated with the staging area 120 (also
referred to as a staging area). With the staging area 120, a trust
relation is established between the computing device and the
secured domain that is based on the identity of some trusted
individual that brings the computing device having a new and
un-configured SIPA into the staging area. The new and un-configured
SIPA, such as exists when the SIPA is initially inserted into its
computing device 105 and located within the staging area 120, does
not contain any key information and can be considered as a hollow
container to receive key information. Only those computing devices
that have an un-configured SIPA which are desired to be configured
to be trusted are brought into the staging area 120. The trusted
person brings in the new and un-configured computing device to the
staging area, and connects the staging area 120 to a port on the
computing device.
This disclosure provides a staging area mechanism by which 1)
authentication of the production network occurs by copying key
information from the staging area to the production network, and 2)
the staging area signs a certificate, and then gives the
certificate back to the computing device (the computing device uses
the certificate to authenticate itself relative to the production
network). One difference between case 1) and case 2) is that with
case 2), there does not need to be a network connection between the
staging area and the production network.
A computing device with a previously configured SIPA can be
recycled in the staging area by erasing its previous contents and
treating it as an un-configured SIPA.
There are different cases as described involving the staging area.
One case involves the authentication server exchanging public keys
with the computing device that is connected to the staging area.
Another case involves the computing device presenting its public
key to the authentication server, and wrapping the public key in a
certificate such as the computing device public certificate 159 as
shown in FIG. 13 that in one embodiment is signed by the
certificate authority 110 of FIG. 1. The certificate is handed back
to the computing device that includes the SIPA. In both of these
cases, a trust relation is established that can be verified at some
future time based on the public key as contained in the computing
device public certificate 159 shown in FIG. 13 from the computing
device.
The staging area 120 provides keys for the computing device 105
with respect to the security domain prior to the removal of the
computing device from the staging area 120, and the subsequent
insertion of the computing device into the production area 103 as
shown in FIG. 3.
The embodiment of staging area provides a protected environment
with greatly reduced interfering network data. The staging area is
configured to reduce the threat of another unintended party (e.g.,
computing device) seeing data that is being transmitted between the
computing device 105 and the security domain 104.
The scenario established for either mutual authentication or
one-way authentication of the computing device 105 includes
initially receiving the computing device 105 with an un-configured
SIPA, e.g., from the factory. The computing device 105 is then
moved into a staging area. Within the staging area, the SIPA is
requested to generate a new public/private key pair. This request
can be a manual request (e.g., by setting a hardware jumper(s) on
the computing device) or a more automated request (e.g., from a
server on the staging area). The SIPA will create certificate
requests along with the SIPA public key to a certificate authority
to enroll the SIPA in a public key infrastructure. Furthermore, to
support mutual authentication, a trusted domain public certificate
156 is also typically transferred to the SIPA.
In certain embodiments, while in the staging area, the public key
associated with each computing device 105 is registered within the
security domain 104. Typically, the computing device public
certificate 159 is registered within the security domain 104. The
public key (or public certificate) can be stored, for example, in
persistent account 113. The secure data center 102 can map the
public key (or the public key certificate) to a computer account
for the computing device 105 and subsequently use that public key
(or public key certificate) during authentication operations with
the newly configured computing device 105.
When the computing device 105 exits the staging area, the computing
device contains the private key 157 and two public certificates.
The first public certificate is the computing device public
certificate 159 as shown in FIG. 13 that is associated with that
computing device. The computing device public certificate 159
allows the computing device to later validate itself to components
or devices in the security domain 104.
The second public certificate contained in the computing device is
the trusted domain public certificate 156 as shown in FIG. 13. The
trusted domain public certificate 156 is the certificate of the
trusted security domain 104. The trusted domain public certificate
156 allows the computing device including the SIPA to validate the
security domain 104 or entities within the security domain using
industry standard protocols. The trusted public key would, in one
embodiment, represent the public root certificate of the security
domain. The SIPA would trust that certificate and through protocols
not mentioned in this disclosure, SIPA would then trust
representatives of the secure domain that would be the domain
controller, or other authentication service.
The public certificates 156 and 159 can take any of a variety of
forms. In one embodiment, both of certificates 156 and 159 conform
to the X.509 standard.
After the computing device 105 including its configured SIPA is
removed or unplugged from the staging area, the computing device is
integrated or plugged into the production area 103 (also referred
to as a production network).
The access to the staging area 120 is thereby controlled through
physical security. One advantage of the staging area is that no
prior trust relation or identity is assumed between the computing
device and the security domain prior to the computing device
entering the staging area.
It should be noted that, although staging area 120 is illustrated
as being coupled to security domain 104 of secure data center 102
in FIG. 1, in alternate embodiments such a coupling may not exist.
In such alternate embodiments, authentication information (such as
a public key of the computing device or a computing device public
certificate) can be copied from the staging area 120 to the
security domain 104. This copying can be performed in a variety of
different manners, such as: sending an electronic mail (email)
message, optionally encrypted, to the security domain 104; having a
removable storage media such as a magnetic disk, optical disc,
flash memory, etc. on which to store the authentication
information; and so forth.
Example Switch and VLAN Structure
After the SIPA 106 of the computing device 105 is configured in the
staging area 120 of FIG. 1, the computing device 105 can be placed
in the production area 103 of the secure data center 102. In
addition to the security offered by the SIPA 106, the network
switch(es) 109 can be used to further enhance the security of data
center 102. For example, in certain embodiments, a protocol such as
PXE is used to obtain boot images over a network. However, there is
typically no network security built into PXE. When a computing
device sends out a request for a boot image, the computing device
accepts a boot image from any computing device that responds to the
request that the computing device sent. The computing device thus
responds to any device that responds to its request, even if that
device is a hostile or rogue computer.
As discussed above, in one embodiment, there are two VLANs that are
described with respect to the security domain 104, and may each be
considered as integrated in the switch 109. The two VLANs are the
production VLAN V.sub.1 and the private VLAN V.sub.2 as shown in
FIG. 2. The SIPA architecture supports authentication of the
computing device 105 before accessing the production VLAN V.sub.1
and for authenticating the computing device for membership in the
security domain as occurs with a domain join. The switch 109
provides isolation for the boot process.
When a computing device 105 such as a boot client first bootstraps,
the server will be on a private VLAN V.sub.2. The computing device
105 negotiates via the boot server (such as the preboot execution,
or PXE boot server) for an operating system. At this time, neither
the computing device 105 nor its operating system are trusted by
either the switch 109 or the security domain. In the 802.1x
protocol, the switch 109 initiates a message using in one
embodiment the Extensible Authenticated Protocol (EAP) as
configured by the user. The computing device 105, called in this
configuration a "supplicant", responds with credentials based on
its SIPA 106. The authentication server 108 performs a protocol
challenge that is used to establish one-way or mutual identity. If
the authentication succeeds, the switch 109 permits the port to
become a member of a production VLAN V.sub.1. The computing device
105 then submits a request to join the security domain. Upon
success, the computing device 105 is authenticated and ready for
authorized transactions. This authentication process is discussed
in more detail below.
FIGS. 3 and 4 illustrate network switches 109 in additional detail.
FIG. 3 illustrates an example with a single network switch 109,
while FIG. 4 illustrates an example with three network switches
109. Other embodiments may include two network switches 109 or
three or more network switches 109. One or more network switches
109 are also referred to herein as a switch assembly 111.
Each network switch 109 can be directly coupled to zero or more
boot clients 304, which are computing devices 105 (e.g., of FIGS. 1
and 2). Each network switch 109 can also be directly coupled to
zero or more other devices, such as an authentication server 108, a
boot server 116, a rogue or malicious server 199, and so forth. In
certain embodiments, the switch 109 couples a number of computing
devices 105 to the security domain 104. In other embodiments, the
switch 109 couples and controls data transmission between multiple
computing devices 105 that are associated with the security domain
104 as shown in FIG. 1.
Certain embodiments of the switches 109 (a variety of which are
described with respect to FIGS. 3 and 4) allow for those computing
devices 105 in the production area 103 that have not joined the
security domain to join the security domain 104, and allow those
computing devices 105 that have joined the security domain to use
the security domain.
Each port 302 in FIGS. 3 and 4 is physically located on one switch
109, and each switch includes multiple ports. Each port 302 is
provided with a parenthetical reference in FIGS. 3 and 4 such as
302(1), 302(2), 302(A1), 302(B1), 302(C1), etc., to distinguish the
ports even though the structure, function, and operation of each
port can be identical, except as where particularly indicated. The
ports 302 provide for data transfer and communication between each
switch 109 and a computing device, a server, another switch, or the
like. The ports 302 can be configured to provide or represent any
level of abstraction. Within this disclosure, each switch 109 can
be configured as any network box working to create an isolated
channel so message traffic, in particular broadcast traffic,
remains on the isolated channel.
Within the secure data center 102, each computing device is
attached to the switch 109 that supports port authentication. The
individual switches 109 can operate at the link-layer level, so the
port filter is called a link-layer port filter. To provide
security, switches 109 have port filters on some of the ports. The
port filters are placed on certain ports 302 and not on other ports
as shown in FIGS. 3 and 4 to allow the boot client to send messages
to only specific other ports, and/or to receive messages from only
specific other ports.
This disclosure provides a technique for establishing a secure boot
network within the secure data center 102 by viewing network ports
as being separated into two classes: trusted ports and un-trusted
ports. A port that couples to either a boot client 304 or another
switch 109 that has boot clients 304 attached thereto but no
trusted server attached thereto is classified as an un-trusted
port. A port that is coupled directly, or via one or more
additional network switches, to a trusted server such as a boot
server 116 or an authentication server 108 is classified as a
trusted port. In one embodiment, a trusted person such as a network
operator determines which ports are trusted. This can be done, for
example, when a trusted server such as a boot server 116 or an
authentication server 108 is coupled to a switch 109. Optionally,
other ports can later be indicated as trusted (e.g., after the
device coupled to the port is authenticated to the security domain
based on its SIPA 106).
The port filters are used in network switches 109 so that boot
clients coupled to un-trusted ports can communicate only with
devices on trusted ports. In certain embodiments, the port filters
are applied to transmitted signals. Filters are applied to each
un-trusted port to restrict the port so that the un-trusted port
can only send network packets to trusted ports. There are no
filters on the trusted ports, and the devices coupled to the
trusted ports can transmit network packets to all ports of the
network switch 109. So, if any network packets are sent by a boot
client 304 coupled to an un-trusted port, the port filter on that
un-trusted port will not pass the network packets to any un-trusted
port. For example, if a request were sent targeting a particular
boot client on another un-trusted port, the filter would not pass
the request to that other un-trusted port. By way of another
example, if a broadcast request were sent that was not intended for
a particular recipient or port, then the filter would pass the
request on to only trusted ports.
In other embodiments, the port filters are applied to a respective
port to filter the signals received at the port. Filters are
applied to each un-trusted port to restrict the port so that the
un-trusted port can only receive network packets from trusted
ports. There are no filters on the trusted ports, and the devices
coupled to the trusted ports can transmit network packets to all
ports of the network switch 109. If any network packets are
received at the un-trusted port to which a particular boot client
is coupled, the port filter on that un-trusted port will only pass
the particular boot client network packets that have been received
from a device coupled to a trusted port. For example, if a data
packet (such as a response to a request previously sent by the
particular boot client) were received at the un-trusted port, then
the filter would pass the data packet on to the particular boot
client only if the data packet were received from a trusted port
(regardless of whether the data packet was sent targeting the
particular boot client or was a broadcast data packet).
Using filtering, broadcast messages (such as messages sent by boot
clients 304 when bootstrapping) are directed to one particular
listening port that the boot server 116 is coupled to. One boot
server 116 is coupled to a listening port (302(4) in FIGS. 3 and
302(A4) in FIG. 4) and receives the broadcast messages from all
boot clients 304. The boot server 116 coupled to the listening port
(302(4) in FIGS. 3 and 302(A4) in FIG. 4) provides a suitable
bootstrap service such as DHCP and PXE, and responds appropriately
to the broadcast messages with response messages.
The ports 302 as shown in the switches 109 in FIGS. 3 and 4 are
provided with either a filter or no filter as indicated in the
figures. The presence of a filter within each port 302 that is
connected to a first boot client 304 prevents broadcast requests
from a second boot client from reaching the first boot client. Many
filters that are applied to the ports 302 of the switches 109 are
selective so that boot clients 304 receive only certain messages
from other servers such as boot servers and authentication servers,
etc. The ports 302 that are coupled to either a boot server 116
(such as the PXE/DHCP server), an authentication server 108, or
another switch 109 that has a boot server 116 or authentication
server 108, have no filter. Those ports 302 that are coupled to a
boot client 304 or a port 302 to another switch 109 that is not
coupled to the boot server 116 or authentication server 108 has a
filter.
One embodiment of the switches 109 such as can be applied in the
embodiments of FIGS. 3, and 4 are IEEE 802.1x compliant, and as
such they support link-layer source port filtering, and private
VLAN V.sub.2 protocols. The link-layer source port filtering
directs message traffic within the switch before the computing
device 105 is authenticated. In this mode, broadcasts from each
boot client 304 are directed to a designated source port that
corresponds to the boot server 116.
The networked configurations or topographies using the switches 109
can vary considerably. For instance, the FIG. 3 network includes a
single switch 109 while the FIG. 4 network includes three switches
109 (described as the upper, middle, and lower switch based on
their relative positions in FIG. 4).
With reference to FIG. 4, for example, the middle switch 109
configures port 302(A4) as the source port because it is connected
to the boot server 116. The upper switch 109 of the switch assembly
111 has port 302(B3) as the configured source port because it is
coupled to the middle switch (to which the boot server 116 is
coupled). Similarly, the lower switch 109 of the switch assembly
111 has port 302(C3) configured as the source port.
Broadcasts from each boot client 304 in the upper switch 109 are
directed to the port 302(B3) on the upper switch that is connected
to the port 302(A2) on the middle switch since the boot server is
on the middle switch, and the broadcasts do not make it through any
other ports (e.g., ports 302(B1), 302(B2), 302(BN), 302(AN),
302(A5), 302(A1), 302(A3), and so forth) to other boot clients 304
due to the filters associated with the ports 304. Broadcast from
each boot client 304 in the lower switch 109 are directed to the
port 302(C3) on the lower switch that is connected to port 302(A5)
on the middle switch, and do not make it through any other ports
302 to other boot clients due to the filters associated with the
ports. Broadcast from any boot server 116 on the middle switch 109
are also directed to the ports 302(A4) and 302(A1) since they are
respectively connected to the boot server 116 and the
authentication server 108. Any boot client 304 on the upper switch
109 is serviced by the port 302(B3); and any boot client 304 on the
lower switch 109 is serviced by the port 302(C3).
FIG. 4 therefore contains a link between the port 302(A2) and the
port 302(B3). Also a link exists between the port 302(C3) and the
port 302(A5). The boot clients 304 that broadcast on the upper
switch 109 are each directed to port 302(A2) of the middle switch
109, to continue to port 302(A4) to the boot server 116. The boot
clients 304 that broadcast on the lower switch 109 are each
directed to port 302(A5) of the middle switch, to continue to port
302(A4) to the boot server. In this manner, two or more switches
109 having a single boot (i.e., PXE) server and a single
authentication server 108 can operate together.
An undesired rogue server 199 may exist on a switch 109 (e.g., the
upper switch in FIG. 4). The authentication server 108 limits
authentication of any rogue server 199 into the secure data center
102. Furthermore, the port filters limit the ability of the rogue
server 199 to respond to any broadcast requests. There may also be
other servers attached to non-authenticating switches 111. These
other servers should be configured to limit impact of non-802.1x
attached computing devices upon the infrastructure of the secure
data center 102.
While there is only one boot server 116 illustrated in each of
FIGS. 3 and 4, there may be certain embodiments of the secure data
center 102 in which there are two or more boot servers 116 (coupled
to the same switch 109 or different switches 109). In such
configurations, each computing device 105 could mutually
authenticate or one-way authenticate with one or more of the boot
servers 116.
The switches 109 essentially provide physical port authentication
and link-layer source port filtering to each computing device (that
allows authentication with the private VLAN V.sub.2, authentication
with the production VLAN V.sub.1, or authentication with a
particular network, etc.) on/off, and/or port authentication.
The switch 109 directs the message traffic on a physical attachment
(port) basis along with source port filters and bounded network
addresses spaces to establish the virtual local area network(s)
(VLAN) such as shown as V.sub.1 and V.sub.2 in FIG. 2. One
embodiment of the switch 109 can be designed to operate based on
the IEEE 802.1x protocol (incorporated herein by reference).
The configuration of the switches 109 as shown in FIGS. 3 and 4
mitigate vulnerabilities from using PXE and DHCP protocols, both of
which are vulnerable to network based attacks. Rogue servers 199
such as on the port 302(BN) of the upper switch 109 of FIG. 4
cannot offer a PXE response because the original broadcast messages
from all boot clients are directed away from ports with the rogue
servers 199 (e.g., due to the filter within the port coupled to the
rogue server 199). The rogue server 199 also cannot access the
production VLAN V.sub.1 until the particular switch 109
authenticates the rogue computing device 199, which the switch 109
will not do as the rogue server 199 will have no SIPA 106 or no
SIPA 106 configured within the staging area.
The computing device 105, the switch 109, and the security domain
104 are used to begin a port authentication protocol when the
operating system activates the hardware (associated with a network
interface card in one embodiment) that is in communication with the
switch 109. The computing devices that are characterized as the
boot client with SIPA 304 are shown as being part of the security
domain 104 in FIG. 4, which is true after the computing device
joins the security domain. Prior to the computing device/boot
server joining the security domain, the boot server is not a
portion of the security domain. The rogue server 199 is never
considered to be a portion of the security domain since it never
joins the security domain. The switch 109 acts by detecting whether
the link is live using link-layer media sense. This protocol
provides one-way authentication. Mutual authentication is also
provided if during the staging phase that is performed within the
staging area as described with respect to FIGS. 8a and 8b, the
computing device accepts and stores a public certificate or key of
the trusted entity in the security domain.
Successful port authentication permits boot clients 304 to use the
production VLAN V.sub.1 as shown in FIG. 2. Failure to authenticate
the boot client 304 causes the switch 109 to take no action.
Failure to authenticate the security domain 104 of the secure data
center causes the boot client 304 to refuse the offered operating
system and retry the bootstrap. Under these circumstances, the boot
client computing device remains isolated. Following the port
authentication success, the client computing device is granted
access to a production network such as production VLAN V.sub.1.
After joining the production VLAN V.sub.1, the boot client's
operating system initiates operations to join the security
domain.
Example Domain Join
The operating system of the computing device 105 typically contains
an identity associated with the operating system. This identity is
established through some association with a computer account that
is controlled by the security domain controller 115, and exists in
the security domain 104 as shown in FIG. 2. The security domain
controller 115 includes a list of the computing devices 105 (e.g.,
in a directory) that are known to, and trusted by, the security
domain 104. This list is established as the computing devices 105
pass through staging area 104.
Data from the persistent identity 154 of the SIPA is physically
separated from the operating system instance running on the
computing device 105. The separation reduces the possibility that
any keys, certificates, or key information that is contained within
the SIPA would be compromised to locations outside of the SIPA. The
computing device can be identified in the security domain
controller 115 based on the persistent identity 154 of the SIPA 106
(e.g., based on the public key certificate of the computing
device), and thus can be used rather than the identifier of the
operating system of the computing device in the security domain
controller 115. Alternatively, an identity of the operating system,
separate from the public key or public key certificate of the
computing device, can be generated based on the persistent identity
of the SIPA 106 (e.g., using the public key certificate to
authenticate the computing device) and be maintained in the
security domain controller 115.
Credentials may be considered in this disclosure as computing
device accessing credentials. In one embodiment, the security
domain access credentials may be acquired on the computing device
by: a) storing a persistent identity on the computing device; b)
deriving data that includes the security domain access credentials
from the persistent identity; and c) transferring the derived data
to a security domain to allow the computing device to join the
security domain.
When a computing device with an identity communicates with the
security domain, the computing device exchange messages for
authentication. The computing device can be discovered as a unique
entity on the network even if the computing device has no operating
system on start-up by using the identity of the SIPA. With a
computing device having a separate identity from the operating
system, the security domain has the ability to communicate with
either resource. In one embodiment, each operating system has a
separate identity, and as such can be distinctly cryptographically
authenticated from other operating systems and the persistent
identity of the SIPA in the computing device.
Conventional security domain accounts are referred to as a computer
account. This computer account relates to a computing device
including its operating system and hardware. By storing the
identity of the computing device persistently in the SIPA, the
computer account is separated from the operating system instance
uniquely and securely.
Using the persistent account stored in the security domain
controller 115 and the persistent identity in the SIPA 106, a trust
relationship can be established that provides a secure domain join
of the SIPA 106 after the computing device is configured in the
staging area. The secure domain join mitigates spoofing threats (by
using the SIPA 106, the possibility of an imposter posing as the
computing device is reduced). The SIPA secure domain join can also
mitigate information disclosure that occurs in conventional
computing devices joined to the security domain when trusted
employees are given a secret used to join the computing device to
the security domains. The SIPA 106 allows the authentication
involved in the domain join to be automated and completed without
human intervention.
Using the automatic secure domain join as provided by the SIPA
interfacing with the security domain, input of a shared secret or
key does not have to be performed by a trusted person as with
conventional systems. This secure domain join allows the computing
device to be authenticated automatically without keyboard input or
certificate information by a trusted employee. The domain join is
thereby automatic, remote, and no trusted employees have to travel
to the computing device to perform the domain join. The computing
device is provided membership in the security domain based on the
trusted persistent identity that is contained in the SIPA.
Example Operating System Booting
This disclosure provides a variety of embodiments in which a
portion of, or the entirety of, an operating system can be securely
downloaded to a computing device. In one embodiment, only an
initial boot portion of the operating system of the computing
device 105 is initially maintained in persistent memory. As such,
at least a portion of the operating system is retrieved from some
remote location to the computing device 105 upon booting. As such,
there is no requirement for local persistent storage of the
entirety of the operating system within the memory 134.
Three memory configurations that allow for storing none or only a
portion of the operating system within the local memory 134 of the
computing system include: a) locally attached storage of the
operating system; b) network attached storage of the operating
system; and c) virtualized storage of the operating system in
memory.
In locally attached storage of the operating system, the operating
system can be at least partially located on the hard drive of the
computing device 105. In another instance, the computing device
stores its operating system in a chip attached to the motherboard
or the motherboard itself, at some local location that is separate
from the memory 134. When the operating system is instantiated, the
operating system becomes resident in a random access memory (RAM)
region of the computing device.
In network-attached storage of the operating system, the operating
system is stored at some remote network location outside of the
computing device 105. For example, in many workstation computing
device environments, the operating system is booted over the
network to a RAM within the computing device 105 from a storage
unit on a server that is remote from the computing device.
In virtualizing the operating system in memory, data that is
associated with the operating system is contained within a
virtualized location such as a virtual disk (e.g., a RAM disk)
within the memory 134. The data is copied to the virtual disk from
some other location such as some network location.
In many versions, the SIPA 105 is structurally and functionally
independent of the operating system state and the existence of the
operating system on the client computing device as shown in FIG. 2.
In these versions, the SIPA 106 can be configured as a complete and
structurally separate package that is protected from and
structurally distinct from the CPU 132 and the memory 134.
Example Authentication Process
One embodiment of an authentication mechanism is now described by
which computing devices 105 become mutually authenticated or
one-way authenticated with respect to the secure data center 102.
The secure data center 102 is populated with computing devices 105
with SIPAs that are not configured, and are not yet part of
security domain 104.
One generalized embodiment of an authentication process 500 is
described with respect to FIG. 5, in which the SIPA attempts to
authenticate the computing device 105, such as a boot client 304 in
FIGS. 3 and 4, with respect to the security domain as shown in
FIGS. 1 and 2. The authentication process 500 starts with 502 in
which the network computing device seeks authentication by the
security domain. In 504, the security domain considers the
authentication request of 502, and either grants or rejects the
request. The security domain will grant the request if the trusted
domain public certificate contains sufficient key information to
authenticate the computing device that is associated with the SIPA.
The authentication process 500 continues to 506 in which if the
authentication request is granted, then the computing device joins
the security domain 104 of FIGS. 1 and 2.
The authentication process 500 as described with respect to FIG. 5
involves both the computing device and the security domain. One
embodiment of the authentication process 500 is described with
respect to FIGS. 6a and 6b that describe respectively a computing
device authentication process 600 and a security domain
authentication process 630. The computing device authentication
process 600 describes one embodiment, from the perspective of the
computing device, of authenticating the computing device with
respect to the security domain. The security domain authentication
process 630 describes one embodiment, from the perspective of the
security domain, of the security domain authenticating the
computing device.
Initially, in operation 602, the computing device is powered on as
shown in FIG. 6a. After being powered on, the computing device
requests access to a resource(s) that is contained within the
security domain in operation 604. As the resource(s) is within the
security domain, the resource(s) can also be referred to as a
secure resource(s). Examples of such resources include an operating
system, portions of an operating system, an application program(s),
and so forth. Within the computing device authenticating process
600, some level of authentication from the security domain is
optionally requested by the SIPA 106.
Process 600 continues to operation 606 in which the computing
device transmits a resource access request to within the security
domain. Following operation 606, the computing device waits for
operation 608 in which the computing device receives the resource
access response from the security domain. Between operations 606
and 608, the security domain authentication process 630 as
described with respect to FIG. 6b is performing all of its
operations and decisions 632, 634, 636, 638, 640, and/or 642.
Following the operation 608, the computing device authenticating
process 600 continues to operation 610 in which the computing
device determines whether the access is granted to the computing
device to use the resource within the security domain. If the
answer to the decision 610 is no, then the computing device
authenticating process 600 continues to 612 in which the resource
request fails and the security domain is not granting access to the
requested resource. However, if the answer to the decision 610 is
yes, then the computing device authentication process 600 succeeds
and continues to operation 614 in which the computing device
process the access grant response. Any of a wide variety of actions
can be taken as part of this processing of operation 614, such as
receiving the requested operating system or application from the
security domain, communicating with devices in the security domain,
and so forth.
After operation 612 or 614, the computing device authentication
process 600 continues to the decision 616 in which the computing
device determines whether to request access to an additional
resource(s) within the security domain. If the answer to the
determination in decision 616 is yes, that access to additional
resource(s) should be requested, then process 600 returns to act
604 to request access to one of those additional resource(s).
However, if the answer to the determination in decision 616 is no,
that access to additional resource(s) should not be requested, then
process 600 continues to operation 618 where process 600 ends.
One embodiment of the security domain authentication process 630
that is described with respect to FIG. 6b describes one embodiment
of the security domain authenticating a computing device to use a
resource that is contained within the security domain. The security
domain authenticating process 630 includes operation 632 in which
the security domain receives an access request from the computing
device, which has been described in operation 606 of the computing
device authenticating process 600 of FIG. 6a. The security domain
authenticating process 630 continues to operation 634 in which the
security domain attempts to validate the access request. In certain
embodiments, the security domain attempts to validate the access
request based on the persistent identity within the SIPA 106 of the
computing device from which the request is received.
The security domain authenticating process 630 continues to
decision 636 in which it is determined whether the access request
is valid. If the answer to the decision 636 is yes, then the
security domain authenticating process 630 continues to operation
638 in which the security domain grants access to the resource for
the computing device. Following the operation 638, the security
domain sends a grant access response to the computing device, which
is received in the operation 608 of the computing device
authenticating process 600 of FIG. 6a.
However, if the answer to the decision 636 is no, then the security
domain authenticating process 630 continues to operation 640 in
which the security domain denies access to the resource for the
computing device. Following the operation 640, the security domain
sends a deny access response to the computing device, which is
received in the operation 608 of the computing device
authenticating process 600 of FIG. 6a.
It should be noted that, with respect to process 630 of FIG. 6b,
validating an access request may involve operations from one or
more devices within the security domain 104 of FIGS. 1 and 2.
Additionally, in certain embodiments the device(s) within the
security domain 104 can process multiple access requests
concurrently, whether the multiple access requests are from the
same or different computing devices 105.
FIGS. 6a and 6b discuss access to resources. It should be noted
that access to a particular resource can be predicated on obtaining
access to one or more other resources. Examples of such situations
are discussed in additional detail below with reference to FIGS.
8a, 8b, 9a, 9b, 9c, 10a, 10b, and 11. Alternatively, access to a
particular resource can be independent of access to any other
resource. For example access to a first restricted VLAN may be
independent of access to a second restricted VLAN.
FIG. 7 shows one embodiment of a challenge technique 700 that the
authentication server 108 of the security domain 104 uses to
challenge the identity of the computing device 105 including a SIPA
106 as described with respect to FIGS. 1 and 2. The challenge
technique 700 includes operation 702 in which the access of the
computing device is authenticated with respect to the resource of
the security domain, and operation 704 in which the computing
device makes use of the resource of the security domain based on
the authentication.
In one embodiment, operation 702 includes operations 706, 708, and
710. In operation 706, the authentication server challenges the
computing device 105. In the challenge, the authentication server
generates random challenge information (e.g., a random number), and
encrypts the random challenge information with the public key of
the computing device 105 to produce the challenge. The public key
of the computing device 105 is contained in the computing device
public certificate. The authentication server then sends the
challenge to the computing device.
In operation 708, the cryptographic processor 150 of the computing
device 105 decrypts the challenge using its private key 157
contained in the isolated storage portion 152 of the SIPA as shown
in FIG. 13 to yield a challenge response. The challenge response is
derived by decrypting the challenge using the private key 157 of
the computing device 105, and then extracting the random challenge
information. The random challenge information is then re-encrypted
by the cryptographic processor 150 using the public key of the
authentication server (e.g., as contained in the trusted domain
public certificate 156 of FIG. 13) to form the challenge response.
The computing device 105 then sends the response that is encrypted
using the public certificate of the trusted domain back to the
authentication server.
In operation 710, the authentication server then performs a compare
by decrypting the challenge response using the private key of the
authentication server. The challenge information from the decrypted
challenge response is then compared to the original random
challenge information as sent in operation 706. If the original
random challenge information and the challenge information from the
decrypted challenge response are the same, then the computing
device is authenticated. The authentication server assumes that
only the computing device, which knows the private key of the
computing device, would have been able to decrypt the challenge
sent in operation 706 and extract the random challenge information
from the challenge. This allows the computing device to make use of
the requested resource in operation 704.
FIG. 11 is a diagram of one embodiment of the authentication levels
or stages relative to a security domain that may be attained by a
computing device containing the SIPA. Each level or stage
illustrated in FIG. 11 represents access to a particular resource
that is predicated on access to the resource in the previous level
or stage.
The first level or stage in the example of FIG. 11 is a PXE stage
1102. The PXE stage 1102 is carried out using an initial private
VLAN V.sub.2 as described with respect to FIG. 2. The next level or
stage is the deployment agent stage 1104, followed by the full
operating system stage 1106, followed by the domain join of
operating system stage 1108, and finally the operating system
authentication stage 1110. The higher the level obtained in FIG. 11
(e.g., by obtaining a higher level of operating system), the
greater the level of authentication of the computing device with
respect to the security domain. Each of the levels or stages 1104
through 1110 can be performed in the same VLAN, such as production
VLAN V.sub.1 described with respect to FIG. 2, or one or more other
VLANs.
Example Staging Area Scenario
One embodiment of a computing device technique that involves the
staging area 120 is described with respect to FIGS. 8a and 8b. The
process for the computing device within the secure data center 102
involves applying the computing devices 105, prior to placing the
devices 105 in the production area 103, to the staging area 120
using a staging area flow diagram 800 as described relative to
FIGS. 8a and 8b.
In the staging area flow diagram 800 as described in FIGS. 8a and
8b, the computing device 105 is physically moved into the staging
area. In one embodiment, the staging area operator may at their
discretion cause the SIPA cryptographic processor 150 to regenerate
the public/private key pair for the SIPA 106. The staging area 120
allows for a persistent identity of the computing device to obtain
key information without any human intervention by a trusted human.
Such human intervention in conventional systems may take the form
of the human providing a shared secret, such as occurs in smart
cards. Alternatively, the human intervention would take the form of
the human manually inputting key information (that is used to
generate the key pair 158 that is contained in the persistent
identity 154 as shown in FIG. 2) by, for example, typing in the key
information on a keyboard. While private keys and public keys are
represented extremely long numbers, the key information that is
considerably shorter such as input from a trusted human can be used
to generate the keys.
By reducing the human intervention by a trusted human when the
computing device is in the staging area, the process of providing
the keys to the security domain is largely automated.
One embodiment of the staging area flow diagram 800 includes a link
layer segment 808, a dynamic host configuration protocol (DHCP)
segment 810, a preboot execution (PXE) segment 812, and a staging
operating system segment 814. The segments 808, 810, 812, and 814
occur within the staging area 120 to provide a key pair to the
computing device 105 with respect to the security domain 104 of
FIGS. 1 and 2. In one scenario, a human carries a computing device
into the staging area. At this point, the computing device does not
contain any keys in its persistent identity. For instance, an owner
of a new computing device would insert the computing device into a
slot of a dedicated chassis (not shown), with the chassis wired to
the staging area in a manner that reduces network-based threats. In
this configuration, the computing device can access servers (e.g.,
the authentication server 108 and the boot server 116 as shown in
FIGS. 3 and 4) that are located within the security domain. Upon
insertion of the computing device into the staging area, the
computing device is powered and then a physical mechanism
automatically closes a reset switch whereby the SIPA generates a
key pair.
The link layer segment 808 occurs within the staging area 120 of
FIG. 1 at the link-layer level. The resource for which access is
being requested in link layer segment 808 is the staging VLAN. In
the link layer segment 808 of FIG. 8a, the computing device
accesses a link-layer physical network of the staging area in
operation 826.
Following the link layer segment 808, the staging area flow diagram
800 continues to the DHCP segment 810 that applies at the DHCP
level. The resource for which access is being requested in DHCP
segment 810 is an Internet Protocol (IP) address. The DHCP segment
810 includes operation 834 in which the computing device requests
an address through the DHCP client protocol. In operation 838 of
the DHCP operation 810, the boot server allocates the Internet
Protocol (IP) address, and provides the address to the computing
device. In operation 840, the computing device configures the
TCP/IP network to use the designated IP address.
The preboot execution (PXE) segment 812 involves interfacing with
the staging area at the PXE level. The resource for which access is
being requested in PXE segment 812 is a PXE boot loader and staging
operating system. The preboot execution (PXE) segment 812 includes
operation 842 in which the computing device broadcasts the preboot
execution boot request. In optional operation 844, the boot server
validates the PXE boot request. The preboot execution (PXE)
operation 812 continues to 846 in which the boot server returns the
PXE boot response to the computing device. In operation 848, the
computing device downloads the PXE boot loader and the staging
operating system from the boot server.
The staging operating system segment 814 generates a certificate,
signed by a certificate authority, containing a public key of the
computing device. The resource for which access is being requested
in staging operating system segment 814 is a certificate containing
a public key of the computing device. In operation 850 of the
staging operating system segment 814, the staging operating system
of the computing device asks the SIPA to generate a public/private
key pair, retrieve the public key from the SIPA, Rand create a
certificate request that will be sent to a certificate authority,
perhaps using an industry standard format such as Public-Key
Cryptography Standard #10 (PKCS#10). In operation 852, the
certificate authority 110 as shown in FIG. 2 which is connected to
the staging area validates the certificate request. In operation
854, the certificate authority 110 signs the certificate that
includes the SIPA public key. In operation 856, the staging
operating system on the computing device stores the new certificate
in the SIPA. The computing device may also receive the public
certificate of the security domain.
It should be noted that various validation operations are discussed
in the flow diagram 800, such as operations 828, 844, and 852.
These discussions assume that the various validation operations are
successful. However, if any of the validations are unsuccessful
(e.g., in operation 828 the switch determines that access to the
network port is not valid), then the process of flow diagram 800
stops, and no new certificate will end up being stored in the SIPA
(in operation 856 of FIG. 8b).
Example Production Area Booting Scenarios
After the computing device 105 is enrolled within the staging area
120 of FIG. 2 as discussed above, the computing device 105 is
placed in the production area 103 of FIG. 1. The production area
103 can also be referred to as the production network. The
computing device 105 can be authenticated and have an operating
system installed thereon as described relative to FIGS. 9a, 9b, and
9c. In the production area booting scenario or process 900, the
potential for network-based threats exist. The production area can
be distinguished from the staging area since the staging area is a
place where threats typically do not exist; while the production
area uses a network where threats are assumed to exist but are not
known.
When the computing device 105 exits the staging area, it contains
the identity of the SIPA 106, but not necessarily any other state
or operating system. The computing device is then placed in the
production area 103 and coupled to a network switch 109. When the
computing device 105 is coupled to network switch 109 and powered
up, booting process 900 as described relative to FIGS. 9a to 9c
begins. Booting process 900 may also be performed in response to a
hardware or software reset of the computing device 105, or when the
computing device 105 is resuming operation from a standby,
hibernation, or other power-saving mode.
One embodiment of the production area booting process 900 includes
a link layer authentication segment 904, a dynamic host
configuration protocol (DHCP) authentication segment 906, a preboot
execution (PXE) authentication segment 907, a deployment operating
system authentication segment 908, and a staging operating system
authentication segment 910. Each of the access requests in segments
904, 906, 907, 908, and 910 can be authenticated as discussed above
with respect to FIGS. 6a and 6b.
The link layer authentication segment 904 authenticates the
computing device within the production network at the link-layer
level. The resource for which access is being requested in link
layer authentication segment 904 is the unrestricted production
VLAN. In the link layer authentication segment 904 of FIG. 9a, the
computing device accesses a link-layer physical network of the
production network in operation 914. In operation 916, the switch
determines that the access to the network port is valid. In
operation 918, the switch enables the network port and the switch
connects to the unrestricted production VLAN (e.g., VLAN network
V.sub.2 of FIG. 2). In operation 920, the computing device 105
completes the configuration of the link layer network
interface.
The DHCP authentication segment 906 authenticates the computing
device within the production network at the DHCP level. The
resource for which access is being requested in DHCP authentication
segment 906 is an Internet Protocol (IP) address. The DHCP
authentication segment 906 includes operation 922 in which the
computing device requests an address through the DHCP client
protocol. In operation 926 of the DHCP authentication segment 906,
the boot server allocates the Internet Protocol (IP) address, and
provides the address to the computing device. In operation 928, the
computing device configures the TCP/IP network to use the
designated IP address.
The preboot execution (PXE) authentication segment 907
authenticates the computing device within the production network at
the PXE level. The resource for which access is being requested in
PXE authentication segment 907 is a PXE boot loader and deployment
operating system. The PXE authentication segment 907 includes
operation 930 in which the computing device broadcasts the preboot
execution boot request. In operation 932, the boot server validates
the PXE boot request. The PXE authentication segment 907 continues
to operation 934 in which the boot server returns the PXE boot
response to the computing device. In 936, the computing device
downloads the PXE boot loader and a staging operating system from
the boot server.
The PXE bootstrap of segment 907 results in the computing device
105 booting an operating system image with the production area
booting process 900. When the computing device boots without an
operating system in a local store, a boot image is acquired from a
network source within the security domain 104.
The deployment operating system authentication segment 908
authenticates the computing device within the production network at
the deployment operating system level. The resource for which
access is being requested in deployment operating system
authentication segment 908 is a restricted production VLAN. In
operation 938 of the deployment operating system authentication
segment 908 in the production area booting scenario 900, the
deployment operating system on the computing device creates an
Extensible Authentication Protocol/Transport Level Security
(EAT/TLS) request to join a restricted production virtual local
area network (e.g., VLAN V.sub.1), and sends the EAP/TLS request to
the switch assembly. In operation 940 of the deployment operating
system authentication segment 908, the switch 109 of FIG. 2
delivers the EAP/TLS request to the authentication server. The
authentication server validates the computing device identity using
public and private key challenge-response with the SIPA over the
communication channel through the switch to the deployment
operating system on the computing device. In operation 942 of the
deployment operating system authentication segment 908, the
computing device configures the virtual network adapter that is
connected to the restricted production VLAN V.sub.1, and then
reboots. In operation 944 of the deployment operating system
authentication segment 908, the deployment operating system on the
computing device boots, and creates a request to join a production
VLAN.
The production operating system authentication segment 910 of the
production VLAN booting scenario 900 further authenticates the
computing device with respect to the security domain. The resource
for which access is being requested in production operating system
authentication segment 910 is the security domain. The production
operating system authentication segment 910 includes an operation
946 in which the production operating system on the computing
device boots, and creates a request to join a production security
domain. In operation 948, a security domain server validates the
identity of the computing device via public/private key challenges
and key response using the trusted domain public certificate that
is stored on the SIPA. In operation 950 of the production operating
system authentication segment 910, the security domain server
returns the security domain logon credentials to the computing
device. In operation 952 of the production operating system
authentication segment 910, the production operating system reboots
and uses the stored security domain logon credentials to access the
restricted production security domain.
When the computing device 105 downloads the operating system and
the SIPA does not have the public certificates stored in its
isolated storage portion 152, the automated deployment service 119
can send the encrypted binary computing device blob 1200 of FIG. 12
to the computing device 105. The computing device blob 1200 can be
encrypted using the public key of the SIPA. The blob 1200 includes
the computing device public certificate 159, as well as the trusted
domain public certificate 156. In this case, the computing device
105 asks for a particular computing device blob 1200 by submitting
its public key along with the request. The automated deployment
service 119 will catalog the binary computing device blobs 1200 by
public key and send the corresponding blob. If the computing device
105 is not a rogue, it will be able to decrypt the computing device
blob 1200 using its private key in the SIPA. In this way, only the
computing device 105 with the corresponding key pairs receives
their public certificate. When it has decrypted the computing
device blob 1200, the computing device 105 places the trusted
domain public certificates 156 and the computing devices public
certificate 159 as shown in FIG. 13 in the certificate store
contained within persistent identity 154 of the isolated storage
portion 152. In one embodiment, the authentication protocols
described above also are applied for network access and security
domain membership.
In the production area booting process 900 as described relative to
FIGS. 9a to 9c, where the computing device 105 boots and acquires a
boot image from the network, the computing device 105 uses an
industry standard protocol such as PXE to broadcast "discovery" for
a network identity and a network address. The network address and
the network identity are used to download the first boot image. The
network identity is set forth in the Dynamic Host Configuration
Protocol (DHCP).
Another embodiment of the production VLAN booting scenario or
process 1000 is described with respect to FIGS. 10a and 10b.
Booting process 1000 of FIGS. 10a and 10b is similar to process 900
of FIGS. 9a to 9c, however, process 1000 differs from process 900
in that in process 1000 the SIPA is used to retrieve operating
system software without using the unrestricted VLAN (e.g., VLAN
V.sub.2) as used in process 900. The production area booting
process 1000 includes a link layer authentication segment 1006, a
deployment operating system authentication segment 1008, a DHCP
authentication segment 1010, and a PXE execution segment 1012. Each
of the access requests in segments 1006, 1008, 1010, and 1012 can
be authenticated as discussed above with respect to FIGS. 6a and
6b.
In the link layer authentication segment 1006 of FIG. 10a, the
computing device accesses a link-layer physical network of the
production network in operation 1014. The resource for which access
is being requested in link layer authentication segment 1006 is the
network port. In operation 1016, the switch determines that the
access to the network port is valid. In operation 1018, the switch
enables the network port for communication, but does not connect to
any VLAN. In operation 1020, the computing device 105 completes the
configuration of the link layer network interface.
The deployment operating system authentication segment 1008
authenticates the computing device within the production network at
the deployment operating system level. The resource for which
access is being requested in deployment operating system
authentication segment 1008 is a restricted production VLAN. The
deployment operating system authentication segment 1008 includes
operation 1022 in which the network boot firmware of the computing
device creates an Extensible Authentication Protocol/Transport
Level Security (EAP/TLS) request to join a restricted production
VLAN (e.g., VLAN V.sub.1), and sends the EAP/TLS request to the
switch. In operation 1024, the switch delivers the EAP/TLS request
to the authentication server. The authentication server validates
the computing device identity using public and private key
challenge-response with the SIPA as shown in FIG. 7 over the
communication channel through the switch to the network boot
firmware on the computing device. In operation 1025, the
authentication server instructs the switch to enable port access of
the computing device to the restricted production VLAN. In
operation 1028, the network boot firmware of the computing device
configures the network stack to use the restricted production
VLAN.
The DHCP authentication segment 1010 authenticates the computing
device within the production network at the DHCP level. The
resource for which access is being requested in DHCP authentication
segment 1010 is an IP address. The DHCP authentication segment 1010
includes operation 1030 in which the networked boot firmware of the
computing device requests an address through the DHCP client
protocol. In operation 1034 of the DHCP authentication segment
1010, the boot server allocates the IP address, and provides the
address to the computing device. In operation 1036, the computing
device configures the TCP/IP network to use the designated IP
address.
The PXE authentication segment 1012 authenticates the computing
device within the production network at the PXE level. The resource
for which access is being requested in PXE authentication segment
1012 is a PXE boot loader and operating system. The PXE
authentication segment 1012 includes operation 1040 in which the
computing device broadcasts the preboot execution boot request. In
operation 1042, the boot server validates the PXE boot request. The
PXE authentication segment 1012 continues to operation 1044 in
which the boot server returns the PXE boot response to the
computing device. In operation 1046, the computing device downloads
the PXE boot loader and a staging operating system from the boot
server.
The PXE bootstrap of the PXE authentication segment 1012 results in
the computing device 105 booting an operating system image with the
production area booting process 1000. When the computing device
boots without an operating system, a boot image is acquired from a
network source within the security domain 104.
A SIPA solution includes system software and in one embodiment,
operating system programmers generally refer to drivers as a
software layer that works between hardware and the operating
system. An operating system may include authentication services or
it may be considered a supplemental package of software. In either
embodiment, standard authentication software generally needs to be
interfaced to the operating system and is typically either the
driver mentioned earlier or to a software API layer operating
system dependent. In one embodiment this additional software layer
is called a cryptographic software provider (CSP). A SIPA CSP
provides communication between the SIPA driver and all services
above including authentication services for network access and
security domain membership join authentication.
CONCLUSION
Various modules and techniques may be described herein in the
general context of computer-executable instructions, such as
program modules, executed by one or more computers or other
devices. Generally, program modules include routines, programs,
objects, components, data structures, etc. that perform particular
tasks or implement particular abstract data types. Typically, the
functionality of the program modules may be combined or distributed
as desired in various embodiments.
An implementation of these modules and techniques may be stored on
or transmitted across some form of computer readable media.
Computer readable media can be any available media that can be
accessed by a computer. By way of example, and not limitation,
computer readable media may comprise "computer storage media" and
"communications media." "Computer storage media" includes volatile
and non-volatile, removable and non-removable media implemented in
any method or technology for storage of information such as
computer readable instructions, data structures, program modules,
or other data. Computer storage media includes, but is not limited
to, RAM, ROM, EEPROM, flash memory or other memory technology,
CD-ROM, digital versatile disks (DVD) or other optical storage,
magnetic cassettes, magnetic tape, magnetic disk storage or other
magnetic storage devices, or any other medium which can be used to
store the desired information and which can be accessed by a
computer.
"Communication media" typically embodies computer readable
instructions, data structures, program modules, or other data in a
modulated data signal, such as career wave or other transport
mechanism. Communication media also includes any information
delivery media. The term "modulated data signal" means a signal
that has one or more of its characteristics set or changed in such
a manner as to encode information in the signal. By way of example,
and not limitation, communication media includes wired media such
as a wired network or direct-wired connection, and wireless media
such as acoustic, RF, infrared, and other wireless media.
Combinations of any of the above are also included within the scope
of computer readable media.
Although the description above uses language that is specific to
structural features and/or methodological acts, it is to be
understood that the invention defined in the appended claims is not
limited to the specific features or acts described. Rather, the
specific features and acts are disclosed as exemplary forms of
implementing the invention.
* * * * *
References