Secure networking building blocks, engineered for constrained hardware first.

KA Libraries are Kasteon's embedded-first, modular building blocks for secure networking—engineered to run on constrained microcontrollers (STM32), then extended, from the same codebase, up through full desktop and server operating systems (Linux, macOS, Windows). Available for direct integration into your own products.

Discuss integration
Built for real-world use cases. KA Libraries power Kasteon SecureAccess, which targets enterprise, IoT, medical, and defense use cases. SecureAccess is currently in internal testing and development. See SecureAccess

Embedded-first. Cross-platform by design, not by porting.

KA Libraries are built embedded-first—designed from the ground up for constrained, resource-limited targets—and extend, from the same codebase, up through full desktop and server operating systems. All platform-specific functionality is fully abstracted within the libraries (via KA-Core's platform support layer), so products built on top of them—including SecureAccess itself—contain no platform-specific code of their own. The only platform dependency at the application layer is the build environment.

Most embedded-grade IPsec/PQC implementations stay embedded—constrained, narrow-purpose, hard to extend beyond the MCU they were written for. KA Libraries start from that same constrained-hardware discipline but don't stop there—the identical codebase scales up to full desktop and server platforms without a rewrite. That's the harder direction to build in, and the reverse of how most desktop-first security stacks get "ported down" to embedded, typically shedding features, hardening, or performance along the way.

STM32 family of 32-bit microcontrollers — embedded / IoT Linux macOS Windows

Independently usable. Built to work together.

Each KA library can be integrated on its own or as part of the full stack. All are the same components used by Kasteon SecureAccess. Capability details below are drawn directly from a source-level audit of the codebase, including what's implemented, what specifications each feature traces to, and known gaps — not marketing summaries.

KA-Core

runtime

Foundational runtime services—memory allocation, error handling, logging, and the platform support layer—underlying every other KA library.

● production-ready
Full technical detail

Key Capabilities

  • Platform Support Package (PSP): a single abstraction for time, locking, allocation, and logging that every other KA library builds on—this is the seam that lets the same codebase run from an MCU to a desktop OS.
  • Fixed-size object pool and multi-size arena allocators, built entirely on caller-supplied platform hooks (never libc malloc), with optional allocation metrics and a persistent vs. per-tick allocation lifetime model.
  • Sink-based logging framework: console, file (with log rotation), and UART sinks; severity and category filtering; an async-dispatch hook for integration with an event loop.
  • Byte-order helpers, a stack-depth probe for embedded bring-up/debugging, and 3GPP-specific parsing utilities (BCD, PLMN, 5G Serving Network Name construction).

Specifications

  • MISRA C:2012 (documented deviations)
  • 3GPP TS 24.501 §9.11.3.4 (BCD/MSIN encoding), TS 23.003 §2.2 (PLMN encoding), TS 24.501 §5.4.1.3.2 (5G Serving Network Name)

KA-Crypto

cryptography

Post-quantum and classical cryptographic primitives: AES, SHA-2/SHA-3, HMAC/HKDF, RSA, ECDSA, ECDH, X25519/X448, and ML-KEM-768 (FIPS 203).

● production-ready
Full technical detail

Key Capabilities

  • Block ciphers: AES-128/256 (CBC, CTR, GCM, CMAC); ChaCha20-Poly1305.
  • Hashing: SHA-1/256/384/512, SHA3-256/512, SHAKE-128/256, Keccak-f[1600].
  • MAC / KDF: HMAC-SHA-1/256/384/512, HKDF-SHA-256, KDF X9.63.
  • Asymmetric: RSA sign/verify (PKCS#1 v1.5 and PSS, import-only—no keygen); ECDSA over P-256/P-384/P-521 with full keygen/sign/verify; ECDH over the same curves; X25519/X448; classical Diffie-Hellman (MODP groups 5, 14–18).
  • Post-quantum: ML-KEM-768 key encapsulation (FIPS 203).
  • 3GPP algorithms: SNOW 3G core plus 128-EEA1/128-EIA1 confidentiality/integrity; SPECK32/64 lightweight cipher (used internally for SPI/token generation, not general-purpose encryption).
  • Arbitrary-precision bignum/Montgomery-arithmetic engine backing RSA, DH, and ECDSA.

Specifications

  • FIPS 197 (AES), NIST SP 800-38A/D (CBC/CTR/GCM), RFC 4493 (CMAC), RFC 8439 (ChaCha20-Poly1305)
  • FIPS 180-4 (SHA-2), FIPS 202 (SHA-3/SHAKE/Keccak), FIPS 203 (ML-KEM)
  • FIPS 186-4/186-5 (ECDSA), RFC 8017 (RSA/PKCS#1), RFC 7748 (X25519/X448), RFC 3526 (MODP DH groups), RFC 5869 (HKDF), ANSI X9.63 (KDF)
  • 3GPP TS 35.201/35.202 (SNOW 3G, 128-EEA1/128-EIA1)

Known Limitations

  • ML-KEM-768 only—ML-KEM-512 and ML-KEM-1024 are not reachable through the current build, though the underlying vendored library supports all three.
  • ECDSA nonce generation is randomized, not RFC 6979 deterministic.
  • AES-192 is not implemented (128/256 only).
  • SHA3-224 and SHA3-384 are not implemented.
  • RSA key generation is intentionally out of scope (import-only, keys arrive via X.509/PKCS#8).

KA-Net

networking

Core networking stack: ARP/NDP, ICMP, IPv4/IPv6, TCP, UDP, DHCP, and GRE. The most actively developed component, providing the networking foundation that KA-IPsec and other components build on.

● production-ready
Full technical detail

Key Capabilities

  • Full dual-stack IPv4/IPv6 with ARP, NDP (including SLAAC), and ICMPv4/ICMPv6.
  • TCP: full 11-state state machine, RFC 5681 congestion control (slow start, congestion avoidance, fast retransmit/recovery), RFC 6298 retransmission timing, delayed ACK.
  • UDP: dual-stack, with checksum handling correctly reflecting the IPv4-optional / IPv6-mandatory distinction.
  • DHCPv4 client with a full state machine including RENEWING/REBINDING.
  • GRE tunneling purpose-built for 3GPP non-3GPP-access (N3IWF/NWu) tunneling, including 5G QoS Flow Identifier marking in the GRE key field.
  • 5G Service Data Flow (SDF) classifier—a 5-tuple QoS packet classifier that assigns a 5G QoS Flow Identifier per 3GPP TS 24.501.
  • Packet-buffer pool with optional overrun/double-free/poison hardening for embedded targets.

Specifications

  • RFC 826 (ARP), RFC 791 (IPv4), RFC 8200 (IPv6), RFC 792 (ICMPv4), RFC 4443 (ICMPv6), RFC 4861 (NDP)
  • RFC 2131 (DHCPv4), RFC 768 (UDP), RFC 1071 (checksum), RFC 5681 & RFC 6298 (TCP congestion control/retransmission)
  • 3GPP TS 38.415 §5.5.3.1 and TS 24.502 (GRE/NWu tunnel format), TS 24.501 §9.11.4.13 (SDF/QFI classifier)

Known Limitations

  • No IPv4 fragmentation/reassembly, no IPv6 extension headers, no VLAN (802.1Q) support.
  • TCP has no window scaling, SACK, or timestamps (MSS option only).
  • DHCP is client-only and IPv4-only (no DHCPv6).
  • No hardware checksum offload—checksums are computed in software on all targets.

KA-IPsec

IPsec / IKEv2

An IKEv2 + ESP implementation with hybrid post-quantum key exchange. The initiator role is mature and interop-demonstrated against strongSwan; the responder role currently covers session establishment but not the full exchange set.

● initiator role production-ready — responder role in progress
Full technical detail

Key Capabilities

  • IKEv2 initiator: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA (including rekey), and INFORMATIONAL (DPD, delete, MOBIKE address update), plus RFC 9242's IKE_INTERMEDIATE exchange and RFC 9370 hybrid post-quantum key exchange.
  • ESP: tunnel mode, with AES-CBC+HMAC (encrypt-then-MAC) and AES-GCM (AEAD); RFC 4303 anti-replay window; RFC 3948 NAT-T (UDP encapsulation).
  • Message fragmentation per RFC 7383, including fragmented retransmission (initiator side).
  • Authentication: PSK, RSA (PKCS#1v1.5/PSS), and ECDSA (P-256/384/521), plus full initiator-side EAP support (method-agnostic—works for EAP-5G, EAP-AKA', etc.).
  • Certificate authentication: X.509 chain validation via KA-X509 when trust anchors are configured.
  • Demonstrated interop against strongSwan 6.x across PSK and certificate-based scenarios, over both direct and NAT-T transport, including a hybrid X25519 + ML-KEM-768 key exchange scenario.

Specifications

  • RFC 7296 (IKEv2), RFC 4303 (ESP), RFC 9242 (IKE_INTERMEDIATE), RFC 9370 (hybrid post-quantum key exchange), RFC 7383 (fragmentation)
  • RFC 3948 (NAT-T), RFC 4754 (ECDSA authentication), RFC 4555 (MOBIKE), RFC 3706 (Dead Peer Detection), RFC 3748 (EAP)
  • FIPS 203 (ML-KEM-768 as an IKEv2 key-exchange group)
Responder role is materially narrower than initiator. The responder currently handles session establishment (IKE_SA_INIT, IKE_AUTH) but not CREATE_CHILD_SA, INFORMATIONAL, MOBIKE, EAP, rekeying, or PQC-hybrid key exchange—those are initiator-only today. Integration planning should account for which role your deployment needs.

Other Known Limitations

  • ESP is tunnel-mode only (no transport mode).
  • AES-CTR and ChaCha20-Poly1305 are defined as protocol constants for ESP but have no registered crypto backend yet.
  • RFC 7427 signature authentication (method 14) is not yet implemented—PSK/RSA/ECDSA legacy methods only.
  • The PQC-hybrid interop scenario currently runs as a manual/on-demand test, not yet part of continuous automated interop testing.

KA-X509

certificates

Certificate parsing and chain validation (DER/ASN.1), currently exercised indirectly through KA-IPsec's certificate-authentication interop testing.

● functional — no dedicated unit test suite yet
Full technical detail

Key Capabilities

  • Zero-allocation, single-pass DER parser (strict DER, not BER) built specifically for the X.509 grammar.
  • Certificate field/extension parsing: SubjectAltName, BasicConstraints, KeyUsage, SubjectKeyIdentifier, AuthorityKeyIdentifier; correctly rejects unrecognized critical extensions per RFC 5280.
  • Full chain validation: path building to a configured trust anchor, expiry checking, CA/BasicConstraints enforcement, path-length constraint checking, and per-link signature verification.
  • Supports RSA- and ECDSA- (P-256/P-384/P-521) signed certificates; PKCS#8 and SEC1 private key container parsing.

Specifications

  • ITU-T X.690 / ISO/IEC 8825-1 (DER encoding rules)
  • RFC 5280 (X.509/PKIX certificate and chain profile)
  • RFC 5480, RFC 5758, RFC 4055, RFC 3279 (signature algorithm identifiers)
  • RFC 8017 (RSA/PKCS#1), RFC 5915 (EC private keys), RFC 5958 (PKCS#8 private key containers)

Known Limitations

  • No certificate revocation checking (CRL or OCSP)—a deliberate design decision favoring short-lived credentials over revocation infrastructure, not a gap to be closed.
  • No dedicated unit test suite yet; current coverage comes from KA-IPsec's certificate-authentication interop scenarios against strongSwan.
  • Post-quantum (ML-DSA) certificate signatures are roadmap, not yet implemented.
  • Issuer/subject name comparison uses byte-equality rather than full RFC 5280 §7.1 name normalization.

KA-TLS & KA-QUIC

roadmap

TLS 1.3/DTLS 1.3 support, with QUIC to follow. On the roadmap as the next addition to the KA Libraries family—not yet started.

● not yet started

Built for OEMs and integrators.

If you're building your own gateway, radio, or ruggedized device and need standards-based, post-quantum-ready secure networking without maintaining separate embedded and desktop codebases, KA Libraries are built for exactly that integration path.

Talk to us about licensing