SimpleSoftHSM

This library uses libsodium's guarded heap allocation, ED25519/ED448 challenge and respond as authentication and experimental key separation encryption/decryption to mimic HSM in a secure manner.

Steps:

1. Create an ED448 keypair or ED25519 keypair via bouncycastle or libsodium.
2. Load ED448 or ED25519 public key into the library. (Can't replace the existed public key unless the time is more than 30 minutes [Customizable])
3. Request challenge from initialization.
4. Sign the challenge via ED448 or ED25519. (The signed challenge needs to be in the form of Signature+Challenge)
5. Send signed challenge to authorize function. (Keep in mind, the signed challenge or valid authorization period lasts for no more than 8 minutes [Customizable])
6. Create another ED448 keypair or ED25519 keypair via bouncycastle or libsodium.
7. Load another ED448 or ED25519 keypair signing private key into the library. (Copies the private key and forcefully apply permission on it for details refer to libsodium's guarded heap allocation and permission) or load another ED448 or ED25519 keypair signature verification public key into the library [A must do from 0.0.9 and onwards].
8. Load any randomly generated encryption/secret key into the library. (Similar description as stated in 6th)
9. Load any randomly generated MAC key into library. (Similar description as stated in 6th)
10. Encrypt or decrypt data.
11. Clear the secret keys or private key.

Starting from version 0.0.6, the experimental domain separation within secret key encryption/decryption now has basic key commitment via digital signature signing and verification.

As key commitment was involved in symmetric encryption, the only uniqueness in this software based HSM may be its secretless based approach in authentication. The current unclear use case may be limited to only secure communication between 2 parties when key commitment was not an issue from the sender side. In addition, this also enforces a strong and secure authentication by default at the user side.

SHSM limitations

SHSM typically will be able to work fine on OSI level 1, 4 to 7 when any specific end user device turned into a server.

The actual details on how to make it work might be long and tedious.

If client side requires SHSM that does not turn any specific end user device into a server, SHSM most likely won't be able to provide OSI level 1 security.

The best SHSM can provide is software level KMS (Key Management System) + zero trust related implementations. The actual inner workings of HSM is essentially like how antivirus or virus/anticheat or cheat/DRM works which is security with obscurity. Security with obscurity refers to any security mechanisms were only proven to be secure when one doesn't know how its inner workings work.

Other information

If time and chances present, I might make this slightly more secure by making appropriate changes.

For maximum security, especially when using SHSM related functions (not necessarily my implementations), if the underlying cryptography libraries are not like libsodium try to disable the swap partition even though from a system stability point of security, it's not recommended. One has to choose between system stability and cryptographic security.