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

Discussion:

Jaime Hablutzel Egoavil

2017-03-21 04:46:39 UTC

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

Tomas Gustavsson

2017-03-21 15:19:24 UTC

Permalink

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". The command just doesn't sense
that you are not changing anything, but just giving the same PIN.

Cheers,
Tomas

Post by Jaime Hablutzel Egoavil
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
$ 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
https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Jaime Hablutzel Egoavil

2017-03-21 17:34:19 UTC

Permalink

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.

Post by Tomas Gustavsson
The command just doesn't sense
that you are not changing anything, but just giving the same PIN.
Cheers,
Tomas

------------------

Post by Jaime Hablutzel Egoavil
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
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
https://lists.sourceforge.net/lists/listinfo/ejbca-develop

--
Jaime Hablutzel - RPC 994690880

Tomas Gustavsson

2017-03-22 08:07:27 UTC

Permalink

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

Post by Tomas Gustavsson
Hi,
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
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

------------------------------------------------------------------------------

<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
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
https://lists.sourceforge.net/lists/listinfo/ejbca-develop

Jaime Hablutzel Egoavil

2017-03-23 23:35:18 UTC

Permalink

Post by Tomas Gustavsson
The comment states that it is for verifying the supplied PIN. I.e. that
it works.

If I'm just about to set auto-activation for a PKCS #11 crypto token, what
is the purpose of verifying the old pin?. It should suffice to ask for the
new pin and set auto-activation with that.

Post by Tomas Gustavsson
What is it exactly that you want to do, and what are your expectations
of the process?

I just think that the following command should suffice to update a pin and
set auto-activation for a PKCS #11 crypto token. No need for --oldpin.

$ ejbca.sh cryptotoken setpin --token ManagementCA --newpin
partitionpassword

Post by Tomas Gustavsson
/Tomas

Post by Tomas Gustavsson
Hi,
For soft CryptoTokens the underlying keystore's pin will be modified

and

Post by Tomas Gustavsson
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
if
(*SoftCryptoToken.class.getName().equals(cryptoToken.getClas

s().getName())*)

Post by Tomas Gustavsson
{
...
*} 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_P

ROPERTY);

Post by Tomas Gustavsson
} 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

Post by Jaime Hablutzel Egoavil
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