Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr...>
wrote:

> Hi,
>
> The "--help" text provides this information:
>
> For soft CryptoTokens the underlying keystore's pin will be modified and
> this requires the current activation PIN.
>
> So, being a generic command, it will use the "oldpin" to open the P12
> file, and change password to "newpin".


Ok, for soft tokens it makes perfect sense: you need the previous PIN to
open the P12 and protect it again, but the code I quoted doesn't apply for
soft tokens, I'm quoting a larger chunk now:

if (
*SoftCryptoToken.class.getName().equals(cryptoToken.getClass().getName())*)
{
    ...
*} else {*
    if (oldAutoActivationPin != null) {
        // If we have an old auto-activation pin we will compare the
"current" with this value to avoid deactivating the token
        if (!oldAutoActivationPin.equals(new
String(currentAuthenticationCode))) {
            final String msg = "Supplied PIN did not match auto-activation
PIN.";
            log.info(msg);
            throw new CryptoTokenAuthenticationFailedException(msg);
        } else {
            log.debug("Successfully verified the PIN for non-soft
CryptoToken by comparing supplied PIN to auto-activation PIN.");
        }
    } else {
        *// If we don't have an auto-activation pin to compare the supplied
PIN to, we need to verify the supplied*
*        // PIN can be used in a de-activation/activation cycle.*
*        final boolean wasInactive =
!isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);*
*        cryptoToken.deactivate();*
*        cryptoToken.activate(currentAuthenticationCode);*
*        if (wasInactive) {*
*            // Note that there is a small glitch here where the token was
active, but we have no other options to verify the pin*
*            cryptoToken.deactivate();*
*        }*
    }
    if (newAuthenticationCode == null) {
        cryptoTokenProperties.remove(CryptoToken.AUTOACTIVATE_PIN_PROPERTY);
    } else {
        BaseCryptoToken.setAutoActivatePin(cryptoTokenProperties, new
String(newAuthenticationCode), true);
    }
    cryptoToken.setProperties(cryptoTokenProperties);
}

The highlighted section is the one that currently applies to PKCS #11
crypto tokens and I just don't understand what is its purpose.


> The command just doesn't sense
> that you are not changing anything, but just giving the same PIN.
>
> Cheers,
> Tomas
>
> On 2017-03-21 05:46, Jaime Hablutzel Egoavil wrote:
> > Let's say I have a PKCS #11 crypto token deactivated and having
> > auto-activation disabled. Now, if I want to activate the crypto token
> > and turn on auto-activation using the local CLI I need to use the
> > following command:
> >
> > $ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
> > partitionpassword --newpin partitionpassword
> >
> > Where --oldpin is a mandatory parameter, but... why?, given that the new
> > PIN should suffice to activate the partition and enable auto-activation.
> >
> > Furthermore, I can see the following code being executed for the
> > previous operation (where currentAuthenticationCode corresponds to
> > --oldpin).
> >
> > // If we don't have an auto-activation pin to compare the supplied PIN
> > to, we need to verify the supplied
> > // PIN can be used in a de-activation/activation cycle.
> > final boolean wasInactive =
> > !isCryptoTokenStatusActive(authenticationToken, cryptoTokenId);
> > cryptoToken.deactivate();
> > cryptoToken.activate(*currentAuthenticationCode*);
> > if (wasInactive) {
> >   // Note that there is a small glitch here where the token was active,
> > but we have no other options to verify the pin
> >   cryptoToken.deactivate();
> > }
> >
> > But I can't figure it out the reason to exercise this
> > de-activation/activation cycle in the current scenario. Why would you
> > want to test the previous or current PIN when you are about to set a new
> > one?.
> >
> > Can you please provide some explanation on the reason to require
> > --oldpin and what the previous code is doing?
> >
> > Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.
> >
> > --
> > Jaime Hablutzel -  RPC 994690880
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejb...@li...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>



-- 
Jaime Hablutzel -  RPC 994690880