Insta PKI basics

1
Insta PKI basics

• Partner Training

2
Agenda

• Time schedule 12-15.9.2006
• 12.9.2006 Theory (slide shows)
• 13-15.9.2006 Practise and training and demos
• Location Tampere, Finland
• Insta Premises in Finlaysoninkuja 21 A

3
Day 1 11.9.2006, Theory

• Agenda
• General issues and introduction
• Insta company presentation shortly
• PKI theory
• X509 Certificates and certificate revocation
  lists
• Insta Certifier
• Architecture
• Services
• Insta Token Master
• PKI applications
• Designing the PKI

4
Day 2 12.9.2006, Theory

• Installing Insta Certifier (Windows and Linux)
• Configuring Insta Certifier ( VoiceCrypto
  Manager)
• CA creation and CA policy settings
• Setting up services (CMP, publishing, admin etc)
• Setting up LDAP directory for PKI publishing
• Administrating Insta Certifier (backup, logs,
  operators etc)
• Installing Insta Token Master
• Configuring Insta Token Master
• Certificate life-cycle management

5
Day 3, 4 13-14.9.2006, PKI Applications

• Configuring PKI into use in applications
• Windows domain login (MS Windows Server 2003 and
  MS Windows XP Pro)
• E-mail encryption (MS Exchange Server 2003 and MS
  Outlook 2003)
• Web security (MS IIS web server and several web
  browsers)
• Web security (Apache web server and several web
  browsers)
• Network security (Secgo Crypto IP VPN option
  for Secgo Mobile IP)
• Insta VoiceCrypto demonstration and training
• Insta PKI use cases
• Partner PKI use cases

6
Insta PKI Solutions
7
Insta PKI Solutions

• Turnkey solution for providing PKI and security
  services to end-users
• Total consulting, deployment and knowledge
  transfer process for
• Analysis of operational requirements
• Defining security policies and processes
• Designing and deployment of the infrastructure
• PKI training
• Management Administration processes and support
• System auditing by Insta for Insta Certified
  Partner
• Continuous support and development for technology
  and services for partner Insta partnership
  program

8
PKI

• Theory

9
Symmetric encryption (secret key method)

• Process Encrypt Decrypt
• Algorithms DES/3DES, AES, Blowfish. Key length
  56-128 bits
• Usually the keys are random numbers
• The same secret key must be shared between
  communicating parties. Confidentiality of the
  secret key must be protected during distribution.
• Encryption provides confidentiality

10
Asymmetric encryption (1/2)

• Also known as public key encryption
• The process is similiar to symmetric encryption
  (encrypt-decrypt)...
• ... but instead of a single secret key we have a
  key pair
• Public key available for everyone
• Private key accessible for the key holder only
• It is not possible to deduce the private key from
  the public key
• The keys are generated by certain key generation
  algorithm

11
Asymmetric encryption (2/2)

• Examples RSA, Diffie-Hellman
• Typical key lengths 1024 - 4096 bits
• Less efficient than symmetric algorithms (by
  several decades)
• In data encryption hybrid mechanisms are used
  i.e. symmetric keys are shared by using
  asymmetric encryption and the data is protected
  by using symmetric encryption
• Key distribution is easier
• Only public keys need to be distributed (no
  confidentiality requirements for public keys)
• Can be used
• in encryption to provide confidentiality
• in digital signatures to provide integrity and
  authenticity

12
Hash algorithms

• A hash value is a fingerprint of a message
• Hash value message digest fingerprint
• MD5, SHA-1, RIPEMD-160
• Very efficient one-way function
• H(M) H(M) should be difficult
• Hash functions are used in digital signatures and
  in HMAC constructs

13
Digital signature
Message
Hello, John! How are you doing out there? Blaah
blaah, Blaah blaah, Blaah blaah.
14
From Public Key cryptography to PKI

• PKI, Public Key Infrastructure, is based on
  public key cryptography
