openssl/openssl

Async-signal-safe API to clear `EVP_PKEY` contents

Open

#30.057 geöffnet am 17. Feb. 2026

Auf GitHub ansehen
 (6 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C (11.262 Forks)batch import
help wantedtriaged: feature

Repository-Metriken

Stars
 (30.157 Stars)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

Background

In containerized environments, applications often cannot rely on the host’s default core-dump configuration. Core dump behavior is controlled by host-level limits and kernel settings, which may be restricted by the container runtime. As a result, some applications install fatal signal handlers and generate crash artifacts (e.g. core dumps or structured crash reports) in userspace.

When a process receives a fatal signal (e.g. SIGSEGV, SIGABRT) and handles it via sigaction, applications may need to ensure that private key material is not recoverable from those crash artifacts.

Calling EVP_PKEY_free() from a signal handler is not safe, as it may eventually call free(), which is not async-signal-safe and can result in undefined behavior. Currently, there is no supported way to reliably wipe the contents of an EVP_PKEY in a signal-safe context.

Proposal

Introduce an async-signal-safe API to clear sensitive key material without freeing memory, e.g.:

int EVP_PKEY_clear(EVP_PKEY *pkey);

Requirements:

  • Zero all sensitive key material associated with the EVP_PKEY
  • Must not call free() or other non–async-signal-safe functions
  • Must not allocate memory or take locks
  • Safe to call from a fatal signal handler
  • Leave the object allocated but in an cleared/inert state

The goal is zeroization only, not object destruction.

Rationale

  • Reduces risk of private key exposure via core dumps
  • Enables safer crash handling in security-sensitive applications
  • Avoids undefined behavior/crash from calling non–signal-safe APIs
  • MADV_DONTDUMP or similar mechanisms cannot be used

We would appreciate feedback on whether such an API would be acceptable, or whether there are alternative approaches that better align with OpenSSL’s design.

Contributor Guide