How to randomize USB channel for crypttab script

Hello,

Please suggest how is it possible to randomize and/or protect what is being transferred over USB channel and disk buses like SATA for using together with disk encryption like dmcrypt, truecrypt, etc. ?

For example /etc/crypttab allows to specify a script which can be used to get a key e.g. from a file decrypted by smartcard and pass it to further disk encryption backend.

I need to protect from possible emmanation side channel attack.

So that attacker would not be able to get a pure key used for disk encryption via USB and SATA channels and still use USB Nitrokey for decryption. Please suggest, may be a ready solution exists?
Most likely encryption/decryption will not work because both values will be known to attackers.

But may be signature scheme can help somehow like:

?

Btw, do you have in NK PRO2 the same protection from emanation like in NK HSM2?

Is it just a few layers of a tin foil over the chip?

It still does not protect from data leakage from USB bus then, e.g. decrypted password for a LUKS slot?

It theoretically protects only from private key leakage inside the token and only provided with a good grounding, etc.?

Can you please suggest a well supported in Linux card reader without USB bus?

Do PCI smartcard readers exist working with OpenSC or at least proprietary PKCS11?

May be some model for a laptop PCMCIA?

Hi!

  1. Side-channel attacks are a very broad topic, hence I will refrain from commenting (you can always just install PCI card and have direct access to the memory…).
  2. Regarding transport channel encryption, FIDO2 does that partly and perhaps fido2luks would be the answer for you (you need to check with USB sniffer). Nitrokey HSM2 can establish encrypted channel with proper configuration, if I am not mistaken.
  3. As for the SATA transport channel, full disk encryption already does such as data are sent encrypted to the CPU. Or perhaps I misunderstood the question.
  4. Regarding OpenSC support for PCI / PCMCIA - please ask them directly.

As for the SATA transport channel, full disk encryption already does such as data are sent encrypted to the CPU. Or perhaps I misunderstood the question.

  1. A small boot partition with a kernel and initrd files is generally left not encrypted.
  2. Initrd generally contains an encrypted LUKS_key (by the public part of a cryptotoken’s private key), but since it is being decrypted over USB channel the LUKS_key becomes known to attackers and they can decrypt all further disk operations too even remotely without physical access to the disk, computer and room where computer is located .

May be using Nitrokey only for an authentication by signature in a highly protected by obfuscation program can help if such program is executed as a Librteboot payload stored in a BIOS chip without passing general storage buses?
Such program could have inside it actual LUK2 encryption keys in some encrypted form decrypted without help of the Nitrokey.

Can you please elaborate more about HSM2 encryption for USB channel? Cannot it be decrypted by attackers? Is it something like SESPAKE protocol?

Do you plan in the future to produce also NK PROx or NK HSMx in a form of a flat smartcard instead of an integrated USB devices as it is done right now?

The NK HSM is based on the SmartCard-HSM, which is available in various smartcard form factors and as MicroSD card with embedded SE.

The secure channel is using chip authentication and secure messaging as defined in BSI TR-03110 (and used in passports and eID cards). The card is authenticated using Card Verifiable Certificates (CVC) from a 3-tier PKI used in the production process of a SmartCard-HSM.

There is also some example code that we use in a project where a SmartCard-HSM is used to store the disk encryption key. However, the example does not use secure messaging yet.

Please let me know:

Does your HSM in a form factor of a flat smart card have the same functionality like current Nitrokey HSM2?

Does your flat HSM SC conform to the same documentation like Nitrokey AGD_SmartCard-HSM_V3.4_User_Manual.pdf except it does not have an integrated with it USB reader?

Secure Messaging
The secure channel is established with the GENERAL AUTHENTICATE command and
remains active until the applet is deselected, power is switched off, a command is sent in
plain or a secure messaging error occurred.
Secure messaging is implemented as defined in [TR-03110] with 3-TDES and AES-128
as cryptographic algorithm. All commands can be send either in plain or using an
established secure messaging channel.

Where your the latest version of flat HSM SC (the same in functionality as the latest NK HSM v2) can be purchased and shipped to another country?

Is it compatible with SC reader ACS ACR3901U-H3 ?