• Asymmetric algorithms
• Hash algorithms
• Digital Signature
• Public key cryptography does not solve
• Key distribution
• Key authentication
• Key validation
• PKI offers infrastructure to solve issues above
• Key s are certified by a trusted third party (CA)
  ? certificates
• The certificates are published by the CA
• The CA issues and publishes the Certificate
  Revocation List (CRL)

15
PKI building blocks

• A PKI consist of
• A Security Policy (CA Policy, CP)
• Certificate Practice Statement (CPS)
• Certification Authority (CA)
• Organization that issues certificates. The CA is
  responsible to define and publish the CP and CPS
  and also to act according to those.
• Registration Authority (RA)
• The RA has a delegated responsibility to identify
  the certificate applicant and make the
  certification request to the CA
• Certificate Distribution System (LDAP)
• Archive
• PKI-enabled Applications

16
Terminology

• Certificate, Data structure, which connects the
  public key (key pair) to its holder. The data
  structure is certified by CA with digital
  signature.
• CRL, Certificate Revocation List. A list of
  certificates revoked, before their periods of
  validity have expired. A certificate which has
  been placed on the revocation list cannot be
  re-activated for use.
• End Entity, A person, role person or computer
  system whose public key has been certified by an
  enciphered key of a CA and with whose
  personalized data the certificate is equipped
  with.

17
CA functions

• Issue certificates
• Verify information in certificate before issuance
  and make the proof-of-possession check (may be)
• Verify that all certificates conform profile
  before they are issued
• Maintain list of non-valid certificates that
  should no longer be trusted
• Distribute the certifiates and revocation-lists
• Maintain archive of certificates and CRLs to
  establish the validity also from the history data

18
X.509v3 Certificate (RFC 3280)

• Key identifiers
• Constraints
• Key usages
• Extended key usages
• Alternative names
• Policy info
• CRL distribution point
• Authority info access
• Subject info access
• etc

19
X.509v2 Certificate Revocation List (RFC 3280)
20
PKI functional architecture
Certificate repository
End-entities (PKI Users)
Certificates
Certificate / CRL retrieval
User view
System view
Registration, Initialisation, Certification, Key
pair backup Key pair recovery Key
update Revocation request
Certificate publishing
CRLs
Registration Authority
Certificate / CRL publishing
Cross-certificating
Certification Authority
Certification Authority 2
21
CA hierarchies
22
Techincal standards (by RSA)

• PKCS1, describes implementation of public-key
  cryptography based on the RSA algorithm, covering
  the following aspects cryptographic primitives
  encryption schemes signature schemes with
  appendix ASN.1 syntax for representing keys and
  for identifying the schemes
• PKCS7, describes general syntax for data that
  may have cryptography applied to it, such as
  digital signatures and digital envelopes
• PKCS10, syntax for a request for certification
  of a public key, a name, and possibly a set of
  attributes.
• PKCS8, describes syntax for private-key
  information, including a private key
• PKCS11, specifies an API, called Cryptoki, to
  devices which hold cryptographic information and
  perform cryptographic functions
• PKCS12, specifies a portable format for storing
  or transporting a user's private keys,
  certificates

23
Insta Certifier
24
Insta Certifier - architecture
25
Insta Certifier Engine

• CA key storing and operations done only by the
  engine
• Handles all cryptographic operations
• Certificate signing and verification
• CRL generation and publishing
• Connection to HSM
• Policy checkings for the certificate requests
• Database access only through Engine by using ODBC
  interface
• In the default installation Adaptive Server
  Anywhere, Sybase Inc database included
• Other databases can be also taken into use (e.g.
  Oracle) , but need extra work in the deployment
• For one system there is one engine

26
Insta Certifier Database contents

• All the functional information is stored to
  Insta Certifiers database
• CA keys (if not in the HSM)
• Issued certificates
• Certificate requests
• CA-policies
• Server and service configurations
• Entity data
• Operating logs and systme configurations
• Backed up (key escrow key recovery) entity
  private keys es encrypted with master password
