IP Security

IP Security
Have a range of application specific security mechanisms
eg. S/MIME, PGP, Kerberos, SSL/HTTPS

However there are security concerns that cut across protocol layers Would like security implemented by the network for all applications

IPSec
General IP Security mechanisms Provides
authentication confidentiality key management

Applicable to use over LANs, across public & private WANs, & for the Internet

IPSec Uses

Transparency

Benefits of IPSec
In a firewall/router provides strong security to all traffic crossing the perimeter In a firewall/router is resistant to bypass Is below transport layer, hence transparent to applications Can be transparent to end users Can provide security for individual users Secures routing architecture

IP Security Architecture
Specification is quite complex Defined in numerous RFCs
incl. RFC 2401/2402/2406/2408 many others, grouped by category

Mandatory in IPv6, optional in IPv4 Have two security header extensions:

Authentication Header (AH) Encapsulating Security Payload (ESP)

Architecture & Concepts

Tunnel vs. Transport mode Security association (SA)
Security parameter index (SPI) Security policy database (SPD) SA database (SAD)

Authentication header (AH) Encapsulating security payload (ESP) Practical Issues w/ NAT

Transport Mode vs. Tunnel Mode

Transport mode: host -> host Tunnel mode: host->gateway or gateway>gateway
Encrypted Tunnel
Gateway 1 Gateway 2

Encrypted

New IP Header

AH or ESP Header

Orig IP Header

TCP Data

Transport Mode
IP IP IPSec header options header Real IP destination ESP Higher layer protocol

AH

ESP protects higher layer payload only AH can protect IP headers as well as higher layer payload

Tunnel Mode
Outer IP IPSec Inner IP Higher header header header layer protocol Destination IPSec entity ESP Real IP destination

AH

ESP applies only to the tunneled packet AH can be applied to portions of the outer header

Security Association - SA
Defined by 3 parameters:
Security Parameters Index (SPI) IP Destination Address Security Protocol Identifier

Have a database of Security Associations Determine IPSec processing for senders Determine IPSec decoding for destination SAs are not fixed! Generated and customized per traffic flows

Security Parameters Index SPI

Can be up to 32 bits large The SPI allows the destination to select the correct SA under which the received packet will be processed
According to the agreement with the sender The SPI is sent with the packet by the sender

SPI + Dest IP address + IPSec Protocol (AH or ESP) uniquely identifies a SA

SA Database - SAD
Holds parameters for each SA
Lifetime of this SA AH and ESP information Tunnel or transport mode

Every host or gateway participating in IPSec has their own SA database

Security Policy Database - SPD

What traffic to protect? Policy entries define which SA or SA bundles to use on IP traffic Each host or gateway has their own SPD Index into SPD by Selector fields
Dest IP, Source IP, Transport Protocol, IPSec Protocol, Source & Dest Ports,

SPD Entry Actions

Discard
Do not let in or out

Bypass
Outbound: do not apply IPSec Inbound: do not expect IPSec

Protect will point to an SA or SA bundle

Outbound: apply security Inbound: check that security must have been applied

SPD Protect Action

If the SA does not exist
Outbound processing: use IKE to generate SA dynamically Inbound processing: drop packet

Outbound Processing
Outbound packet (on A)

A
IP Packet Is it for IPSec? If so, which policy entry to select? SPD (Policy) SA Database

IPSec processing Determine the SA and its SPI

SPI & IPSec

Packet

Send to B

Inbound Processing
Inbound packet (on B) From A
SPI & Packet
SA Database SPD (Policy) Was packet properly secured?

Use SPI to index the SAD

un-process

Original IP Packet

Architecture & Concepts

Tunnel vs. Transport mode Security association (SA)
Security parameter index (SPI) Security policy database (SPD) SA database (SAD)

Authentication header (AH) Encapsulating security payload (ESP) Practical Issues w/ NAT

Authenticated Header
Data integrity
Entire packet has not been tampered with