I have tested other inexpensive smart cards like Rutoken ECP2, ESMART Token (both Micron and ACS models) and eToken PRO in that SC reader via PKCS11 (both OpenSC where available and proprietary libs) and all of them work fine after firmware of the reader updated to the latest version. Unfortunately mentioned smart cards do not encrypt data sent via APDU in a reader USB channel, so they are good only for authentication by signature, but not for encryption of messages like secure passwords.

Thank you very much for your help.

Yes to all three questions. See the links on the website for distribution infos.

Please suggest is it possible to use your HSM SC in a boot environment like Debian Linux initrd busybox?
Can HSM SC be used over OpenSC to decrypt a password for opening a LUKS2 slot?

I can write a bash script by myself using other examples for Nitrokey (nitroluks), Yubikey, etc. if there is no a ready script for unlocking a LUKS2 root partition during boot by your HSM, just wondering if it is technically possible at all to use your HSM SC in such boot environment.

Which your flat SC product is equivalent to the Nitrokey HSM2?

Is it

?

Can biometric readers be used together with OpenSC in Linux:


to confirm each signature/authentication transaction using your HSM SC (say in OpenSSH) by a finger touch?

The HSM2 is the 4K version.

You can not use the plain SmartCard-HSM with biometric matching.

Please suggest, does a reader with a transaction confirmation exist which can be used together with your SmartCard-HSM 4K without a need for a custom integration with its SDK?

Any type of confirmation would be good, e.g. even a single button touch without PIN or
a PIN entry like SPE (secure PIN entry). If a SPE PIN has to be typed, then it shall be done on the reader’s small PIN pad instead of big host computer keyboard and without passing the the whole SPE PIN even encrypted through USB channel of the reader. It would even be acceptable having two PINs: SPE PIN (only for confirmation of reader pass-through the transaction) different from HSM2 PIN and then typing another second HSM2 PIN on the main PC keyboard as with a typical simple reader would be OK if still needed.

Main idea is to have a control over each signing transaction beyond main PC and its big keyboard.

For example in Russia such a smart card reader exists, it is SafeTouch PRO.
It is compatible only with a small predefined hardcoded into it white list of popular national SC models (like Rutoken ECP2, Jacarta, etc.) using only national GOST crypto algos and needs an additional integration via SDK to show detailed information about transaction being confirmed on its small PINPAD display. A single button press on the reader confirms a transaction, otherwise APDU commands do not get passed to the smartcard until button pressed.

Though there are no publicly available integrations except for bank institutions, SafeTouch PRO still can be used in other applications like CryptoARM in a blind mode without displaying detail info, but still requiring a touch of the confirmation button for each signing APDU transaction intercepted on the channel by the reader. In such a blind mode it will work with any application using GOST signing features of a compatible SC.

You can use the contact-based card form factor with the Reiner SCT cyberjack PIN pad card reader. That is working with both, the OpenSC middleware and the PKCS#11 module from sc-hsm-embedded.

Thank you for your suggestion about Reiner SCT cyberjack.

Please let me know how can I determine by myself if another reader works for a confirmation of a transaction of your smart card via PKCS#11 module from sc-hsm-embedded ?

For example there are a few PIN PAD SC readers mentioned on Debian website:
https://web.archive.org/web/20200826093718/https://wiki.gnupg.org/CardReader/PinpadInput

  • SCM SPR 532

    • USB ID: 04e6:e003
    • PC/SC reader name: SPRx32
  • KAAN Advanced

    • USB ID: 0d46:
  • FSIJ Gnuk Token

    • USB ID: 234b:0000
  • Reiner cyberJack Go

    • USB ID: 0c4b:0504
  • Vasco DigiPASS 920

    • USB ID: 1a44:0920
  • Cherry ST2000

    • USB ID: 046a:003e

What criterias, keywords or features of a reader can indicate a compatibility of such a reader with your card especially with a PIN entered on the reader’s PAD feature working correclty?

For example according to the page:
https://ccid.apdu.fr/ccid/supported.html
at least provided with some firmware level conditions following reader models shall be supported by the open source CCID driver:
SCM SPR 532, Kobil KAAN Advanced, Cherry ST2000
Do they allow to enter PIN code on the reader’s PAD for you HSM2 SC?

I ask this because even some models of Reiner cyberJack are mentioned as not working with opensc at least a few years ago:

