Menu
▾
▴
Re: [Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?
|
From: Tomas G. <to...@pr...> - 2017-03-22 08:07:39
|
The comment states that it is for verifying the supplied PIN. I.e. that
it works.
What is it exactly that you want to do, and what are your expectations
of the process?
/Tomas
On 2017-03-21 18:34, Jaime Hablutzel Egoavil wrote:
>
>
> On Tue, Mar 21, 2017 at 10:19 AM, Tomas Gustavsson <to...@pr...
> <mailto: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 <http://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...
> <mailto:Ejb...@li...>
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> <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...
> <mailto:Ejb...@li...>
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>
>
>
>
> --
> 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
>
|