• etc

27
Insta Certifier - Database location

• The database is stored in one database file
• E.g. Windows c\sshcertifierdb\certifier.db
• E.g. Linux /usr/local/certifier/bak/certifier.db
• In addition to this the database system uses two
  files
• Transaction log, which logs all database
  operations
• Temporay file, which is used when Certifier is
  runninfg and which is used to store temporary data

28
Insta Certifier Server

• To one Engine, it is possible to connect 1..n
  Servers and one Server can offer 1..n Services.
• Server is used to distribute installations
  logically, according to security level or
  geographically. (e.g. Different Server instances
  offer different services or are used to access
  different CAs or to different customers etc.)
• Also can be used as backup
• Administration services
• Administrator
• Enrollment services
• Web enrollment
• CMP
• SCEP
• External enrollment client service
• Other services
• Identity Integration service
• LDAP authentication service
• OCSP responder
• Publishing (LDAP, HTTP, external)

29
Communication between processes

• Certifier Servers are communicating with
  Certifier Enginenby using propriestry TCP-based
  protocol. The data is structured is association
  lists (ASL)
• The communication between components is secured
  by using TLS protocol with mutual
  certifiate-based authentication.
• The first certificates are created for the engine
  and server during installation
• The keys must be updated and new certificates
  enrolled before old certificates are expired
• Also the user connections to services can be
  defined to use TLS protection with Server
  authentication or mutual Client authentication.
  This is available e.g to following services
• Administration interface
• Web Enrollment
• LDAP-publishing

30
Administrator service

• Insta Certifier Web-based management user
  interface
• Functions
• Database searches
• CA management
• RA and delegated RA management
• Entity management
• Certificate and certificate request management
• Server and service management
• Operator management
• System configuration and management

31
Administration view
32
Adminsration service access control

• Access can be controlled in the service interface
  level and operator level
• Adminstrator Service access levels
• Super User
• Normak user
• Operaattorin pääsyoikeustasot (defined for every
  CA and RA)
• Super User
• Write and key recovery
• Write
• Entity Write
• Read and revocation
• Read
• No access
• Operator access levels (for the view)
• Show all
• Hide Super User
• Simple Admin UI

33
Multi approval

• The adminstration operation in the CA will be
  executed only after multi-operator approval.
• NOTE Before acitvating this feature, be sure
  that you have required amount of operators with
  appropriate access rights...
• The operation is put to Pending Change Set List
  queue until needed amount of operator approvals
  has been done.
• This can be limited to
• ...concern sysmte setitings
• ...concern CA-level changes

34
Web Enrollment service

• - Provides web based enrollment method
• - Enrollment can be done via
• Tailored web form
• PKCS10 request which has been generated in
  another application (e.g. in Microsoft IIS
  server)
• - This interface can also be used to publish CA
  certificates and CRLs

35
CMP service

• CMP service implements Certificate Management
  Protocol functionality and offers services to
  certificate life-cycle management
• CMP service is used to communication between RA
  and CA. The CMP is packeted inside TCP or HTTP
  session protocol
• CMP client can be for exampel Insta Certifier
  Externel Enrollment Client service, Insta Token
  Master or Aventra APM.
• Additionaly CMP can be used to CAlt-gtCA
  communication for example in CA
  corss-certification cases

36
CMP-protocol

• CMP Certificate Management Protocol (based on
  RFC2510 and RFC2511) defines complete services
  for certificate life-cycle management
• In addition to certificate enrollment the CMP
  defines services for e.g. certificate/key update,
  revocation etc
• - CMP is very multi-use protocol, but this also
  makes it complex
• - In Insta Certifier following CMP services are
  provided
• Initial request
• Cross-certification request
• PKCS10 request
• Revocation request
• Certification requests signed by an initialized
  end entity

37
SCEP service and SCEP-protocol

• SCEP-service offers Simple Certificate Enrollment
  Protocol services for SCEP-clients
