How is trust revoked on pkc

[freedge]

hello! thanks for this tool.

I would like to know if there is a way to improve it to validate that the key was not generated on (or transited through) a known vulnerable HSM that leak keys (I also asked the question on https://github.com/orgs/pkic/discussions/32). A pkc for a key generated on a vulnerable HSM still validates OK with this tool.

[freedge]

I have some side questions / remarks

openjdk provided on centos stream has restrictions on the ecc curves it supports, so it's not possible to validate for example, a certificate for a X9_62_c2tnb431r1 curve. So it would be great to provide an official container image for the validator. Personally I built one with

FROM maven:3-openjdk-18-slim AS build
WORKDIR /luna

RUN curl -L https://github.com/ThalesGroup/luna-pkc-validator/archive/refs/heads/main.tar.gz | tar -zxv -f - --strip-components 1
RUN /usr/bin/mvn compile assembly:single
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/ecc-pkc.p7b  --ca tests/luna-ecc-root-certificate.pem
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/rsa-pkc.p7b  --ca tests/luna-rsa-root-certificate.pem
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/ecc-pkc.p7b  --req luna-pkc-validator/tests/ecc-test.csr
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/rsa-pkc.p7b  --req luna-pkc-validator/tests/rsa-test.csr

FROM openjdk:11-jre-slim
COPY --from=build luna/target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar /validator.jar
COPY --from=build luna/tests/luna-ecc-root-certificate.pem /ecc.pem
COPY --from=build luna/tests/luna-rsa-root-certificate.pem /rsa.pem
ENTRYPOINT ["java", "-jar", "/validator.jar" ]

that can be used to validate any curve without the limitations imposed by Red Hat.

another thing a pkc generated on dpod will fail validation with "Error: Root CA verification failed. Fingerprint does not match." with the provided root ca cert as luna-pkc-validator compares the cert fingerprints and not only the modulus values which stay the same.

also I notice the pkc contains a couple of extensions like "1.3.6.1.4.1.12383.2.3" (which looks like it could provide a firmware version). Is it possible to parse this, and could this be used to reject certificates created with older unsafe versions? (or are keys kept during firmware upgrade, so the pkc is in the end, offers no guarantee of non-extractability for ecc keys).

a last question regarding those X509 extensions, is it possible to know if a key has an associated CKA_UNWRAP_TEMPLATE and its content? I'd like to give users a public RSA key and prove that it can be used to safely import AES secrets that will not be extractable.

[Raj192628]

hello! thanks for this tool.

I would like to know if there is a way to improve it to validate that the key was not generated on (or transited through) a known vulnerable HSM that leak keys (I also asked the question on https://github.com/orgs/pkic/discussions/32). A pkc for a key generated on a vulnerable HSM still validates OK with this tool.

The tool purpose is to validate the pkc chain. It is end user responsibility to update the vulnerable firmware on the HSM.

[Raj192628]

I have some side questions / remarks

openjdk provided on centos stream has restrictions on the ecc curves it supports, so it's not possible to validate for example, a certificate for a X9_62_c2tnb431r1 curve. So it would be great to provide an official container image for the validator. Personally I built one with

FROM maven:3-openjdk-18-slim AS build
WORKDIR /luna

RUN curl -L https://github.com/ThalesGroup/luna-pkc-validator/archive/refs/heads/main.tar.gz | tar -zxv -f - --strip-components 1
RUN /usr/bin/mvn compile assembly:single
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/ecc-pkc.p7b  --ca tests/luna-ecc-root-certificate.pem
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/rsa-pkc.p7b  --ca tests/luna-rsa-root-certificate.pem
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/ecc-pkc.p7b  --req luna-pkc-validator/tests/ecc-test.csr
RUN java -jar target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar --pkc tests/rsa-pkc.p7b  --req luna-pkc-validator/tests/rsa-test.csr

FROM openjdk:11-jre-slim
COPY --from=build luna/target/luna-pkc-validator-1.0.0-jar-with-dependencies.jar /validator.jar
COPY --from=build luna/tests/luna-ecc-root-certificate.pem /ecc.pem
COPY --from=build luna/tests/luna-rsa-root-certificate.pem /rsa.pem
ENTRYPOINT ["java", "-jar", "/validator.jar" ]

that can be used to validate any curve without the limitations imposed by Red Hat.

another thing a pkc generated on dpod will fail validation with "Error: Root CA verification failed. Fingerprint does not match." with the provided root ca cert as luna-pkc-validator compares the cert fingerprints and not only the modulus values which stay the same.

also I notice the pkc contains a couple of extensions like "1.3.6.1.4.1.12383.2.3" (which looks like it could provide a firmware version). Is it possible to parse this, and could this be used to reject certificates created with older unsafe versions? (or are keys kept during firmware upgrade, so the pkc is in the end, offers no guarantee of non-extractability for ecc keys).

a last question regarding those X509 extensions, is it possible to know if a key has an associated CKA_UNWRAP_TEMPLATE and its content? I'd like to give users a public RSA key and prove that it can be used to safely import AES secrets that will not be extractable.

DPOD is using the same public/private key pair but signed with SHA384 and tool is validating the Message Digest of certificate as a result it is failing .
It is possible to get the firmware version from the extensions. However it is end user responsibility to update the vulnerable firmware version.
Currently pkc chain does not have keypair attributes.

[freedge]

hello,

The tool purpose is to validate the pkc chain. It is end user responsibility to update the vulnerable firmware on the HSM.

that's understood however the tool goal is to achieve what is described here: https://thalesdocs.com/gphsm/luna/7/docs/network/Content/admin_partition/confirm/confirm_hsm.htm

the client needs a way to verify the authenticity of the device protecting their most valued cryptographic keys.
A Luna HSM will issue confirmations only for private keys that were created by a Luna cryptographic module and that can never exist outside the security perimeter of a Luna HSM.

the tool does not help with this since a valid pkc chain does not prove that the private key is reliable. To achieve this goal the tool needs to also have a way to revoke certificate for HSM that cannot be trusted.