Managing sam unlock at selection when unlockData needs to be diversified.

[lbureau-billettiqueservices]

Hey everyone. I'm thinking that i'm missing a detail or something about the use of CalypsoSamSelection.

Let's see this simple piece of code.

CalypsoSamSelection samSelection = calypsoExtensionService.createSamSelection();
samSelection.setUnlockData(unlockData);

CardSelectionManager selectionManager = smartCardService.createCardSelectionManager();
selectionManager.prepareSelection(samSelection);

CardSelectionResult selectionResult = selectionManager.processCardSelectionScenario(samReader);
calypsoSam = (CalypsoSam) selectionResult.getActiveSmartCard();

I have a problem with how unlockData is handled. What I can see in CalypsoSamSelectionAdapter, the unlockData passed to setUnlockData is used "as is", with no diversification.

Unlock key diversification is done using the SAM's serial number, which would mean that i would need to make a previous selection without unlock data to get the CalypsoSam object, get the SAM Serial, diversify it myself, then redo another selection with unlock.

It might be clearly possible that i'm missing a unlockSam method somewhere that i could call after selection, but I could not see one (and i could only find the object CmdSamUnlock in CalypsoSamSelectionAdapter).

If i'm not missing anything, i would propose this slight change in interface:

• make a new method setRawUnlockData that behaves like the current setUnlockData
• mark setUnlockData as deprecated
• make a new method setUnlockDataWithDiversifier(String unlockData, Diversifier diversification)

Diversifier would like this:

public interface Diversifier {
    byte[] diversify(CalypsoSam sam, byte[] masterKey)
}

That way, we can provide our own diversifier (the usual key diversification is, as far as i know, supposed to be secret, so implementing it directly into keyple (which is public) would break this).

The idea behind this would be that keyple should attempt the unlock using the diversified key from the diversifier object when doing the selection.

[jeanpierrefortune]

Hi Laurent,

Thank you for raising this issue and suggesting a solution.

The management of SAMs is so far incomplete.

There are two modes of using the SAM Unlock command: static or dynamic. Only the static mode is available today.

We are currently working on adding the full processing of SAM functionalities (Unlock, read/write counters and ceilings, key management).

We will keep you informed of these developments which will be completed soon.

[lbureau-billettiqueservices]

Thank you Jean-Pierre, but i'm not talking about using dynamic mode, i'm talking about the case where the SAM master key is diversified with the SAM's serial number. This diversification does not require a second SAM for dynamic mode, and then sends the key in static mode.

The current kinematic doesn't allow to have the serial number of the sam before selection, making it awkward to unlock the sam, as we can't compute the diversified key before selection.

But maybe i'm missing something?

Thanks for everything though.

[jeanpierrefortune]

I understand that this is a particular use of the static mode in which the lock value is diversified by a process independent of any SAM. It is indeed allowed to set an arbitrary value to the lock in the static mode and thus to make sure that a SAM does not have the same lock as its neighbor. However, when the diversifier used is the serial number of the SAM, it is necessary to perform the diversification computation after retrieving it. Today, the selection process allows to send APDUs to the card (here to the SAM) after the selection but these APDUs cannot be built from a value that would come from a preceding APDU or ATR because this mechanism is generic for any type of ISO card and it would not be simple to propose SPIs that would do this kind of operation without generating an undesirable complexity at this place. Originally, this possibility of adding APDUs was mainly intended to enrich the information from the selection, for example by reading the environment file. We have used it for the simple case of unlocking SAMs, but to go further it seems preferable to separate the selection from the unlocking operation, for example by performing a short SAM transaction at startup in which we will have complete freedom to produce the lock value. While waiting for these functionalities to be integrated, it is also possible to overcome this situation by performing the operation using the generic card extension to send the value of the lock with a "SAM Unlock" APDU.

[lbureau-billettiqueservices]

That is indeed what we do currently. It feels a little bit awkward, but it works.

As long as this use case is in the pipeline somehow (considering it is very common!), i'm fine with it. Thanks!

[jeanpierrefortune]

Hello Laurent,

We've just released a new version of the Keypop API and the corresponding Keyple library to enable advanced unlocking modes of the SAM.

It is now possible to compute a diversified version of the unlock value within the application, or to have it computed by an origin SAM in dynamic mode.

These modes are only available for components implementing the Keypop interfaces.

• keypop-calypso-crypto-legacysam-api 0.4.0
• keyple-card-calypso-crypto-legacysam-lib 0.5.0

Regards