Authentication
Can trust IP address source Use MAC to authenticate
Symmetric encryption, e.g, DES One-way hash functions, e.g, HMAC-MD5-96 or HMAC-SHA-1-96

Anti-replay feature Integrity check value

IPSec Authenticated Header

Length of the authentication header

SAD

Next Header Payload Length (TCP/UDP)

Reserved

SPI Sequence Number

ICV

Integrity Check Value - ICV

Keyed Message authentication code (MAC) calculated over
IP header field that do not change or are predictable
Source IP address, destination IP, header length, etc. Prevent spoofing Mutable fields excluded: e.g., time-to-live (TTL), IP header checksum, etc.

IPSec protocol header except the ICV value field Upper-level data

Code may be truncated to first 96 bits

AH: Tunnel and Transport Mode

Original Transport Mode
Cover most of the original packet

Tunnel Mode
Cover entire original packet

Encapsulating Security Payload (ESP)

Provide message content confidentiality Provide limited traffic flow confidentiality Can optionally provide the same authentication services as AH Supports range of ciphers, modes, padding
Incl. DES, Triple-DES, RC5, IDEA, CAST etc A variant of DES most common Pad to meet blocksize, for traffic flow

ESP: Tunnel and Transport Mode

Original

Transport Mode
Good for host to host traffic

Tunnel Mode
Good for VPNs, gateway to gateway security

Outbound Packet Processing

Form ESP header
Security parameter index (SPI) Sequence number

Pad as necessary Encrypt result [payload, padding, pad length, next header] Apply authentication (optional)
Allow rapid detection of replayed/bogus packets Integrity Check Value (ICV) includes whole ESP packet minus authentication data field

ESP Transport Example

Authentication coverage Encrypted

Original IP Header SPI Sequence Number Payload (TCP Header and Data) Variable Length Padding (0-255 bytes)
Pad Length Next Header

Integrity Check Value

Inbound Packet Processing...

Sequence number checking
Duplicates are rejected!

Packet decryption
Decrypt quantity [ESP payload,padding,pad length,next header] per SA specification Processing (stripping) padding per encryption algorithm Reconstruct the original IP datagram

Authentication verification (optional)

Allow potential parallel processing - decryption & verifying authentication code

Architecture & Concepts

Tunnel vs. Transport mode Security association (SA)
Security parameter index (SPI) Security policy database (SPD) SA database (SAD)

Authentication header (AH) Encapsulating security payload (ESP) Practical Issues w/ NAT

NATs
Network address translation = local, LANspecific address space translated to small number of globally routable IP addresses Motivation:
Scarce address space Security: prevent unsolicited inbound requests

Prevalence of NATs
Claim: 50% of broadband users are behind NATs All Linksys/D-Link/Netgear home routers are NATs

NAT types
All use net-10/8 (10.*.*.*) or 192.168/16 Address translation Address-and-port translation (NAPT)
most common form today, still called NAT one external (global) IP address

Change IP header and TCP/UDP headers

NAT Example
Messages sent between host B to another host on the Internet Host B original source socket: 192.168.0.101 port 1341 Host B translated socket: 68.40.162.3 port 5280
A B C

IAPs Point of Presence

Router with NAT External IP: 68.40.162.3 Internal IP: 192.168.0.0

Router assigns internal IPs to hosts on LAN : A: 192.168.0.100 B: 192.168.0.101 C: 192.168.0.102

Will IPSec Work with NAT ?

Consider both AH and ESP protocols. Consider both transport and tunnel modes. For tunnel mode, consider the following two cases
Sender NAT IPSec Gateway 1 IPSec Gateway 2 Receiver Sender IPSec Gateway 1 NAT IPSec Gateway 2 Receiver

What about w/o port # translation?

Backup Slides

Combining Security Associations

SAs can implement either AH or ESP to implement both need to combine SAs
form a security association bundle may terminate at different or same endpoints combined by
transport adjacency iterated tunneling

issue of authentication & encryption order