• SCEP HTTP-based certificate enrollment protocol,
  which uses PKCS7 ja PKCS10 formats
• SCEP is used e.g. in some IPSec applications
  (e.g. Cisco IOS, PIX and Nokia CC )
• Authentication of SCEP client is based on shared
  secret
• Functionality
• Client gets CA-certificate from the server
• Client forms PKCS10-certificate request, which
  will be packeted by using CA-certificates public
  key to PKCS7-packet
• Supports RA and CA modes.

38
External enrollment client service

• External enrollment client service is used when
  Insta Certifier Server is used to form CMP
  certificate requests
• This is used when a Insta Certifier Server
  instance is acting as RA or when CA servers are
  doing cross-certification

39
Identity Integration service

• Identity Integration service is used when Insta
  Certifier is integrated to existing user
  managament store (LDAP or database)
• The certificates are enrolled or revoced
  automatically according to the user managament
  actions done in the user management store. (e.g.
  When users are created or deleted)
• The interface exists for LDAP and some common
  third party user management products
• This feature needs (almost) always special
  scripting

40
LDAP authentication service

• LDAP-authentication service is used to
  authenticate users during certificate enrollment
• In the authentication the username and password
  are checked from the LDAP.

41
OCSP responder service

• OCSP-service implements Onlice Certificate Status
  Protocol functionality, which is defined in RFC
  2560.
• OCSP is used to check the certificates validity
  status (avtive, revoced, suspended) in real-time.
  There is no delay that is caused by CRL validity
  time window.
• This might be used e.g in payment transactions

42
Publishing service (LDAP, external)

• Publishing service is used to publish
  certificates and CRLs
• In the most common way of doing publishing is the
  LDAP or Microsoft AD
• Also External method can be used. External
  methods are e.g to filesystem or some scripts can
  be defined to publish the data to e.g. to FTP
  server or to E-Mail.

43
LDAP-publishing pkiUser-schema

• User certificate publishing can be used by using
  pkiUser shcema
• pkiUser OBJECT-CLASS
• SUBCLASS OF top
• KIND auxiliary
• MAY CONTAIN userCertificate
• ID joint-iso-ccitt(2) ds(5) objectClass(6)
  pkiUser(21)
• Other possible choices are
• inetOrgPerson
• strongAuthenticationUser

44
LDAP-publishing - pkiCA-schema

• In CA certificate and CRL publishing can be used
  by using pkiCA shcema
• pkiCA OBJECT-CLASS
• SUBCLASS OF top
• KIND auxiliary
• MAY CONTAIN cACertificate
• certificateRevocationList
• authorityRevocationList
• crossCertificatePair
• Other possible choices are certificationAuthority
  shcema
• ActiveDirectory schema

45
CA policy checking (1/3)

• Certificate request from the enrollment client
• The CA Servers enrollment service(SCEP, Web
  Enrollment or CMP) receives and decodes the
  request
• The engine pre-processa the request
• Select the protocol
• Check the integrity of the request
• Bind the request to the CA
• Decrypt the request (SCEP)
• Bind the request to an entity
• Proof-of-Possession (make the POP i.e make sure
  that the requestor is having the private key for
  the public key in the request)

46
CA policy checking(2/3)

• 4. CA policy chain walkthrough
• Receive request
• This is executed at first when the request is
  received and in this chain the content of the
  request can be changed according to the CA policy
  (e.g validity time, key usages etc.)
• Decision whether the processing is continuing
  automatic (? accept request chain) or manual (?
  view request chain) or rejected.
• View request
• Manual approval, where the request is viewed to
  the operator and before this the automatic
  modification can be done by CA policy.
• Update request
• In this chain the operator can change the request
  and accept or reject the request.
• Accept request
• Chain where the request is finally accepted or
  rejected. Also some details (e.g. CRL DP or AIA)
  is added to the certificate.

47
CA policy checking(3/3)

• 5. Issuing the certificate (i.e. Signing the
  certificate template with CA private key)
• 6. Certificate delivery in response message to
  the client.

