Raw and XML digital signature and encryption Flashcards
Generics about PKCS#7 and CSM formats
PKCS#7 and CMS are both standards related to cryptographic signed and encrypted messages.
PKCS#7 is the RSA standard for secure envelope and CMS (Cryptographic Message Syntax) is the evolution of PKCS#7 in the IETF context.
They provide data integrity, data authentication and/or privacy with symmetric or asymmetric algorithms.
They both allow parallel and sequential signatures.
They are based on ANS.1-BER.
CMS algortihms
Base algorithms:
* digest: MD5, SHA1
* MAC: HMAC-SHA1
* signature: RSA, DSA
* key management: DH (agreement), RSA (transport)
* encryption: 3-DES-CBC
CMS external structure
A CMS document consists of a ContentInfo which is made of the ContentType field and of the Content field.
CMS: contentType options
- data: encodign of a generic sequence of bytes with Basic Encoding
- signedData: the document contains the data to be signed and 1-N parallel digital signatures
- envelopedData: the document contains encrypted data; they are encrypted using symmetric cryptography and the symmetric key is encrypted with 1-N public keys belonging to the wanted recipients. Here the goal is to choose who can decrypt the content.
- authenticatedData: the document contains the data, digest of the data and the symmetric key is encrypted with 1-N public keys belonging to the receivers. Here the goal is to choose who can verify the digest.
- encryptedData: data are just encrypted with a symmetric algorithm and the key is managed outside CSM scope
- digestData: it’s an unprotected format (since it contains just a digest) but it could be enveloped inside another
(protected) format since CMS has a recursive structure
CMS: signedData contentType
If contentType = signedData then the Content is made of:
* version
* digestAlgorithmS: each signer may have chosen a different digest algorithm
* encapContentInfo: information reguarding the content
* [certificates]: either single certificate or chain; to verify the signatures of each signer
* [crls]
* 1-N signerInfo: version, issuer + SN, encryptedDigest (digest computed over the data and encrypted with the private key of the signer)
The more infos it contains the more it becomes a self-contained signed docuement.
CMS: envelopedData contentType
If contentType = envelopedData then the Content is made of:
* version
* encryptedContentInfo: contentType + encryptionAlgorithm (to encrypt data) + encryptedContent
* 1-N recipientInfo: version + issuer + SN + encAlgorithm (for the key) + encKey
XML signature generics
XML signature is used to protect XML data with either a digital signature or a MAC.
A XML signature provides data authN, data integrity and, if the signature is performed with asymmetric cryptography and associated to a X.509 certificate, non-repudiation.
XML signature provides the definition of the signature format and of the procedures to create and verify the signature.
The signed objecct may be internal to the document or external and referenced by an URI.
It can be a XML native-object or a non-XML object.
XML signature offers different signature levels:
- signed
- co-signed: many actors sign the same document
- witnessed: counter signature made by someone that testifies that he witnessed the document creation and signing processes
- notarized: a notary is a public officer who has the obligation to verify the identity of the signers and to check if they signed with free will
It is independent from the transport and from the storage technique.
xmldsig namespace and DTD
An XML document contains the Document Type Definition which describes the schema of the identifiers used to identify the elements the document is made of.
The <!DOCTYPE …> contains this informations and also allows to define abbreviations.
XML signature types
- enveloping signature: the XML signature OBJECT embeds the XML object to be signed inside it
- enveloped signature: the XML original document contains the XML signature (if there is enough space)
- detached signature: the XML document and signature are separated and linked by means of a two-ways-pointer
XML canonicalization
There are cases in which two XML documents have the same logical meaning but have different representations.
XML allows to canonicalize a document in order to have the same signature value.
Characteristics of a canonical XML document:
* UTF-8 encoding
* line breaks are normalized to #xA
* each reference is replaced with the corresponding content
* attribute values are enclosed within double quotes
* XML declaration and DTD are removed -> ATTACK POINT
* empty elements are converted to start-end tag pairs
* white spaces inside tags or outisde the document are normalized
* attribute values delimiters are set to quotation marks
* superflous namespaces are removed
* default attributes are added to each element
Structure of XML signature
-> foglio
XML reference type
A reference may point to:
- object: generic
- SignatureProperty: a signature attribute
- Manifest: set of references
XML manifest
It is a list of Reference elements that are external to SignedInfo but pointed by SignedInfo.
Any Reference in the Manifest is not individually validated (≠ from References in SignedInfo) because the procedure considers the Manifest as a whole.
The validation of manifest’s references is left to the application.
XML security requirements
- confidentiality: no! only achieved by using TLS and/or XML encryption
- data authN and integrity + creator authN
- but not sender/receiver authN
=> better to use a nonce (timestamp) to do not allow to declare to have received a message multiple times + include info about the intended receiver (none can say they have received the message if they are not supposed to)
XML encryption characteristics
It allows to encrypt different parts of a document and this is not possible with PKCS#7 or CMS encryption.
It is possible to encrypt:
- single XML element with tags included
- content of a single XML element with tags excluded
- a whole XML document
- and EncryptedData or EncryptedKey element -> super-encryption
It is not compulsory to specify the encryption algorithm and the encryption key (could be agreed OOB).
