| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IRMd will now check the user UID and GID for privileged access,
avoiding unprivileged users being able to disrupt all IPC (e.g. by
shm_open the single pool and corrupting its metadata).
Non-privileged users are now limited to a PUP (per-user pool) for
sending/receiving packets. It is still created by the IRMd, but owned
by the user (uid) with 600 permissions. It does not add additional
copies for local IPC between their own processes (i.e. over the local
IPCP), but packets between processes owned by a different user or
destined over the network (other IPCPs) will incur a copy when
crossing the PUP / PUP or the PUP / GSPP boundary.
Privileged users and users in the ouroboros group still have direct
access to the GSPP (globally shared private pool) for packet transfer
that will avoid additional copies when processing packets between
processes owned by different users and to the network.
This aligns the security model with UNIX trust domains defined by UID
and GID by leveraging file permission on the pools in shared memory.
┌─────────────────────────────────────────────────────────────┐
│ Source Pool │ Dest Pool │ Operation │ Copies │
├─────────────────────────────────────────────────────────────┤
│ GSPP │ GSPP │ Zero-copy │ 0 │
│ PUP.uid │ PUP.uid │ Zero-copy │ 0 │
│ PUP.uid1 │ PUP.uid2 │ memcpy() │ 1 │
│ PUP.uid │ GSPP │ memcpy() │ 1 │
│ GSPP │ PUP.uid │ memcpy() │ 1 │
└─────────────────────────────────────────────────────────────┘
This also renames the struct ai ("application instance") in dev.c to
struct proc (process).
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds initial support for runtime-configurable encryption and
post-quantum Key Encapsulation Mechanisms (KEMs) and authentication
(ML-DSA).
Supported key exchange algorithms:
ECDH: prime256v1, secp384r1, secp521r1, X25519, X448
Finite Field DH: ffdhe2048, ffdhe3072, ffdhe4096
ML-KEM (FIPS 203): ML-KEM-512, ML-KEM-768, ML-KEM-1024
Hybrid KEMs: X25519MLKEM768, X448MLKEM1024
Supported ciphers:
AEAD: aes-128-gcm, aes-192-gcm, aes-256-gcm, chacha20-poly1305
CTR: aes-128-ctr, aes-192-ctr, aes-256-ctr
Supported HKDFs:
sha256, sha384, sha512, sha3-256, sha3-384, sha3-512,
blake2b512, blake2s256
Supported Digests for DSA:
sha256, sha384, sha512, sha3-256, sha3-384, sha3-512,
blake2b512, blake2s256
PQC support requires OpenSSL 3.4.0+ and is detected automatically via
CMake. A DISABLE_PQC option allows building without PQC even when
available.
KEMs differ from traditional DH in that they require asymmetric roles:
one party encapsulates to the other's public key. This creates a
coordination problem during simultaneous reconnection attempts. The
kem_mode configuration parameter resolves this by pre-assigning roles:
kem_mode=server # Server encapsulates (1-RTT, full forward secrecy)
kem_mode=client # Client encapsulates (0-RTT, cached server key)
The enc.conf file format supports:
kex=<algorithm> # Key exchange algorithm
cipher=<algorithm> # Symmetric cipher
kdf=<KDF> # Key derivation function
digest=<digest> # Digest for DSA
kem_mode=<mode> # Server (default) or client
none # Disable encryption
The OAP protocol is extended to negotiate algorithms and exchange KEX
data. All KEX messages are signed using existing authentication
infrastructure for integrity and replay protection.
Tests are split into base and _pqc variants to handle conditional PQC
compilation (kex_test.c/kex_test_pqc.c, oap_test.c/oap_test_pqc.c).
Bumped minimum required OpenSSL version for encryption to 3.0
(required for HKDF API). 1.1.1 is long time EOL.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the flow encryption option (cypher_s) from the qosspec.
The configuration file is configured in the security options (default
/etc/ouroboros/security/). For this poc, encryption can be disabled
client or server side by putting an enc.cfg file. If that file is
present in the client folder, the client will require encryption. If
that file is present on the server side, the server will require
encryption and reject non-encrypted flows.
Encryption is now configured outside of any application control.
Example: /etc/ouroboros/security/client/oping/enc.cfg exists:
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd(DB): Generated ephemeral keys for 87474.
irmd/oap(PP): OAP_HDR [caf203681d997941 @ 2025-09-02 17:08:05 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: [91 bytes]
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/client/oping/enc.cfg does not exist:
irmd(II): Allocating flow for 87506 to oping.
irmd(DB): File /etc/ouroboros/security/client/oping/enc.cfg does not exist.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [e84bb9d7c3d9c002 @ 2025-09-02 17:08:30 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/server/oping/enc.cfg exists:
irmd(II): Flow request arrived for oping.
irmd(DB): IPCP 88112 accepting flow 7 for oping.
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/server/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [3c717b3f31dff8df @ 2025-09-02 17:13:06 (UTC) ] <--
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
irmd(WW): Encryption required but no key provided.
The server side will pass the ECRYPT to the client:
$ oping -l
Ouroboros ping server started.
Failed to accept flow: -1008
$ oping -n oping -c 1
Failed to allocate flow: -1008.
Encryption on flows can now be changed at runtime without needing to
touch/reconfigure/restart the process.
Note: The ECRYPT result is passed on via the flow allocator responses
through the IPCP (discovered/fixed some endianness issues), but the
reason for rejecting the flow can be considered N+1 information... We
may move that information up into the OAP header at some point.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