48
Logs

• Following log files are used in the Linux (by
  default)
• /usr/local/certifier/var/log/engine.log
• /usr/local/certifier/var/log/server.log
• /var/log/messages (syslog)
• Following log files are used in the Windows (by
  default)
• ltinstallation dirgt\engine.log (e.g. C\Program
  Files\Insta\Insta Certifier\engine.log)
• ltinstallation dirgt\server.log

49
Backup in Linux

• In Linux the backup procedure is configured with
  next script
• ./bin/ssh-ca-backupconf
• The script requests from the user and defines
• Directory where the transaction log is backed up
• Directory where the database file is backed up
• Backup schedule (daily, weekly, monthly)
• The backup can be don with following command
• ./bin/ssh-ca-backup
• The backup includes
• Database files and logs, PKI data (./var/pki),
  HSM-module configuration and data
• Every backup is stored to a sub-directory in
  ./var/bak directory Old backups are not
  overwritten.

50
Backup in Windows

• The backup in Windows is done followingly
• Stop the CA Server engine
• Backup the database file and log
• Backup the PKI-data (./pki/)

51
Typical configuration

• In typical configuration following components are
  needed
• Administration
• Publishing
• Certificate enrollment
• These can be configured in one server or can be
  distributed to several servers.

52
Supported platforms

• Insta Certifier version 3.x
• Red Hat Enterprise Linux 4 ES (x86)
• Sun Solaris 9 (SPARC)
• Microsoft Windows 2000 with SP4
• Microsoft Windows 2003 Server

53
Supported Cryptographic Algorithms, Standards,
and Protocols

• The supported public-key algorithms are
• RSA
• DSA
• The supported hash algorithms are
• MD5
• SHA-1
• The supported symmetric ciphers used with the TLS
  protocol are
• AES
• DES
• 3DES
• RC2
• RC4

54
Supported Certificate Standards Drafts

• RFC 2437, PKCS 1 RSA Cryptography
  Specifications Version 2.0
• PKCS 6 Extended-Certificate Syntax Standard
  Version 1.5
• RFC 2315, PKCS 7 Cryptographic Message Syntax
  Version 1.5
• PKCS 8 Private-Key Information Syntax Standard
  Version 1.2
• PKCS 9 v2.0 Selected Object Classes and
  Attribute Types
• RFC 2986, PKCS 10 Certification Request Syntax
  Specification Version 1.7
• PKCS 12 v1.0 Personal Information Exchange
  Syntax
• RFC 3039, Internet X.509 Public Key
  Infrastructure Qualified Certificates Profile,
• RFC 3280, Internet X.509 Public Key
  Infrastructure Certificate and Certificate
  Revocation List (CRL) Profile
• draft-ietf-pkix-rfc2510bis-07.txt (RFC 2510bis),
  Internet X.509 Public Key Infrastructure
  Certificate Management Protocols
• draft-ietf-pkix-rfc2511bis-05.txt (RFC 2511bis),
  Internet X.509 Public Key Infrastructure
  Certificate Request Message Format (CRMF)
• draft-nourse-scep-06.txt, Cisco Systems Simple
  Certificate Enrollment Protocol

55
Other Supported Standards

• Certificate and CRL publishing and certificate
  status services
• RFC 2559, Internet X.509 Public Key
  Infrastructure Operational Protocols - LDAPv2
• RFC 2587, Internet X.509 Public Key
  Infrastructure LDAPv2 Schema
• RFC 2560, X.509 Internet Public Key
  Infrastructure Online Certificate Status Protocol
  OCSP
• Smart-card and cryptographic-token-related
  standards
• PC/SC v1.0, Interoperability Specification for
  ICCs and Personal Computer Systems
• PKCS 11 v2.11 Cryptographic Token Interface
  Standard
• PKCS 15 v1.1 Cryptographic Token Information
  Syntax Standard
