olivier-heurtier-sia commented 2 years ago

Work in progress...

olivier-heurtier-sia commented 1 year ago

The initial proposition included in this PR relied on specific fields added to describe encryption keys, algorithms, etc.

This comment is to propose to rely on existing standards for signature and encryption to be more interoperable and reduce development costs.

Needs

The need is to secure the biometric data (and the document data) attached buffer by enforcing:

the integrity of one piece of data, preventing changes and being able to validate who/what created the data.
the confidentiality of one piece of data, preventing entities with no permission from accessing the data.
the global integrity of the list of biometrics (resp. documents), preventing inversion or replacements.

2 alternatives are proposed:

Rely on JWT-related standards (namely, RFC7515 and RFC7516) and extend the existing JSON schema to include elements from JSON Web Signature (JWS) and JSON Web Encryption (JWE) structures.
Rely on PKCS#7 format (RFC5652) (See also https://en.wikipedia.org/wiki/PKCS_7)

Solutions

For signing and encrypting with JWT

It is proposed to rely on the following RFC:

RFC7515: JSON Web Signature
RFC7516: JSON Web Encryption

When an image/document is signed:

the image (or document) buffer is used as the payload for the generation of a jws
the image (or document) buffer is unchanged
the jws information (signature, algo, etc.) is added to the biometricData (or documentData) element without the payload

When an image/document is encrypted:

the image (or document) buffer is used as the payload for the generation of a jwe
the resulting encrypted data (cypher text) is replacing the buffer
the jwe information (iv, tag, encrypted keys, etc.) is added to the biometricData (or documentData) element without the payload

When an image/document is both signed and encrypted:

first the signature is applied
then the encryption is done

This is in application of best practices (see https://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign)

The jws and jwe tags are optional.

Any type of algorithm, headers, keys, etc. is supported as long as it is compliant with RFC 7515 and RFC 7516.

Examples:

Not signed, not encrypted:

{
    "biometricType": "FINGER",
    "biometricSubType": "RIGHT_INDEX",
    "instance": "INST0",
    "image": "IMAGE OF RIGHT INDEX",
    "captureDate": "2019-05-21T12:00:00Z",
    "impressionType": "LIVE_SCAN_PLAIN",
    "mimeType": "image/jpeg",
    "resolution": 500
}

Signed, not encrypted:

{
    "biometricType": "FINGER",
    "biometricSubType": "RIGHT_INDEX",
    "instance": "INST0",
    "image": "IMAGE OF RIGHT INDEX",
    "captureDate": "2019-05-21T12:00:00Z",
    "impressionType": "LIVE_SCAN_PLAIN",
    "mimeType": "image/jpeg",
    "resolution": 500,
    "jws": {
        "signature": "HpO3qVCPs_zrDuEUd7Aq6WHB4N0cm2c_ZFKJvM6bUNc",
        "header": {
            "alg": "HS256",
            "kid": "e9bc097a-ce51-4036-9562-d2ade882db0d"
        }
    },
    "comment": "Signature is included"
}

Signed and encrypted:

{
    "biometricType": "FINGER",
    "biometricSubType": "RIGHT_INDEX",
    "instance": "INST0",
    "image": "GDDyTwFQW3HKCbp_9cZHxOrPPf0",
    "captureDate": "2019-05-21T12:00:00Z",
    "impressionType": "LIVE_SCAN_PLAIN",
    "mimeType": "image/jpeg",
    "resolution": 500,
    "jws": {
        "signature": "HpO3qVCPs_zrDuEUd7Aq6WHB4N0cm2c_ZFKJvM6bUNc",
        "header": {
            "alg": "HS256",
            "kid": "e9bc097a-ce51-4036-9562-d2ade882db0d"
        }
    },
    "comment": "Signature is included and image buffer is encrypted",
    "jwe": {
        "protected": "eyJlbmMiOiJBMTI4R0NNIn0",
        "iv": "oSGO2IApCFxWQPcz",
        "tag": "F6wmPYo1LYv3fr6W1ym37Q",
        "recipients": [
            {
                "header": {
                    "alg": "A128KW"
                },
                "encrypted_key": "AcfBOeqibaCpxIUNMQXN9IwSWeePvoOv"
            }
        ]
    }
}

For signing and encrypting with PKCS#7

It is proposed to rely on the following RFC:

RFC5652: Cryptographic Message Syntax (CMS)

The buffer attached to the biometricData (resp. documentData) is replaced with a PKCS#7 containing the signature and encryption elements, plus the encrypted image buffer itself.

There is no change to the JSON schema of OSIA and the buffer can be validated and encrypted independently from the other data contained in the OSIA JSON.

For storage efficiency, the DER format should be preferred over PEM.

Global Integrity

For the global integrity of a list of biometric/document data, it is proposed to add a structure with a signature of all hashes.

With JWT: a JWS is generated on the hash of all the elements in the list, and then added to the OSIA JSON.
With PKCS#7: a "signed data" is generated on the hash of all the elements in the list, and then added to the OSIA JSON.

For both options, the OSIA JSON schema must be adapted:

Example:

"biometricData": [
    {
        "biometricType": "FINGER",
        "biometricSubType": "RIGHT_INDEX",
        "instance": "INST0",
        "image": "IMAGE OF RIGHT INDEX",
        "captureDate": "2019-05-21T12:00:00Z",
        "impressionType": "LIVE_SCAN_PLAIN",
        "mimeType": "image/jpeg",
        "resolution": 500
    }
]
"biometricDataSecurity" : {
    "hashAlgorithm": "SHA256",
    "hashValues": [
      "8c65ef25b84f57dd8a5278934f8e3842309cef7f77950cf2011ea131a1f2e207"
    ],
    -- JWS --
    "jws": {
        "signature": "MDP-H_ULgIKk06vfBHrCJb-AHoGUdZBQalAFsXffHYE",
        "header": {
            "alg": "HS256",
            "kid": "e9bc097a-ce51-4036-9562-d2ade882db0d"
        }
    }
    -- OR PKCS#7 --
    "signedData": "PEM"
}

Open to discussion

Only buffers (image, PDF, etc.) are considered here. Should we include, at least for the integrity, also the other information contained in the json. Ex: include biometricSubType in the signature to prevent finger inversion?

wberges commented 3 months ago

Only buffers (image, PDF, etc.) are considered here. Should we include, at least for the integrity, also the other information contained in the json. Ex: include biometricSubType in the signature to prevent finger inversion?

Regarding the data used to calculate the signature, perhaps we could give the list of fields used to build it so that it is more flexible and generic? Or simply why not signing the whole JSON content to insure the global integrity? For example, I could bypass the security by simulating a missing finger by adding it to the "missing" fields and removing the corresponding (encrypted&|signed) image. No? :)

olivier-heurtier-sia commented 1 week ago

See also PR#79 for the topic of confidentiality and integrity

SecureIdentityAlliance / osia