• chevron_right

      DNSSEC signing with the se.SAM N200 HSM with PKCS#11

      pubsub.slavino.sk / jpmens.net · Saturday, 1 October, 2022 - 22:00 · 8 minutes

    I pretty much stumbled over sematicon and their N200 Series on my quest for Hardware Security Modules (HSM) of almost any shape and size, and after a very pleasant phone call with one of their managers, I was quickly given documentation to study and access to a dedicated device over a Wireguard VPN.

    Every appliance features two or more independently configurable crypto processors, which work with a variety of keys. Therefore, test and production can be operated separately of each other on only one platform.

    Although the N200 series isn’t specifically tailored to PKCS#11, it’s what I’m mainly interested in so what I focus on. I pretty much ignored the actual PKI capabilities of the device. It can be a certification authority (CA), produce X.509 certificates, perform symmetric encryption, and a load of other features. I toyed with creating a user and assigning access rules. The Web-based UI is neat and functional. There were some labels and captions which appeared confusing to me, but I got used to them.

    PKCS#11 support is relatively new, and the documentation doesn’t yet mention about it, but I’m told that will change for the upcoming new version. A small interim PDF gave some tips, but I had a bit trouble actually using the interface because after initializing the device, I wasn’t aware that I had to create an access rule for a user who wants to use the PKCS#11 interface without which I kept getting an access denied. A brief meeting with the person who’s blog article initially led me to sematicon got me set up.

    I copy the PKCS#11 sematicon-provided shared object library to the directory I want it in and configure the n200.conf file, adding a high log level to begin with, but it turns out the level is ignored: setting it to 0 doesn’t change much. Beware the log: it will contain the user and password in clear, but I’ve reported this. 

    % echo "10.195.10.11 seSAM-nserie-101" >> /etc/hosts    # avoid TLS verification errors on hostname                                                        #the appliance has a cert with subject CN= this name

% install -m 555 pkcs11-sesam-x64-3.so /usr/local/lib

% export p=/usr/local/lib/pkcs11-sesam-x64-3.so

% cat $N200_CONF 
{
   "url": "https://10.195.10.11/n200/web/postv1",
   "tlscert": "/etc/tls/server63.crt",
   "user": "pkmaster",
   "pass": "<password>",
   "core": 1,
   "keygen_pin": "12345678",
   "log_level": 10,
   "log_output": "/tmp/seSAM_p11.log"
}

% pkcs11-tool --module $p --show-infoCryptoki version 3.0
Manufacturer     sematiconAG
Library          se.SAM N200 pkcs11 (ver 1.0)
Using slot 0 with a present token (0xc13cc61)

    The pkcs11-sesam.so speaks to the N200 via their REST API using curl , and judging by the number of CURL_GLOBAL_INIT occurrences, there is plenty of opportunity to improve performance of the shared library. (I will gloss over performance, because the network connection I had to the HSM was so flaky as to not be funny.)

    Web UI

    I’ve already mentioned the N200 has a REST API which I want to test. After learning how to do so in the Web UI, I use the API to generate a key-pair on the device: 

    % curl \
        --cacert server63.crt \
        -u $user:$pass\--no-progress-meter\-dcommand=genecckey \-dcore=1 \-dcurve=NIST \-dkeysize=256 \-dacl=FFFF \-dpin=12345678 \-dnice_name=JP.example \
        https://seSAM-nserie-101/n200/web/postv1
{       
  "command": "genecckey",
  "core": 1,
  "clustersync": "n/a",
  "nice_name": "JP.example",
  "publickey": "FACD4CF599AD0CBD43A5C38B294AF3DDC06FBC0883D419EEBCBF8039C132FC61FE972236B38A1C236E5EF0F1E78B64B31C9632C0D5B9CFA49AECDB89144A2C3C",
  "result": "hsm010123F13C56131E1EEE0000000000000025"
}