Combining Security Associations

SA Bundle
More than 1 SA can apply to a packet Example: ESP does not authenticate new IP header. How to authenticate?
Use SA to apply ESP w/o authentication to original packet Use 2nd SA to apply AH

Outbound Packet Processing...

Integrity Check Value (ICV) calculation
ICV includes whole ESP packet minus authentication data field Implicit padding of 0s between next header and authentication data is used to satisfy block size requirement for ICV algorithm

Inbound Packet Processing

Sequence number checking
Anti-replay is used only if authentication is selected Sequence number should be the first ESP check on a packet upon looking up an SA Duplicates are rejected!

reject 0

Check bitmap, verify if new Sliding Window size >= 32

verify

Anti-replay Feature
Optional Information to enforce held in SA entry Sequence number counter - 32 bit for outgoing IPSec packets Anti-replay window
32-bit Bit-map for detecting replayed packets

Anti-replay Sliding Window

Window should not be advanced until the packet has been authenticated Without authentication, malicious packets with large sequence numbers can advance window unnecessarily
Valid packets would be dropped!

ESP Processing - Header Location...

IPv4 New IP hdr IPv6 ESP hdr Orig IP hdr ESP ESP TCP Data trailer Auth

New New ESP Orig Orig ESP ESP TCP Data IP hdr ext hdr hdr IP hdr ext hdr trailer Auth

Tunnel mode IPv4 and IPv6

Key Management
Handles key generation & distribution Typically need 2 pairs of keys
2 per direction for AH & ESP

Manual key management

Sysadmin manually configures every system

Automated key management

Automated system for on demand creation of keys for SAs in large systems

VPN: Virtual Private Network

Outline
Introductions What is it? Overview Security/Tunneling Advantages and Disadvantages Demonstration

Introductions
Gregg

Liz

BSG Student Developer Unified Western Grocers Retail Technology Specialist BSG Business Analyst ResNet Network Technician COB CRC: Tier 2/3 Support Technician BSG Student Tester/Analyst

Whitney

VPN: What is it?

Virtual Private Network Remote network communication through Internet Used by companies/organizations who want to communicate confidentially Two parts:
Protected or inside network Outside network or segment (less trustworthy)

VPN: Types
Secure VPNs use cryptographic tunneling protocols.
IPsec, SSL/TLS, OpenVPN, PPTP, L2TP, L2TPv3, VPN-Q and MPVPN

Trusted VPNs rely on the security of a single providers network to protect the traffic.
MPLS and L2F

VPN: Security
Encryption IPSec Authentication
User/System and Data AAA Servers
(Authentication, Authorization, and Accounting)

Firewalls

VPN: Tunneling
Requires 3 protocols
Carrier
Default network protocol

Passenger
Original data

Encapsulation
GRE, IPSec, L2F, PPTP, L2TP

VPN: Encapsulation

Figure 1

VPN: Tunneling (cont.)

Two Basic types of tunneling
Site-to-Site
Typically uses GRE

Remote-Access
Typically uses PPP

VPN: Advantages
Cost Effective Greater scalability Easy to add/remove users Mobility Security

VPN: Disadvantages
Understanding of security issues Unpredictable Internet traffic Difficult to accommodate products from different vendors

VPN Demonstration
Click on Start select Network Connections

VPN Demonstration
In Network Connections on the left hand side there is a link to Create New Connection click on this and a wizard will pop up assisting the user

VPN Demonstration
Select Connect to the Network at my Workplace

VPN Demonstration
Select Virtual Private Network Connection

VPN Demonstration
Make a name for this connection that you are establishing to distinguish this connection from other VPN connections that might already be established

VPN Demonstration
For this demonstration I am trying to connect to my wireless router off campus therefore the IP address that I insert is the IP address for my router which I can find out by running an ipconfig and it is the IP address for your default gateway

NOTE: Not all routers will allow users to VPN into it

VPN Demonstration
Personal preference as to whether or not you want other users to be able to use this VPN connection on this computer