• Other standards
• STD 5 (RFC 791), Internet Protocol
• STD 7 (RFC 793), Transmission Control Protocol
• RFC 2616, Hypertext Transfer Protocol HTTP/1.1
• RFC 2246, The TLS Protocol Version 1.0
• ODBC v3.x (Open Database Connectivity)

56
Insta Token Master
57
Insta Token Master

• The RA application, which implements CMP protocol
  (i.e. CMP client)
• Certificate enrollment to tokens (smart card and
  USB token)

58
Insta Token Master features

• Standards-based online enrollment (PKIX CMPv2)
• Certificates are enrolled on-the-fly during the
  personalization
• Offline enrollment
• Private key PKCS12, PKCS8
• Certificate PKCS12, binary (.bin) and
  certificate format (.cer,.crt)
• Flexibility for smart card profile definitions
• PKCS15 support
• Supports multiple keys per card
• Certificate templates
• Private keys can be created on the card
• Key escrow supported either to local storage or
  via CMP to CA
• Support for certificate update and renewal

59
Where to store private key? (1/2)

• Security of a system utilizing public-key
  cryptography relies on the security of the
  private keys
• It is assumed that private key is only known by
  the owner
• Authentication tokens provide tamper-resistant
  key storage together with
• Portability (can be carried like normal keys)
• Convenience (no need to remember long passwords)
• Two-factor authentication
• Need to 1) have something (e.g. card) and 2) know
  something (PIN)

60
Where to store private key? (2/2)

• Smart card
• private key protection (not able to copy or
  read)
• easy to handle and deliver
• price
• Needs additional reader
• USB token
• private key protection (not able to copy or
  read)
• easy to handle and deliver
• does not need additional reader
• File (PKCS12)
• Easy to deliver
• Can be copied

61
Example PKI Service Center
62
PKI Applications
63
Applications and PKI

• Public-key Infrastructure is enabling technology
• Enabling technology without enabled applications
  is useless
• Return on investment brought by applications is
  the driver to use PKI
• Business point of view to applications, ROI of an
  application can be based on
• Increased revenues
• Cost savings or avoidance
• Regulatory compliancy
• Risk mitigation

64
Technical point of view to applications

• Software products from several different vendors
  are needed to implement any given PKI-enabled
  application
• May involve operating systems, web browsers, web
  servers, VPN products, directories, e-mail
  software etc
• CSP interface (PKI-client) is needed to access
  the smart card (SetWeb, DigiSign etc)
• Interoperability is a critical requirement
• Communications protocols needed between third
  party products
• Third party products need to interface with the
  CA and directory
• Third party products need to be able to process
  certificate chains issued by CAs

65
Windows, Cryptographic Service Provider (CSP)
66
Customer use case 1 all in one card (1/2)

• Customer has taken into use hybrid smart card,
  which includes
• RFID antenna for physical access control
• Digital certificates
• Visual personalisation for identity card usage
• The card is used for physical access control in
  the building, electronic identification and
  visual identification.
• The digital certificates in the card are used for
• Windows domain login
• Intranet and extranet web portal authentication
  (Single-sign-on) with Netegrity SiteMinder from
  where the customer
• Remote connections (Client-to-LAN VPN) and branch
  office connections (LAN-to-LAN VPN).
• E-mail encryption and digital signing (e.g. With
  MS Outlook)
• Document encryption and digital signing (e.g.
  With E-Lock ProSigner)

67
Customer use case 1 all in one card (2/2)

• The digital certificates and visual
  personalisation are done in Registration
  Authority (RA) workstation, which includes
• RA software for electronic personalisation
• smart card printer for visual personalisation
• matrix printer for PIN/PUK-letter printing
• The Registration Authority workstation is
  integrated to the companys centralized user
  managament system.
• The card personalisations can be run as batch
  jobs and the personalisation is based on the
  information in the user managament system
• The RA also stores certificate life-cycle
  management information to the user management
  system.

68
Customer use case 2 - Certificate usage in banks

• eBanking for business customers
• The banks are using secure channels for business
  customers to execute financial transactions
• These connections are secured with IPSec-VPN and
  the connection parties are authenticated with
  digital certificates, which are certified by
  banking association.
• Internet banking for customers
• The customers are authenticated (SSL/TLS client
  authentication) to the Internet bank with digital
  certificates.
• The certificates can be certified by the bank
  itself or government authorities.

69
Summary

• Applications justify investment in public-key
  infrastructure
• PKI without applications equals to investment
  without return
• Third party application software products have
  reached maturity
• PKI support has become a standard built-in
  security feature
• VPNs, secure e-mail, web sign-on, Windows logon,
  Secure Shell etc
• Insta Certifier is designed to work with wide
  variety of 3rd party applications
• Open architecture, standard based implementation,
  interoperability and flexibility enable this

70
PKI Training applications

• Purpose
• To demonstrate PKI management (i.e. CA
  administration and certifiacate life-cycle
  management)
• To demonstrate PKI application usage
• PKI tools
• Insta Certifier (CA Server)
• Insta Token Master (RA Workstation)
• Setec SetWeb/Fujitsu mPollux DigiSign (PKI
  client)
• OpenLDAP Server (Directory Server)
• PKI applications
• Windows domain login (MS Windows Server 2003 and
  MS Windows XP Pro)
• E-mail encryption (MS Outlook 2003)
• Web security (MS IIS web server and several web
  browsers)
• Web security (Apache web server and several web
  browsers)
• Network security (Secgo Crypto IP VPN option
  for Secgo Mobile IP)

71
Training environment

• WINDOWS SERVER
• Windows 2003
• Active Directory
• MS Mail Server
• MS IIS

192.168.100.0/24

• Linux Server
• CentOS Linux
• Secgo Mobile IP HA
• Secgi Crypto IP GW
• Apache Web Server
• Insta Certifier
• OpenLDAP Server

192.168.101.0/24

• Router/VMWare Host
• Linux CentOS
• VMWare WS

• Wndows Client
• Windows XP
• Fujitsu DigiSign
• Secgo Crypto IP Client
• Secgo Mobile IP Client
• MS Outlooki
• MS Internet Explorer
• Insta Token Master

192.168.102.0/24
72
Planning the PKI
73
The PKI project?
74
Phases

• Analysis of operational requirements
• Defining security policies and processes
• Designing and deployment of the infrastructure
• PKI training
• Management Administration processes and support

75
1. Analysis of Operational Requirements

• Analysis of operational environment in
  co-operation with partner covering
• Legislation and other requirements or
  restrictions
• (End-)Customer requirements
• Local partners for accessories (e.g. smart cards,
  readers etc.)
• Security/quality certification need and process
  consultation
• Analysis of PKI application usages

76
2. Defining security policies and processes

• CA policy CPS policy (RFC 2527 )
• General provisions
• Identification ja authentication
• Operational requirements
• Physical, procedural, and personnel security
  controls
• Technical security controls
• Certificate and CRL controls
• Specification administration
• Requirements for premises and operating personnel
• Processes
• service agreement templates
• security agreement templates
• service description templates
• service production process
• risk assessment process
• helpdesk services (customer support, ITIL model)

77
3. Designing and deployment of the infrastructure

• Design the PKI technical system infrastructure
• Network connections
• Hardware
• Operating systems
• Software
• Security systems
• Personnel requirement profiles
• Sales resources
• Operating resources
• Administrating resources
• Deployment specialist services
• PKI application integration

78
4. Training

• Knowledge transfer to customer
• Training plan
• Training process
• Both on-site and off-site
• Training needs
• Management people (basic)
• Operating people (basic)
• Administrating people (advanced)

79
Tero Kovanen, Insta DefSec OyB.O. Box 174
(Finlaysoninkuja 21 A)FI-33101 Tampere,
FINLANDTel 358 40 77 23 011Fax [phone]
7880tero.kovanen_at_insta.fiwww.insta.fi,
www.certificate.fi