Thanks to recent help I am now able to sign data from SCSH using a Nitrokey setup with n-of-m authentication.
For the final product though, I need to be able to authenticate users remotely. The “n” users could all be in separate physical locations and i need them to be able to connect to a machine with the Nitrokey which will then sign many files. I have seen that OpenCard Framework can be used in such a scenario with a suitably setup server but I have been unable to find the right documentation to get going.
Any help or pointers to documentation would be gratefully received!
Thanks,
Doug
Edit szszsz: linking mentioned for the future reference:
The sc-hsm-management-server repository in the CDN is probably what you are looking for. That is a service to which HSMs can connect remotely for cryptographic operations and to perform public key authentication.
The same mechanism is used in the PKI-as-a-Service Portal to authenticate CA operators to activate the trustcenter HSM using n-of-m.
I must admit I always felt there is something missing in my attempts to set up the scripting server and this might be it… Is it the component providing the “/rt” endpoint?
> ssh -p 222 git@devnet.cardcontact.de
PTY allocation request failed on channel 0
hello cardcontact@saper.info, this is git@cc-devnet running gitolite3 3.6.12-1 (Debian) on git 2.30.2
R ocf
R ocf-web
R pki-as-a-service
R sc-hsm-android-client
R sc-hsm-android-example
R sc-hsm-android-library
R sc-hsm-jceprovider
R sc-hsm-pgp
R sc-hsm-sdk-scripts
R scdp4j
R scriptingserver
R scsh-mods
R scsh3
Connection to devnet.cardcontact.de closed.
> git clone ssh://git@devnet.cardcontact.de:222/sc-hsm-management-server
Cloning into 'sc-hsm-management-server'...
FATAL: R any sc-hsm-management-server cardcontact@saper.info DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Sorry, the access condition for the repo was wrong. Please try again.
The sc-hsm-management-server is more a PoC than an actual production component. The implementation in the PKI-as-a-Service is similar, but not identical.
The /rt endpoint is part of the scriptingserver, but you need to have some implementation behind that. The sc-hsm-management-server does that with an instance of the scsh/srv-cc1/HSMService module. The PKI-as-a-Service has it’s own HSMService module, as it allows to authenticate towards the HSM in the subject view.
In the long run we plan to rewrite the HSMService in Java and make it available as part of the OCF/JCEProvider stack. That way n-of-m could be used from within Java server applications.
That’s probably because we don’t provision in the old way using a crypto middleware, but have a bootstrap PKI for device authentication and key attestation. All those mechanisms don’t have adequate support in CSP or PKCS#11.
Just open a new thread and I’m happy to provide the details
Does the remote authorisation and signing have to all happen within Smart Card Shell?
We have a process where we want to sign lots of pieces of data - obviously we would only want to authorise once and then run the signing. I’m not clear how i can communicate with an outside process to fetch the file, sign the file, then return the signature generated.
That is just a matter of integrating your code with some middleware.
The native interface supported by the SmartCard-HSM / Nitrokey HSM is using ISO 7816-4 APDUs. That is a fairly simple command / response pattern that you exchange with the HSM. The HSM has an internal data model that consists of key objects, files and authentication objects. APDUs act on those objects and allow to uses them in (cryptographic) operations.
The middleware (OpenSCDP, OpenSC, sc-hsm-embedded, OCF, JCE-Provider) is just a convenience layer on top of the APDU layer. It maps the low-level functions and data model to generic APIs like PKCS#11, MS-CSP or Java JCA/JCE. When you perform actions in the Smart Card Shell, you can see the APDUs in the trace tab.
Unfortunately not all low-level mechanisms have a corresponding mechanism in the higher abstraction layer (like n-of-m for example). That is why sometimes you need proprietary integration to get that working. But ultimately you can always integrate on the APDU layer, the only thing you need is the user manual that describes the APDU interface and PC/SC access in your favorite programming environment.
Of course we are happy to help with custom integration, that is the business model for the open source modules we provide.
We are using mkimage to sign a kernel image for uboot FIT images.
I think we have to modify mkimage so that it can work with the Nitrokey when we have authorised it using n-of-m shared authorisation.
If you know an existing open solution, or commercial solution or if you can provide the help needed (at least the external tool integration part) then we would be happy to consider any option.
one option would be to integrate a RAMOverHTTP connection to the sc-hsm-management-server are part of the C_Login processing in the PKCS#11 module. That call would cause the module to connect to a predefined URL at which the sc-hsm-management-server allows n-of-m authentication. Once authentication is complete, the server releases the connection and C_Login would return to the calling application. Any PKCS#11 operation that requires authentication could then be performed, for example using mkimage.
Please write a personal message and I’ll prepare a quote to get that developed.
Hey man - quick question, could you point me towards the best resources on RA plz?
I’m not as concerned witht the authentication process - rather, remote attestation using PUF-Based OSS Cards.
I don’t understand what you are looking for. What do you mean by “PUF-Based OSS Cards” ?
Remote authentication and key attestation are different mechanisms. While remote authentication is a cryptographic challenge-response protocol to remotely enable access to keys in a device, key attestation provides a relying party with proof, that a key was actually generate an a specific device.
In a SmartCard-HSM / Nitrokey-HSM remote authentication is based on public key authentication using an ECDSA key on the key custodians device. Of course that public key is subject to key attestation (like all other asymmetric keys) and the key attestation is used during registration of the public key in the target device for PKA.
But maybe not in this thread, thank you!