Skip to content

Add AES Key Derivation Support (ECB,CBC Encrypt) #97

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 29, 2020

Conversation

aXedge-arm
Copy link

Additional Information:

  1. Added AES Key Derivation mechanisms described in
    PKCS11 v2.4.0 Section 2.15:
  • CKM_AES_ECB_ENCRYPT_DATA
  • CKM_AES_CBC_ENCRYPT_DATA

Sanity Testing:

  1. Build Validation:
    python setup.py build_ext --inplace

  2. AES Testing:
    export PKCS11_MODULE=XXX
    export PKCS11_TOKEN_LABEL=XXX
    export PKCS11_TOKEN_PIN=XXX
    export PKCS11_TOKEN_SO_PIN=XXX
    pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik

Additional Information:

1. Added AES Key Derivation mechanisms described in
   PKCS11 v2.4.0 Section 2.15:
  - CKM_AES_ECB_ENCRYPT_DATA
  - CKM_AES_CBC_ENCRYPT_DATA

Sanity Testing:

1. Build Validation:
python setup.py build_ext --inplace

2. AES Testing:
export PKCS11_MODULE=XXX
export PKCS11_TOKEN_LABEL=XXX
export PKCS11_TOKEN_PIN=XXX
export PKCS11_TOKEN_SO_PIN=XXX
pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik
Copy link
Collaborator

@danni danni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs tests.

self.param = aes_cbc_params = \
<CK_AES_CBC_ENCRYPT_DATA_PARAMS *> PyMem_Malloc(paramlen)
(iv, data) = param
aes_cbc_params.iv = [<CK_BYTE> x for x in iv[:16]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be able to express this without a comprehension.

@@ -109,6 +109,8 @@ cdef class MechanismWithParam:
cdef CK_RSA_PKCS_OAEP_PARAMS *oaep_params
cdef CK_RSA_PKCS_PSS_PARAMS *pss_params
cdef CK_ECDH1_DERIVE_PARAMS *ecdh1_params
cdef CK_KEY_DERIVATION_STRING_DATA *aes_ecb_params
cdef CK_AES_CBC_ENCRYPT_DATA_PARAMS *aes_cbc_params
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is getting to be a good indication that the mechanism types above should be implemented as subclasses of MechanismWithParam (which should be renamed), mechanism_param keyword should be removed and this class allowed as a parameter to mechanism.

This would allow mechanism=RSA_PKCS, mechanism=Mechanism(AES_CBC, param=iv) or mechanism=mechanisms.RSA_PKCS_OAEP(params=...) with proper typing and a much better point for implementing extensions beyond this package.

That doesn't have to be done now, just a note.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So shall this be added as a feature request, or do you want to take this up now?

If one has been created, I could add its link here in order to complete the tracking of this suggestion.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to give refactoring it a go, I'd be keen. I've opened #98 to track it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi Danni, if it's okay with you, I'll attempt that once these changes have been merged.

Additional Information:

1. Added AES Key Derivation mechanisms described in
   PKCS11 v2.4.0 Section 2.15:
  - CKM_AES_ECB_ENCRYPT_DATA
  - CKM_AES_CBC_ENCRYPT_DATA

2. Incorporated code-review comments:
  - directly sliced the IV data to extract mechanism_params for CBC_ENCRYPT,
  - added Unit Tests for ECB_ENCRYPT
    - test_derive_ecb_encrypt
  - added Unit Tests for CBC_ENCRYPT
    - test_derive_cbc_encrypt

Sanity Testing:

1. Build Validation:
python setup.py build_ext --inplace

2. AES Testing:
export PKCS11_MODULE=XXX
export PKCS11_TOKEN_LABEL=XXX
export PKCS11_TOKEN_PIN=XXX
export PKCS11_TOKEN_SO_PIN=XXX
pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik
@@ -7,6 +7,7 @@

from . import TestCase, requires, FIXME

from parameterized import parameterized
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing from dev-requirements.{in,txt}

pkcs11.exceptions.FunctionFailed) as e:
derived_key = None

