We are storing device credentials and private keys in the datastore, relying on aaa-encrypt-service.

Unfortunately this does not provide the the interface we need for the purposes of implementing a proper NETCONF keystore nor is it offer multiple implementations.

We have multiple use cases that need plain data protection, including, but not limited to:

• NETCONF server private keys
• NETCONF client credentials
• General datastore contents such as data marked with openconfig-hashed-value

Define an interfaces for accessing plaintext data, which is stored in some protected storage, essentially being java.util.Properties with binary keys and binary values:

// read-only access, i.e. iterator() does not support remove() and does not report duplicates
interface PlaintextStorage implements Iterable<Entry<byte[], byte[]>> {
  // equivalent to Map.get(key)
  byte @Nullable[] lookup(byte[] key);
}

// read/write access
interface MutablePlaintextStorage extends PlaintextStorage {
  // equivalent to Map.remove(key)
  byte[] removeKey(byte[] key) throws IOException;
  // equivalent to Map.remove(key, value)
  boolean removeEntry(byte[] key, byte[] value) throws IOException;
  // equivalent to Map.putIfAbsent()
  byte[] insertEntry(byte[] key, byte[] value) throws IOException;
  // equivalent to Map.put(key, value)
  byte[] putEntry(byte[] key, byte[] value) throws IOException;
}

this should reside in keystore/plaintext-api artifact. The use of byte[] for keys is there to allow extensibility, for example storing a YangInstanceIdentifier of the value.

Provide Karaf CLI commands to query and modify the contents of a (Mutable)PlaintextStorage in an keystore/plaintext-cli artifact. This should be independent of a particular implementation. Modification should only be possible it there is a MutablePlaintextStorage.

Provide an implementation of both interfaces in keystore/plaintext-localfile artifact, which will expose implementations of both interfaces to OSGi ServiceRegistry and will use a local encrypted file to store mappings.

The encryption should be based on AES-GCM-SIV. While there is no JDK implementation, BouncyCastle seems to provide it for some time now.

The encryption key being specified through OSGi Configuration Admin (supporting 32-byte and 64-byte keys only). The 96bit nonce should be generated from a SecureRandom every time the file is modified. "modified" here means that the set of key/value mappings actually change, i.e. a putEntry() with the same key and value MUST NOT result in a new file being written out.

When the file is written, the generated nonce should be stored first, followed by the encrypted blob. The order of entries in the output file needs to be also randomized (for example by collecting the results of PlaintextStorage.iterate() into a List, starting writeout at a random offset and wrapping around).

All file IO needs to happen absolutely defensively. This means that on startup, when we read it, the file needs to be locked. The writeout needs to happen safely and atomically, with an intermediate temporary file being moved into place once data is safe.. Symbolic links must never be followed.

Provide a read-only implementation of PlaintextStorage based on Kubernetes Secrets. This should be suitably integrated for the credentials use case, but generalized to support binary keys/values – perhaps through base64-encoding.