ISO IEC 19785-4:2010 pdf – lnformation technology -CommonBiometric Exchange Formats Framework — Part 4: Security block format specifications
ISO IEC 19785-4:2010 pdf – lnformation technology -CommonBiometric Exchange Formats Framework — Part 4: Security block format specifications.
c) The field recipientlnfos of type Recipientlnfos is a collection of per-recipient information. There shall be at least one element in the collection. The type Recipientlnfos is SET of Recipientlnfo. For details of type Recipientlnfo, see RFC 3852 and RFC 5911.
d) The field contentEncryptionAlgorithm identifies the content-encryption algorithm, and any associated parameters, used to encrypt the biometric data. The same content-encryption algorithm and content- encryption key are used for all recipients.
220.127.116.11 encryptionRelatedData content type
18.104.22.168.1 The encryptionRelatedData content type associates an object identifier
id-encryptionRelatedData with an ASN.1 type EncryptionRelatedData as described in 22.214.171.124.
a) Unlike the envelopeRelatedoata content type, the encryptionRelatedData content type has neither recipients nor encrypted content-encryption keys. Keys shall be managed by other means.
NOTE The typical application of the encrypt ionRelatedData content type will be to encrypt the biometric data for local storage, where the encryption key is derived from a password.
b) Type EncryptionRelatedData is defined as follows:
EncryptionRelatedData ::- SEQUENCE (
version CBEFFSBVerBi0n DEFAULT vO,
If CBEFF_BIR_integrity_options in the SBH is present and contains the encoding for INTEGRITY, the security block shall contain a component of type ContentInfoCBEFFSB, the value of whose first component is id-signatureRelatedData or id-authenticationRelatedData. As seen in the definition of ContentInfoCBEFFSB, the type of its second component is determined by the value of the first component, i.e., SignatureRelatedData is taken for id-sig-natureRelatedData, and AuthenticationRelatedData for id-authenticationRelatedData. When a digital signature is used to ensure integrity, the signatureRelatedData content type is used. When a MAC is used, the authenticationRelatedData content type is used. The digital signature or MAC is calculated on the concatenation of the SBH and the (possibly encrypted) BDB encodings.
126.96.36.199 signatureRelatedData content type
188.8.131.52.1 The signatureRelatedData content type associates an object identifier
id-signatureRelatedData with an ASN.1 type signatureRelatedData as described in 184.108.40.206.
a) The type SignatureRelatedData consists of one or more signature values. Any number of signers in parallel can sign the concatenation of the SBH and (possibly encrypted) BDB encodings. Unlike the signedData content type defined in RFC 3852 and RFC 5911, this content type does not contain the data that is being digitally signed.
b) The process by which SignatureRelatedData is constructed involves the following steps, which is illustrated as the left half of Figure 1:
1) For each signer, a message digest, or hash value, is computed on the concatenation of the SBH and (possibly encrypted) BDB encodings with a signer-specific message-digest algorithm (DA in Figure 1), and the result becomes the message digest (MD in Figure 1).
2) For each signer, the message digest is digitally signed using the signer’s private key (PrK in Figure 1) with a signer-specific signature algorithm (SA in Figure 1).
3) For each signer, the signature value (DS in Figure 1) and other signer-specific information are collected into a signerlnfo value, which is defined in RFC 3852 and RFC 5911. Certificates and CRLs for each signer, and those not corresponding to any signer, are collected in this step.
4) The message digest algorithms for all the signers and the signerlnfo values for all the signers are collected together into a signatureRe1ateaata value.
c) The process by which SignatureRelatedData is verified involves the following steps, which are illustrated as the right half of Figure 1. A recipient independently computes the message digest (MD’ in Figure 1) of the concatenation of the SBH and (possibly encrypted) BDB encodings with the signer-specific message-digest algorithm (DA in Figure 1). This message digest and the signer’s public key (PbK in Figure 1) are used to verify the signature value (DS in Figure 1) comparing the message digest calculated by the verifier (MD’ in Figure 1) and the message digest calculated by the signer (MD in Figure 1), which is decrypted from the digital signature (DS in Figure 1) using the signer’s public key (PbK in Figure 1) with the signer-specific signature algorithm (DS in Figure 1). The signer’s public key is referenced either by an issuer distinguished name along with an issuer-specific serial number or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer’s certificate can be included in the field certificates in the Signature Related Data.