Infrastructure for Security


Pervasive substrate is a foundation or underspinning for a large environment

An infrastructure may be considered a pervasive substrate

E.g of infrastructures are electronic communications (LAN), and the electric power infrastructure.

LAN allows computer to transfer data when "plug in"

Electric power infrastructure allows equipment to geet voltage and current they need when "plug in"

A security infrastructure must provide a security underspinning for the entire organization (however the organization is defined) and must be accessible by all applications and objects in the organization that need security.

The "plug in"/entry points into the security infrastructure must be convenient and uniform.

Minimum overhead of using the infrastructure should be used (the just "plug-in" part)


Needs: Application Enablement

Security infrastructure (SI) should enable applications

SI enables applications to add security to their own data or resources and to add security to their interactions with other data or resources


There must be a easy-to-use public interface

The result (output of SI) must be predictable

The way SI works must be transparent to the device

In other words, how it does this need not be known by those device, but that it does this, consistently and correctly, is essential


Needs: Secure Single Sign-On (SSO)

Sign on or log on to applications

If remote from the user, passwords need to travel unprotected network (eavesdropping, interception)

How to pick up good password (password management, policies)

Different passwords for different systems is hard to use

Infrastructure might enable sign-on to be done locally and "extended" to other remote locations (More info during SSO)

The use of certificate or cookie could be used in the Internet scenario

Single could means

different operating system

different web applications

different domain

different legacy applications (MVS, AS/400, OS/390/Mainframe, etc)

Infrastructure should provide SSO for users.

And SI incorporates the mechanisms required to securely disemminate authentication information when and where it is needed.

So, applications just "tap into" the SI to access the information when necessary


End-User Transparency

Needs to be transparent

E.g. User do not need to know about web cookie when logging on to web resources

User should have no idea how the SI works

Level of trust from the users must be there


Comprehensive Security

Prevasive SI ensures a single, trusted, security technology (e.g. PK) is available throughout the *whole* environment

Unlimited number of things should be allowed to use the SI

Must cover all OS, apps (electronic mail, browsers, firewalls, remote access devices, file systems, databases, etc)

Keys must be used understood, and processed among all things. Thus, need a SI


Business Cases

Cost savings: Using SI leads to less complex integration for future deployment. (There is overhead in build the initial SI)

Interoperability (Internal): SI enables interoperability compares with p-t-p solution developed by different vendors

Interoperability (External): Needs a common infrastrusture to communicate with other enterprise

Uniform solution: Consistent, uniform solution to all apps is needed. (Easy of administration follows)

Possibility of actually achieving security: Security between independent point-to-point solutions is much less likely, even if each solution has been rigorously validated, because the interaction between these solutions is largely untested.


Public-Key Infrastructure Defined

A PKI is a prevasive security infrastructure whose services are implemented and delivered using public-key concepts and techniques.


Certificate Authority

Needs an authority to bind public key to a given identity

CA is the authority in the trusted model

CA certifies the public key / identity binding by digitally signing a data structure that contains some representation of the identity and a corresponding public key

The data structure is called public-key certificate (or web certicate, or x.509 certificate, or certificate)


Registration Authority

Optional component

An intermediate agent that stream line the process of certificate processing events

Do the signing of certificate request (CSR) with smart card or software module


Certificate Repository

Need a place to store certificates, so potential recipent can download the public key for a subject

Robust, scalable, on-line

Database and LDAP are the most popular choice


Certificate Revocation

Certificate binds public key and subject (user) identity

When machine or employee leave the organization, or compromise of corresponding private, the binding needs to be broken

Revocation is need

Most CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) is used


Key Backup and Recovery

Private keys could be lost due to

Forgotten passwords (used to protect the private key file)

Destruction of a medium (such as hard disk crash or broken smart card)

Key backup, Key Management server or XKMS (XML Key Management System) is needed


Automatic Renew (Key Update)

Certificate life cycle is finite

Theoretically, based on key lengths and asymmetric algorithms, key pairs need to be regenerated every now and then (E.g. every year)

Need to expire a certificate

Certificate Update / Certificate Renew / Key Update

Manul update for every single certificate is not good

Update process not fully automatic

Ideally, PKI handles certificate update automatically (replacing the old one with the new one)

When expiration approaches, renew process kicks off and new certificate is generated


Key History

Since certificates could get updated, revoked, (and replaced)

Subjects/Users will have a stack of certificates

These are called key and certificate history

Need all of them in order to decrypt old emails, etc.

Management of key histories must be automatic and totally handled by PKI



Not every organization will use the same CA

In other words, multiple PKIs exist which is independently implemented and operated, serving different environments and user communities

Need interconnection between CAs / PKIs

Cross-certification is needed

Microsoft Enterprise CA model

Cross-certified certificate


Support for Non-repudiation

We need to identify "who you said you are"

If a user signs a document, PKI must not allow a user to deny he/she signed it

Such a denial is referred to as repudiation of an action, PKI must provide support for avoiding or preventing repudiation - aka no-repudiation

Human is always involved, so PKI must support a process by providing data origin authentication, and a trusted attestation of the time the data was signed


Time Stamping

Non-repudiation requires secure time stamping

Time must be trusted, time value must be securely conveyed

"Time" need not to be correct, but just need to be trusted

Reference time could be used

Timestamp could be used for PKI related workflow functions, etc


Client Software

Client needs to know how to use

CA for obtain certificates

Repository to store certificates

CRL/OCSP to check for certificate status

Key services to obtain key info

Time stamp when during with documents

PKI-aware applicaitons (Email apps, browsers, with PKI imbedded functions)

Footprint is a problem (light, heavy, etc)