% pkcs11-tool --module $p --token-label hsm010123F13C56131E1EEE00000025 --list-objectsPublic Key Object;EC  EC_POINT 256 bits
  EC_POINT:   044104facd4cf599ad0cbd43a5c38b294af3ddc06fbc0883d419eebcbf8039c132fc61fe972236b38a1c236e5ef0f1e78b64b31c9632c0d5b9cfa49aecdb89144a2c3c
  EC_PARAMS:  06082a8648ce3d030107
  label:      JP.example
  ID:         aaab68606be2
  Usage:      encrypt, verify
  Access:     local
Private Key Object;EC
  label:      JP.example
  ID:         aaab68606be2
  Usage:      decrypt, sign, non-repudiation
  Access:     sensitive, always sensitive, never extractable, local
  Allowed mechanisms: ECDSA,ECDSA-SHA1,ECDSA-SHA224,ECDSA-SHA256,ECDSA-SHA384,ECDSA-SHA512

    The result from the key generation has an identifier (also visible in the UI) which sadly has eight more zeroes in it than the token label in the slot; I don’t know if that’s on purpose. (A limit of 32 characters in a token slot name maybe?) I say sadly because it requires an extra step ( pkcs11-tool --module $p -T ) to find the correct token label.

    Web details of the created ECC key

    It’s time to sign our zone with our Combined Signing Key or Single Signing Key, both euphemisms for “I’m too poor to afford a second key pair”. 

    % cat $OPENSSL_CONF
openssl_conf = openssl_init

[openssl_init]
engines=engine_section

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib64/engines-3/libpkcs11.so
MODULE_PATH = /usr/local/lib/pkcs11-sesam-x64-3.so
init = 1

    After configuring OpenSSL’s engine to use our pkcs11-sesam.so module, I generate the pair of key files referencing the key material in the HSM. Use of the PIN value here depends on the setting in the HSM proper: the N200 can store the PIN on the device in order to not require it on the client, IMO six of one and half-a-dozen of the other in terms of security. 

    % cat jp.example 
$TTL 3600
@ SOA  ns  jpmens  1 3H 1H 1W 1H
  NS   @
  A    192.0.2.43

% dnssec-keyfromlabel -E pkcs11 -a13 -l "token=hsm010123F13C56131E1EEE00000025;object=JP.example;pin-value=12345678" -fKSK jp.example 
Kjp.example.+013+29467

% dnssec-signzone -E pkcs11 -t -z -S -o jp.example jp.example 
Fetching jp.example/ECDSAP256SHA256/29467 (KSK) from key repository.
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 0 active, 0 stand-by, 0 revoked
jp.example.signed
Signatures generated:                        5
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 5.302
Signatures per second:                   0.942
Runtime in seconds:                      5.984

    I wrote earlier that I would gloss over performance, so I will. I’ve no idea where the device is (network-wise) so I’m taking these numbers with spoon-fulls of salt. (To be fair: I wouldn’t expect miracles if the device were close to me because of the seemingly large amount of HTTP requests I see in the log; recall that each DNS and NSEC{3} record needs to be signed and causes a HTTP request.)

    I see in the Web UI that I can import a key to the device and try a PKCS#8-wrapped key, but that doesn’t work for me, but the API should work, and it does: 

    #!/usr/bin/env python3
importrequestsimportjsonurl="https://seSAM-nserie-101/n200/web/postv1"data={"command":"importecckey","core":1,"curve":"NIST","acl":"FFFF","pin":"12345678","nice_name":"example-dot-com-EC","key_to_import":"443A5A0F630559075B8ED453E69FB134E73BED96B7E7695D55AFBBFC085278CD"}r=requests.post(url,data,verify='server63.crt')print("status: %s, %s"%(r.status_code,json.dumps(json.loads(r.text),indent=4)))

    The RAW key data for key_to_import I obtained from the ECDSA key I want to import: 

    % dnssec-keygen -a13 -fksk example.com
Generating key pair.
Kexample.com.+013+37354

% awk '/PrivateKey:/ { print $2 }' Kexample.com.+013+37354.private | base64 -d | ./hexlify
443A5A0F630559075B8ED453E69FB134E73BED96B7E7695D55AFBBFC085278CD

% ./jpimport.py
status: 200, {
    "command": "importecckey",
    "core": 1,
    "result": "hsm010123F13C56131E1EEE0000000000000018"
}

    There’s a so-called “TCP-RAW-API” which allows direct access to the crypto processor as well as an HTTP GET API which uses the URL to transport a request to the appliance; the response to this is JSON. Here are a few examples including symmetric encryption and decryption. (I’ve not yet tried the factoryreset …) In the following examples I omit specifying the certificate verification option in the interest of brevity. 

    % curl https://seSAM-nserie-101/n200/timestamp/  
{"command": "timestamp", "result": "1664657599"}

% curl https://seSAM-nserie-101/n200/getrandom/5/
{"command": "getrandom", "numbers": "5", "core": 1, "result": "EBFB604875"}

% curl https://seSAM-nserie-101/n200/getkeyattributes/k01/
{
  "command": "getkeyattributes",
  "result": {
    "hsm010123F13C56131E1EEE0000000000000026": {
      "key_id": "hsm010123F13C56131E1EEE0000000000000026",
      "key_type": "SYM",
      "key_len": 256,
      "key_acl": "FFFF",
      "key_owner": "pkmaster",
      "nice_name": "k01"
    }
  }
}

% curl https://seSAM-nserie-101/n200/encrypt/k01/12345678/CBC/hello-world/
{
  "command": "encrypt",
  "core": 1,
  "result": "A84663E043099BC74C11628DAFB69B6D8FAABCFBF4FC4AF33657B719C96617B772D229AB8A9A0E7B3903C6E404121980"
}

% curl https://seSAM-nserie-101/n200/decrypt/k01/12345678/CBC/A84663E043099BC74C11628DAFB69B6D8FAABCFBF4FC4AF33657B719C96617B772D229AB8A9A0E7B3903C6E404121980/
{
  "command": "decrypt",
  "core": 1,
  "result": "hello-world"
}

% curl https://seSAM-nserie-101/n200/listkeys/NIST/
{
  "command": "listkeys",
  "core": 0,
  "result": {
    ...
    "hsm010123F13C56131E1EEE0000000000000025": {
      "slot": "hsm010123F13C56131E1EEE00000025",
      "key_id": "hsm010123F13C56131E1EEE0000000000000025",
      "id": "AAAB68606BE2",
      "key_type": "NIST",
      "key_len": 256,
      "key_acl": "FFFF",
      "nice_name": "JP.example",
      "date_of_creation": "2022/10/01 20:15",
      "date_of_last_use": "2022/10/01 20:32",
      "date_planned_lifetime_until": null,
      "token_name": "hsm010123F13C56131E1EEE00000025",
      "key_owner": "pkmaster",
      "public_key": "FACD4CF599AD0CBD43A5C38B294AF3DDC06FBC0883D419EEBCBF8039C132FC61FE972236B38A1C236E5EF0F1E78B64B31C9632C0D5B9CFA49AECDB89144A2C3C"
    }
  }
}

    The sematicon N200 is a network-attached HSM and is positioned as an IoT-specialized device, and I felt comfortable using it after a bit of study. The documentation is good, and the chapter on APIs describes each call in detail for the three access methods (RAW, GET, POST).

    My specific use-case (signing DNS records via a PKCS#11 interface) is not a forte of the appliance, but I was told that from the outset. In spite of this, I was positively surprised that all the PKCS#11 functions required by the utilities I used were supported.

    As an all-purpose HSM this appears to be a very interesting device at a price far below what the market “leaders” demand for a networked appliance.

    Značky: #Network

    • wifi_tethering open_in_new

      This post is public

      jpmens.net /2022/10/02/the-se-sam-n200-hsm-with-pkcs-11/