VPN Demonstration

VPN Demonstration

VPN Demonstration
This is a profile (username and password) that has already been created on your router which can be created by typing in the IP address of your router in a web browser

VPN Demonstration

VPN Demonstration

In Start Run insert the IP address of the computer that you want to access that is connected to the router

VPN Demonstration

Using the same username and password already established for the router you can connect to this specific computer

VPN Demonstration

These are only the files that are shared on this computer

How to Connect to OSU:

How to connect to OSU: Dave Sullivan made a helpful Tutorial First on the Engineering Website you have to download the Cisco VPN Client One must acquire authorization information prior to using the VPN service Once registration is complete you download the appropriate client depending on your operating system; and follow the steps to complete the connection

E-mail Security: PGP and S/MIME

Outline
PGP
services message format key management trust management

S/MIME
services message formats key management

What is PGP?
PGP - Pretty Good Privacy general purpose application to protect (encrypt and/or sign) files can be used to protect e-mail messages can be used by corporations as well as individuals based on strong cryptographic algorithms (IDEA, RSA, SHA-1) first version developed by Phil Zimmermann PGP is now on an Internet standards track (RFC 3156)

PGP services
messages authentication confidentiality compression e-mail compatibility segmentation and reassembly key management generation, distribution, and revocation of public/private keys generation and transport of session keys and IVs

PGP / services

Message authentication
based on digital signatures supported algorithms: RSA/SHA and DSS/SHA
Ksnd-1
sender

hash

enc

PGP / services

m
receiver

h
compare

hash

dec
Ksnd

accept / reject

Message confidentiality
symmetric key encryption in CFB mode with a random session key and IV session key and IV is encrypted with the public key of the receiver supported algorithms: symmetric: CAST, IDEA, 3DES asymmetric: RSA, ElGamal
m

prng PGP / services

sender

Krcv {k, iv}Krcv

s.enc
k, iv {m}k

a.enc

Compression
applied after the signature enough to store clear message and signature for later verification it would be possible to dynamically compress messages before signature verification, but then all PGP implementations should use the same compression algorithm however, different PGP versions use slightly different compression algorithms applied before encryption compression reduces redundancy makes cryptanalysis harder supported algorithm: ZIP

PGP / services

E-mail compatibility
encrypted messages and signatures may contain arbitrary octets most e-mail systems support only ASCII characters PGP converts an arbitrary binary stream into a stream of printable ASCII characters radix 64 conversion: 3 8-bit blocks 4 6-bit 0 7 0 7 0 7 blocks
0 5 0 5 0 5 0 5

PGP / services

6-bit value
0 25 26 51

character encoding
A ... Z a z

6-bit value
52 61 62 63 (pad)

character encoding
0 9 + / =

Combining services
X := file

signature?
no

yes

generate signature X := s(X) || X

compress X := Z(X) generate envelop X := {k}Krcv || {X}k

encryption?

yes

PGP / services

no

radix 64 X := R64(X)

PGP message format

session key k { }Krcv { }Ksnd-1 session key component key ID of Krcv

timestamp
key ID of Ksnd signature leading two octets of hash hash

PGP / message format

timestamp message data

R64

filename
ZIP { }k

Key IDs
a user may have several public key private key pairs which private key to use to decrypt the session key? which public key to use to verify a signature? transmitting the whole public key would be wasteful associating a random ID to a public key would result in management burden PGP key ID: least significant 64 bits of the public key unique within a user with very high probability

PGP / key and trust management

Random number generation

true random numbers
PGP / key and trust management

used to generate public key private key pairs provide the initial seed for the pseudorandom number generator (PRNG) provide additional input during pseudorandom number generation

pseudo-random numbers
used to generate session keys and IVs

True random numbers

PGP maintains a 256-byte buffer of random bits each time PGP expects a keystroke from the user, it records the time when it starts waiting (32 bits) the time when the key was pressed (32 bits) the value of the key stroke (8 bits) the recorded information is used to generate a key the generated key is used to encrypt the current value of the random-bit buffer