http://opensc.1086184.n5.nabble.com/Confused-opensc-openct-pcsc-with-Reiner-SCT-pinpad-and-OpenPGP-card-and-S-Trust-card-td11420.html

https://lists.gnupg.org/pipermail/gnupg-users/2016-May/055946.html

If I understand correctly they mention that only a model with CCID support will work for entering PINs on the reader’s PAD?

When I asked ACS support in Russia they told me their models with PIN PADs do NOT support what I need (OpenSC, OpenSSH, etc.), they offer a SDK for a custom integration into each application.

Does it mean some models of Reiner SCT cyberJack reader are already integrated to OpenSC, which means OpenSC (or some other level of software stack like CCID driver, PCSCD, etc.) knows that a PIN shall be asked on the reader device and knows how to tallk with correct APDU commands to them? Sorry if I am wrong with terminology, I have not enough knowledge in that area and reader’s support staff often does not have it too according to my experience.

It seems there is an active support of the Reiner reader in Debian:
https://tracker.debian.org/pkg/pcsc-cyberjack

Can you please tell exact USB IDs of the compatible models of readers. A few of alternatives would be very helpful for a wider and easier choice and better understanding of what they have in common which allows them to work with your HSM SC + OpenSC + confirmation PIN entered on the reader’s PAD + support for OpenSSH and GPG applications.

Does support of OpenSC means also a compatibility with OpenBSD too if SC stack is built from ports?

Following use cases would be desirable to work with your HSM SC and a reader:

  1. Authenticate login over SSH by your HSM SC and confirm it on the reader’s PIN PAD.
    The same in OpenBSD too in addition to Linux, it means support of OpenSC is needed for the SC and reader with PIN PAD and CCID driver shall be open source too.
  2. Decrypt messages or text strings (for example passwords for LUKS2 slots) by command line tools, for example GPG, OpenSSL, etc. using private key stored inside your HSM SC and confirm it on the reader’s PIN PAD.
  3. Authenticate login into a Linux desktop via a PAM module configured for your your HSM SC and confirm it on the reader’s PIN PAD.

We do not perform regular tests with all the card readers available in the market. There is the PC/SC standard that defines how the interface has to be done, so if a manufacturer sticks to the standard, then it should work without further integration.

However, a lot of manufacturer don’t really care about standards and compatibility.

Internally we only test with cyberjacks, as those turned out to be reliable and well supported.

Can you please specify the exact models of Reiner Cyberjack readers including their USB IDs which you tested with your HSM2 4K card and where PIN typing from the reader’s PAD works ?

Bus 001 Device 030: ID 0c4b:0500 Reiner SCT Kartensysteme GmbH cyberJack RFID standard dual interface smartcard reader

Thanks for the model ID of the tested compatible reader.

According to:
https://bugzilla.redhat.com/show_bug.cgi?id=1092751
this reader was usable already in the end of 2015.

May I know how PIN PAD feature works for example when used with OpenSSH via your open PKCS11 driver for SC-HSM2 in OpenSC package. I try to find keywords for further googling and finding more contacts to ask more details about PIN PAD readers. According to open source CCID driver pages PIN PAD feature shall be supported at least in the CCID driver.

Do then other parts of the software stack except CCID driver like OpenSSH, OpenSC, PCSCD, etc. care about handling where PIN is typed? Which part of the stack generally asks to type a PIN code on the main PC keyboard when PIN PAD is not present on the reader at all? Is it PKCS11 library called from an application like OpenSSH? Do PKCS11 libraries or PCSCD contain any reader specific code especially related to asking PIN typing on the numeric PAD of the reader? Or this code is common for all PIN PAD readers?

In which part of this software stack a support is missing for example for ACS readers with numeric PAD present on the reader but “not integrated using their SDK” and therefore not working? With what part of the stack ACS readers shall be integrated? Only with CCID driver? Is that just missing code for handling their PIN PADs in the CCID driver? If ACS CCID driver improved for those models then other parts of the SC stack would automatically begin to work with those ACS readers like https://www.acs.com.hk/en/press-release/96/ensure-your-internet-security-with-acr83-secure-pin-entry-spe-personal-card-reader at least with some cards may be not yours? Now I am trying to understand just a whole concept of handling PINs typed on a reader’s PAD mini keyboard.

Most likely your SC-HSM smartcard would also require a feature of the reader named “extended APDU commands”?