SCP R-MAC/ENC support

[easydaniel]

I'm recently working on a project that requires attestation of generated keypair public key. Would like to know what is the reason not having R-MAC/ENC supported. Though I do see in documentation said it's not enforced, I wonder if this is simply reusing existing GP libraries. Which would be something looking like:

// STEP 1 - Generate the key pair
  PIVKeyObjectPKI keyPair = (PIVKeyObjectPKI) key;
  short length = keyPair.generate(scratch, ZERO);

// Added wrapping
  SecureChannel sc = GPSystem.getSecureChannel();
  byte mask = SecureChannel.AUTHENTICATED | SecureChannel.R_ENCRYPTION | SecureChannel.R_MAC;
  if ((sc.getSecurityLevel() & mask) == mask) {
    length = sc.wrap(scratch, ZERO, length);
  }

I tried this customizing code snippet but the R-MAC value is not correct when receiving the response from the applet. Any suggestion making this work? I can help sending out MRs to get this supported.

Also though PIV spec doesn't specify the authenticity of the key generated, is there a recommended security scheme that how we can generate an signature from the applet as an option when generating keypair? Thanks

[makinako]

Hi @easydaniel, apologies on the delay for this. The reasons for not implementing R_ENC/R_MAC were more about dealing with the implementation of command/response handling in the applet and less to do with sound arguments of security. Since administrative commands were traditionally sent over plaintext with the 9B key, it was seen as sufficient to improve this by ensuring the command payload was protected, especially for key injection.

The responses are largely just acknowedgements, with the notable exception of GEN ASYM KEYPAIR which is just returning public modulus. Having said this, attestation is a great case for protecting the response integrity, and also given the use of SCP03 for network-based updates, protecting even just acknowledgements is a good idea.

It's been a while since I looked at implementing R_ENC/R_MAC, but I'll have a closer look in the next couple of weeks and in the meantime if you find a workable solution, make a PR for sure.

[makinako]

Updating as implemented in v2-0-0-fips with some caveats:
R-MAC and R-ENC are both supported, but only for single-frame responses. This is good for all administrative command scenarios that simply acknowledge, with the exception of GENERATE ASYMMETRIC KEYPAIR with RSA keys.

I haven't spent a huge amount of time dealing with R-ENC/R-MAC, but it appears that the GP SecureChannel.wrap() method expects you to wrap the entire payload rather than wrapping each frame in a chained response. This brings up issues with larger objects like certs. I can/will probably hack around it to support the GEN KEYPAIR response as it is in RAM, but supporting it universally (GET DATA in particular) is problematic in the current PIVAPDU implement.

One comment I would make is that for verification of the received public key, a suitable approach would be to do a proof-of-posession of the private key by issuing a challenge and verifying the response against the received public key, which provides assurance of both. This doesn't help in remote-issuance scenarios where a network attack against the R-APDU is as good against this as it is against the originally received public modulus, but as a local mechanism for testing something like the read cert against the card's private key before honouring it for attestation it should be enough.

I'll keep this open until I have patched the applet to work for all scenarios except GET DATA, which I think will be "good enough" for most cases.

[easydaniel]

Yep, thanks for the response. And its reasonable to do challenge but it's just not fitting our use-case. For larger chained responses, I recalled (sorry it's been a while) but GP api is able to do chaining (not wrapping entire payload once but it'll handle the scp session with counter states from both ends).

[suut]

So it turns out the implementation of R-MAC/R-ENC in v2-0-0-fips also works for long responses with chaining (generating asymmetric key pairs), but then you need to use a custom SCP-03 implementation that will process each response independently instead of concatenating all the responses until the last 9000 status

Here is a sample implementation that will work with v2.0.0, set chaining_quirk=True when constructing SCP03: https://gist.github.com/suut/d751aa9e807b4fe0bd7ca127c5ad6e21