Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-9067

Improve CryptoToken Config: Verify Auto-Activation Codes


    • Provenance:
      Internal Delivery
    • Issue discovered during:
    • Sprint:
      EJBCA Team Alice - 2020 w16, EJBCA Team Alice - 2020 w20


      We've had a funny situation in an Appliance Support case that I am not 100% sure how he got into (I have a theory), but I am sure I found an edge case (perfectly reproducable and matching the customers description) we can improve behaviour on. The situation the customer was in looked like this:

      • He has an EJBCA CryptoToken with a manual authentication code (not WebConf-autogenerated) where he manually enabled auto-activation, that must have worked at some point.
      • Today, whenever he rebooted the Appliance (or restarted JBoss), the CryptoToken would not auto-activate. Logs show that for sure, EJBCA tried to activate the CryptoToken, but it looks like it has the wrong authentication code stored in the DB.
      • Analysis: The customer at some point has manually changed the P11 slot PIN (through WebConf) but not reconfigured EJBCA.
      • The customer has still not understood that, tries to troubleshoot the problem. Looking at the CryptoToken, it pretends to have auto-activation enabled, as the customer wishes.
      • The customer manually activates the CryptoToken by manually entering the correct/new Authentication Code. The CryptoToken activates successfully.

      One of the problems here clearly is that due to the nature of the P11/SunP11Wrapper stack, the CryptoToken Config Page can not verify the entered authentication code when the CryptoToken is already active.

      This could perhaps be achieved the following way: If an operator manually activates a CryptoToken that was previously not activated, and if the CryptoToken is configured to auto-activate, and if activating the CryptoToken was successful, automatically store the new authentication code.
      Or, if automatically storing the activation code is too critical, then compare the stored authentication code to the entered authentication code. If those differ, forget the stored authentication code and disable auto-activation.

      Perhaps also we should think about to auto-disable the auto-activate setting of a CryptoToken whenever auto-activating fails with CKR_PIN_INCORRECT.


          Issue Links



              bastianf Bastian Fredriksson
              manueld Manuel Dejonghe
              Verified by:
              Henrik Sunmark
              0 Vote for this issue
              2 Start watching this issue



                  Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0 minutes
                  Time Spent - 2 hours