PGP / key and trust management

Pseudo-random numbers
based on the ANSI X9.17 PRNG standard K1, K2

PGP / key and trust management

DTi

3DES

3DES

Vi+1

Vi

3DES

Ri

Pseudo-random numbers
dtbuf

+ rseed +

E
+

E
+

rseed

PGP / key and trust management

E
+

E
+

+
true random bits

IV[0..7]

K[8..15]

K[0..7]

CAST-128 is used instead of 3DES with key rkey

Pseudo-random numbers
dtbuf[0..3] = current time, dtbuf[4..7] = 0 pre-wash take the hash of the message this has already been generated if the message is being signed otherwise the first 4K of the message is hashed use the result as a key, use a null IV, and encrypt (rkey, rseed)previous in CFB mode if (rkey, rseed)previous is empty, it is filled up with true random bits set (rkey, rseed)current to the result of the encryption post-wash generate 24 more bytes as before but without XORing in true random bytes encrypt the result in CFB mode using K and IV set (rkey, rseed)previous to the result of the encryption

PGP / key and trust management

Private-key ring
used to store the public key private key pairs owned by a given user essentially a table, where each row contains the following entries: timestamp key ID (indexed) public key encrypted private key private key user ID (indexed)
passphrase

PGP / key and trust management

hash

enc
encrypted private key

Public-key ring
used to store public keys of other users a table, where each row contains the following entries: timestamp key ID (indexed) public key user ID (indexed) owner trust signature(s) signature trust(s) key legitimacy

PGP / key and trust management

Trust management
owner trust assigned by the user possible values: unknown user usually not trusted to sign usually trusted to sign always trusted to sign ultimately trusted (own key, present in private key ring) signature trust assigned by the PGP system if the corresponding public key is already in the publickey ring, then its owner trust entry is copied into signature trust otherwise, signature trust is set to unknown user

PGP / key and trust management

Trust management
key legitimacy computed by the PGP system if at least one signature trust is ultimate, then the key legitimacy is 1 (complete) otherwise, a weighted sum of the signature trust values is computed always trusted signatures has a weight of 1/X usually trusted signatures has a weight of 1/Y X, Y are user-configurable parameters example: X=2, Y=4 1 ultimately trusted, or 2 always trusted, or 1 always trusted and 2 usually trusted, or 4 usually trusted signatures are needed to obtain full legitimacy

PGP / key and trust management

Example key legitimacy

X = 1, Y = 2 G B

C H

PGP / key and trust management

user F

A E

untrusted / usually untrusted usually trusted always trusted ultimately trusted (you) signature

L
J M

legitimate

Public-key revocation
why to revoke a public key? suspected to be compromised (private key got known by someone) re-keying the owner issues a revocation certificate has a similar format to normal public-key certificates contains the public key to be revoked signed with the corresponding private key and disseminates it as widely and quickly as possible if a key is compromised: e.g., Bob knows the private key of Alice Bob can issue a revocation certificate to revoke the public key of Alice even better for Alice

PGP / key and trust management

What is S/MIME?
Secure / Multipurpose Internet Mail Extension a security enhancement to MIME provides similar services to PGP based on technology from RSA Security industry standard for commercial and organizational use RFC 2630, 2632, 2633

RFC 822
defines a format for text messages to be sent using email Internet standard structure of RFC 822 compliant messages header lines (e.g., from: , to: , cc: ) blank line body (the text to be sent) example
S/MIME / introduction

Date: Tue, 16 Jan 1998 10:37:17 (EST) From: abc <abc@wce.ac.in> Subject: Test To: bvs@bvbs.ac.in Blablabla

Problems with RFC 822 and SMTP

executable files must be converted into ASCII various schemes exist (e.g., Unix UUencode) a standard is needed text data that includes special characters (e.g., Hungarian text) some servers reject messages over a certain size delete, add, or reorder CR and LF characters truncate or wrap lines longer than 76 characters remove trailing white space (tabs and spaces) pad lines in a message to the same length convert tab characters into multiple spaces

S/MIME / introduction

MIME
defines new message header fields defines a number of content formats (standardizing representation of multimedia contents) defines transfer encodings that protects the content from alteration by the mail system

S/MIME / introduction

MIME - New header fields

MIME-Version Content-Type describes the data contained in the body receiving agent can pick an appropriate method to represent the content Content-Transfer-Encoding indicates the type of the transformation that has been used to represent the body of the message Content-ID Content-Description description of the object in the body of the message useful when content is not readable (e.g., audio data)

S/MIME / introduction

MIME Content types and subtypes

text/plain, text/enriched image/jpeg, image/gif video/mpeg audio/basic application/postscript, application/octet-stream multipart/mixed, multipart/parallel, multipart/alternative, multipart/digest (each part is message/rfc822) message/rfc822, message/partial, message/external-body

S/MIME / introduction

MIME Transfer encodings

7bit short lines of ASCII characters 8bit short lines of non-ASCII characters binary non-ASCII characters lines are not necessarily short quoted-printable non-ASCII characters are converted into hexa numbers (e.g., =EF) base64 (radix 64) 3 8-bit blocks into 4 6-bit blocks x-token non-standard encoding

S/MIME / introduction

MIME Example
MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@nsb.fv.com> To: Ned Freed <ned@innosoft.com> Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 Content-type: text/plain; charset=US-ASCII Some text --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2

S/MIME / introduction

--unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... base64-encoded image data goes here ... --unique-boundary-2--

MIME Example contd

--unique-boundary-1 Content-type: text/enriched This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller> Isnt it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Additional text in ISO-8859-1 goes here ... --unique-boundary-1--

S/MIME / introduction

S/MIME services
enveloped data (application/pkcs7-mime; smime-type = enveloped-data) standard digital envelop signed data (application/pkcs7-mime; smime-type = signed-data) standard digital signature (hash and sign) content + signature is encoded using base64 encoding clear-signed data (multipart/signed) standard digital signature only the signature is encoded using base64 recipient without S/MIME capability can read the message but cannot verify the signature signed and enveloped data signed and encrypted entities may be nested in any order

S/MIME / services

Cryptographic algorithms
message digest must: SHA-1 should (receiver): MD5 (backward compatibility) digital signature must: DSS should: RSA asymmetric-key encryption must: ElGamal should: RSA symmetric-key encryption sender: should: 3DES, RC2/40 receiver: must: 3DES should: RC2/40

S/MIME / services

Securing a MIME entity

MIME entity is prepared according to the normal rules for MIME message preparation prepared MIME entity is processed by S/MIME to produce a PKCS object the PKCS object is treated as message content and wrapped in MIME

S/MIME / services

PKCS7 signed data

Version (Set of) Digest Algorithms

Content type

Content Info

Content

S/MIME / message formats

Set of certificates Version Set of CRLs Signer ID (issuer and ser. no.) Digest Algorithm Signer Info Authenticated Attributes Digest Encryption Alg. Encrypted digest (signature)

PKCS7 enveloped data

Version Originator Info Recipient Info Version Recipient ID (issuer and s.no.) Key Encryption Algorithm Encrypted Key

S/MIME / message formats

Encrypted Content Info

Content type Content Encryption Alg.

Encrypted Content

Enveloped data Example

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

S/MIME / message formats

Clear-signed data Example

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42
--boundary42 Content-Type: text/plain

This is a clear-signed message.

--boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756

S/MIME / message formats

--boundary42--

Key management
S/MIME certificates are X.509 conformant key management scheme is between strict certification hierarchy and PGPs web of trust certificates are signed by certification authorities (CA) key authentication is based on chain of certificates users/managers are responsible to configure their clients with a list of trusted root keys
S/MIME / key management