Re: [Globalplatform-developers] scp03 with encryption

[Karsten O. <wid...@t-...>]

Hi Klas,


I have applied your patch. I have also added you to the AUTHORS file if
you don't mind.

Thanks for the other patches. I will continue with the other patches later.


Another approach would be to add you as a developer and you can work in
your own branch, before I merge it into the master trunk.  But patches
are also fine.


Karsten

Am 22.08.2019 um 16:09 schrieb Klas Lindfors via Globalplatform-developers:
> Hey,
>
> I have a couple more small patches for more scp03 support. If you want
> to I can re-send the earlier large patch as broken up patches for each
> specific thing.
>
> These are as follow:
> scp03-fix-enc-iv.patch zeroes the IV before encrypting the counter
> (this could just ues ECB instead since it's one block)
> scp03-implement-get-key-data.patch implement scp03 parts in
> get_key_data_field()
> put-key-double-length.patch changes the template for put key to have
> double lengths, as I understand the specification the length should be
> duplicated, once for the key component block and once for the key
> component value, I might've missunderstood this.
>
> Thanks!
>
> /klas
>
> On Thu, Aug 22, 2019 at 8:49 AM Klas Lindfors <kl...@yu...
> <mailto:kl...@yu...>> wrote:
>
>     Hello!
>
>         thanks for the patch. I have started to fix the SCP03 mutual
>         authentication a couple days ago, not sure where I have left
>         off. Can you please describe the problem with the existing
>         code? I tried to summarize what I have found, is this correct?
>
>     Sorry, should've provided more details with the patch,
>      
>
>           * I see that the CMAC CLA byte is always set to 0x84, which
>             was incorrect.
>
>     Yes, (as I read the spec) CLA on mac is supposed to always be 0x84
>     disregarding whatever it actually is.
>
>           * The EVP_EncryptUpdate is now not encrypting the message in
>             one step.
>
>     Yeah, the previous code did EncryptUpdate in chunks of 8 which
>     means every second call just buffers the data, I replaced that
>     with one call to avoid having to care about sizes at all.
>     Additionally it only used 1-8 bytes of padding where AES needs
>     1-16 bytes.
>
>           * The padding size inthe wrap_command function is already
>             included in the encryptionLength and the wrappedLength
>             calculation can be simplified.
>
>     Yeah, here I added checks of status from the AES functions to bail
>     out on failure and restructured the length calculations,
>     additionally the encrypted part from calculate_enc_cbc_SCP03() was
>     never moved into wrappedApduCommand.
>
>         Have you checked if the R-MAC computation is correct? The
>         unwrap function is missing, so actually no response decryption
>         should work. I have not invested time to look into this, but
>         the patch does not contain any fixes for that?
>
>     Yeah, R-MAC seems to validate correctly for me, I noted the
>     missing unwrap, no fix for that.
>
>     I'm poking a bit at getting put_sc_key working with scp03 right now.
>
>     Thanks!
>
>     /klas
>
>
>
> _______________________________________________
> Globalplatform-developers mailing list
> Glo...@li...
> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers