Skip to main content
Redhat Developers  Logo
  • AI

    Get started with AI

    • Red Hat AI
      Accelerate the development and deployment of enterprise AI solutions.
    • AI learning hub
      Explore learning materials and tools, organized by task.
    • AI interactive demos
      Click through scenarios with Red Hat AI, including training LLMs and more.
    • AI/ML learning paths
      Expand your OpenShift AI knowledge using these learning resources.
    • AI quickstarts
      Focused AI use cases designed for fast deployment on Red Hat AI platforms.
    • No-cost AI training
      Foundational Red Hat AI training.

    Featured resources

    • OpenShift AI learning
    • Open source AI for developers
    • AI product application development
    • Open source-powered AI/ML for hybrid cloud
    • AI and Node.js cheat sheet

    Red Hat AI Factory with NVIDIA

    • Red Hat AI Factory with NVIDIA is a co-engineered, enterprise-grade AI solution for building, deploying, and managing AI at scale across hybrid cloud environments.
    • Explore the solution
  • Learn

    Self-guided

    • Documentation
      Find answers, get step-by-step guidance, and learn how to use Red Hat products.
    • Learning paths
      Explore curated walkthroughs for common development tasks.
    • Guided learning
      Receive custom learning paths powered by our AI assistant.
    • See all learning

    Hands-on

    • Developer Sandbox
      Spin up Red Hat's products and technologies without setup or configuration.
    • Interactive labs
      Learn by doing in these hands-on, browser-based experiences.
    • Interactive demos
      Click through product features in these guided tours.

    Browse by topic

    • AI/ML
    • Automation
    • Java
    • Kubernetes
    • Linux
    • See all topics

    Training & certifications

    • Courses and exams
    • Certifications
    • Skills assessments
    • Red Hat Academy
    • Learning subscription
    • Explore training
  • Build

    Get started

    • Red Hat build of Podman Desktop
      A downloadable, local development hub to experiment with our products and builds.
    • Developer Sandbox
      Spin up Red Hat's products and technologies without setup or configuration.

    Download products

    • Access product downloads to start building and testing right away.
    • Red Hat Enterprise Linux
    • Red Hat AI
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat Developer Toolset

    References

    • E-books
    • Documentation
    • Cheat sheets
    • Architecture center
  • Community

    Get involved

    • Events
    • Live AI events
    • Red Hat Summit
    • Red Hat Accelerators
    • Community discussions

    Follow along

    • Articles & blogs
    • Developer newsletter
    • Videos
    • Github

    Get help

    • Customer service
    • Customer support
    • Regional contacts
    • Find a partner

    Join the Red Hat Developer program

    • Download Red Hat products and project builds, access support documentation, learning content, and more.
    • Explore the benefits

Smart cards support in libssh

October 28, 2020
Sahana Prasad
Related topics:
SecurityKubernetesLinux

    In computer security, software implementations of cryptographic algorithms are vulnerable to side-channel attacks. This type of attack seeks to glean information from the computer system rather than from the program that it is running. As examples, Spectre and Meltdown are both side-channel attacks that target the microarchitecture of modern processors. Microarchitectural attacks are only a subset of all side-channel attacks. There are many others that leak sensitive secret information.

    An attacker who is able to access unauthorized regions in memory can discover private or sensitive information, including authentication secrets. A question that naturally follows is, "Where can I safely store my secrets?"

    One way to protect your secrets is to store them in a hardware token. A hardware token physically separates your secret key from the host machine and the applications that it is running. You can use secret keys stored on smart cards or cryptographic tokens to authenticate to server-side applications.

    This article introduces Public Key Cryptography Standard #11 (PKCS #11), which you can use to uniquely identify objects stored in tokens. I will show you how to build and use libssh with support for PKCS #11 and how to use curl to store and retrieve tokens through the secure shell (SSH) protocol.

    The PKCS #11 interface

    PKCS #11 provides an application programming interface (API) for interacting with devices like smart cards, which store private cryptographic information. Such cryptographic devices are known as tokens. PKCS #11 uses a uniform resource identifier (URI) to uniquely identify objects stored in tokens. The PKCS #11 URI is defined by the RFC 7512: PKCS #11 URI Scheme:

    pkcs11:token=my-token;object=my-object;type=private?pin-value=1234
    

    The URI format is defined as follows:

    • Every PKCS #11 URI begins with the scheme name, "pkcs11:".
    • The scheme name is followed by attribute-value pairs, which are separated by a semicolon.
    • The parameter token represents the name of the device or smart card.
    • The stored-object name in the token is identified by the parameter object.
    • The object itself can be of type private, public, certificate, data, or a secret key.
    • The parameter pin-value stores the personal identification number that is required to access the private key.

    Note: The token description provides authenticating applications with a logical view of the hardware device storing the cryptographic token.

    Smart card support in libssh

    The SSH library, or libssh, is a library-based implementation of the Secure Shell (SSH) protocol. It supports using PKCS #11 URIs to authenticate users to a remote server. Currently, PKCS #11 URI support is only available in the libssh main branch and not in Fedora. The next libssh release (0.9.x) will include PKCS #11 URI support, which will then be available in Fedora.

    Build and use libssh with PKCS #11

    The SSH library uses OpenSSL (Secure Socket Layer) as its cryptographic back end. OpenSSL defines an abstract layer called the engine, which implements cryptographic primitives. It provides cryptographic functionality, called key-loading, which we use to load private and public keys from smart cards. The engine_pkcs11 module acts as an interface between the PKCS #11 modules and OpenSSL.

    To build and use libssh with support for PKCS #11, do the following:

    1. Enable the cmake option: $ cmake -DWITH_PKCS11_URI=ON.
    2. Build with OpenSSL.
    3. Install and configure engine_pkcs11.
    4. Plug-in a working smart card or configure SoftHSM, a cryptographic store that is accessible through PKCS #11.

    The legacy functions in libssh are extended to automatically detect if a provided filename is a file path or a PKCS #11 URI. You can replace the paths to files containing keys and certificates with PKCS #11 URIs. If a PKCS #11 URI is detected, the engine is loaded and initialized. The engine loads the private or public key corresponding to the PKCS #11 URI from the PKCS #11 device.

    Note: If you wish to authenticate using public keys on your own, follow the steps described in the "Authentication with public keys" section of the libssh documentation (see Chapter 2: A deeper insight on authentication).

    Public-key authentication with PKCS #11 and libssh

    Here is a minimalistic example of public-key authentication using PKCS #11 URIs:

    int authenticate_pkcs11_URI(ssh_session session)
    {
      int rc;
      char priv_uri[1042] = “pkcs11:token=my-token;object=my-object;type=private?pin-value=1234”;
    
      rc = ssh_options_set(session, SSH_OPTIONS_IDENTITY, priv_uri);
      assert_int_equal(rc, SSH_OK)
    
      rc = ssh_userauth_publickey_auto(session, NULL, NULL);
    
      if (rc == SSH_AUTH_ERROR)
      {
        fprintf(stderr, “Authentication with PKCS #11 URIs failed: %s\n”,
          ssh_get_error(session));
        return SSH_AUTH_ERROR;
      }
    
      return rc;
    }
    

    Instead of specifying the path where the private-key file was stored, all you need to do is to set the PKCS #11 URI using SSH_OPTIONS_IDENTITY.

    Using PKCS #11 smart cards with curl

    Applications such as curl use libssh as the underlying library to communicate through the SSH protocol. In this example, we use curl to connect to a Secure File Transfer Protocol (SFTP) server:

    curl -kvu root: sftp://localhost –key ‘pkcs11:token=my-token;object=my-object;type=private?pin-value=1234’ — testuser
    

    We could change the above command to use a PKCS #11 URI to test a SSH testuser's access to localhost. Instead of specifying the path to the private key in the --key attribute,  we would specify the corresponding PKCS #11 URI.

    Conclusion

    This article has been a brief introduction to using the PKCS #11 standard and libssh to store and access cryptographic private information in hardware tokens such as smart cards. I will leave you with two additional recommendations.

    First, provide a specific PKCS #11 URI that matches only a single slot in the engine. If the engine discovers multiple slots that could potentially contain the private keys referenced by the provided PKCS #11 URI, the engine will not attempt to authenticate. Second, if you are using Elliptic Curve Digital Signature Algorithm (ECDSA) for your PKCS #11 URIs, ensure that you import the public keys along with the private keys to the token. Unlike the more commonly used RSA algorithm, ECDSA public keys cannot be derived from private keys.

    Last updated: November 4, 2020

    Recent Posts

    • Protect data offloaded to GPU-accelerated environments with OpenShift sandboxed containers

    • Case study: Measuring energy efficiency on the x64 platform

    • How to prevent AI inference stack silent failures

    • Preventing GPU waste: A guide to JIT checkpointing with Kubeflow Trainer on OpenShift AI

    • How to manage TLS certificates used by OpenShift GitOps operator

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Build

    • Developer Sandbox
    • Developer tools
    • Interactive tutorials
    • API catalog

    Quicklinks

    • Learning resources
    • E-books
    • Cheat sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site status dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2026 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Chat Support

    Please log in with your Red Hat account to access chat support.