if test_type.startswith("NEGATIVE"):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Split these into two separate tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although, now I think about it, do we honestly need to parameterize so many tests? It feels here like we're actually testing the PKCS#11 library, not the wrapper.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Essentially these tests validate what "should" work with PKCS11.
I agree that they might be doing more than just verify our changes, but I felt that these tests might also serve as reference points of what works vs what shall not work. this might be useful for any other newbie developers (like me).
I would still remove them, if you like.
in the meantime, I would upload the test split across key_derivation-only and key_derivation+data_enc/dec
I await your feedback :-)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay to keep the parameterised, I just don't like branches in tests. It means you effectively now need to be coverage testing your tests to know if you got it all.

Consider passing in func which can either be assertIsNone or assertIsNotNone and not having a branch at all. func might have to be a string that calls getattr(self, func)(...), but that will still fail hard if the function doesn't exist.

IndexError) as e:
derived_key = None

if test_type.startswith("NEGATIVE"):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Split these into two separate tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Akshitij Malik added 3 commits October 26, 2020 11:05
Additional Information:

1. Added AES Key Derivation mechanisms described in
   PKCS11 v2.4.0 Section 2.15:
  - CKM_AES_ECB_ENCRYPT_DATA
  - CKM_AES_CBC_ENCRYPT_DATA

2. Incorporated code-review comments:
  - directly sliced the IV data to extract mechanism_params for CBC_ENCRYPT,
  - added Unit Tests for ECB_ENCRYPT
    - test_derive_ecb_encrypt
  - added Unit Tests for CBC_ENCRYPT
    - test_derive_cbc_encrypt
  - updated dev-requirements
  - split the Unit Tests into 2 phases:
    - key-derivation tests
    - data encrypyion/decryption tests

Sanity Testing:

1. Build Validation:
python setup.py build_ext --inplace

2. AES Testing:
export PKCS11_MODULE=XXX
export PKCS11_TOKEN_LABEL=XXX
export PKCS11_TOKEN_PIN=XXX
export PKCS11_TOKEN_SO_PIN=XXX
pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik
Additional Information:

1. Added AES Key Derivation mechanisms described in
   PKCS11 v2.4.0 Section 2.15:
  - CKM_AES_ECB_ENCRYPT_DATA
  - CKM_AES_CBC_ENCRYPT_DATA

2. Incorporated code-review comments:
  - directly sliced the IV data to extract mechanism_params for CBC_ENCRYPT,
  - added Unit Tests for ECB_ENCRYPT
    - test_derive_ecb_encrypt
  - added Unit Tests for CBC_ENCRYPT
    - test_derive_cbc_encrypt
  - updated dev-requirements
  - split the Unit Tests into 2 phases:
    - key-derivation tests
    - data encrypyion/decryption tests
    - replaced f-strings with python3.5 compatible format strings

Sanity Testing:

1. Build Validation:
python setup.py build_ext --inplace

2. AES Testing:
export PKCS11_MODULE=XXX
export PKCS11_TOKEN_LABEL=XXX
export PKCS11_TOKEN_PIN=XXX
export PKCS11_TOKEN_SO_PIN=XXX
pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik
Additional Information:

1. Added AES Key Derivation mechanisms described in
   PKCS11 v2.4.0 Section 2.15:
  - CKM_AES_ECB_ENCRYPT_DATA
  - CKM_AES_CBC_ENCRYPT_DATA

2. Incorporated code-review comments:
  - directly sliced the IV data to extract mechanism_params for CBC_ENCRYPT,
  - added Unit Tests for ECB_ENCRYPT
    - test_derive_ecb_encrypt
  - added Unit Tests for CBC_ENCRYPT
    - test_derive_cbc_encrypt
  - updated dev-requirements
  - split the Unit Tests into 2 phases:
    - key-derivation tests
    - data encrypyion/decryption tests
    - replaced f-strings with python3.5 compatible format strings
  - negative test rework:
    - prevent branching by passing assertIsNotNone and assertIsNone
      as assertion functions for Positive & Negative test cases.

Sanity Testing:

1. Build Validation:
python setup.py build_ext --inplace

2. AES Testing:
export PKCS11_MODULE=XXX
export PKCS11_TOKEN_LABEL=XXX
export PKCS11_TOKEN_PIN=XXX
export PKCS11_TOKEN_SO_PIN=XXX
pytest ./tests/test_aes.py

Signed-off-by: Akshitij Malik
@danni danni merged commit c148a2f into pyauth:master Oct 29, 2020
@danni
Copy link
Collaborator

danni commented Oct 29, 2020

Thanks for this 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants