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)
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
Requirement
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
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
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
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
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.
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
Cross-Certification
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)