You have hit one of the fundamental problems of programming as far as I’m aware. This is why some say passwords are a broken concept.

We do have a issue in our internal bugtracker that the sample private key passwords should be removed at some point in the future. A bit similar to opc.https, they “serve no purposes”. The password would only be useful if you have some external system (e.g. human) inject the password at runtime, anything else is security by obscurity (like there are different levels of that, but I would categorize more like is X possible or not possible).

So basically this is a good question, but it is a general one of “how to store secrets that must be able to be reverted to their cleartext formats” and thus outside of the SDK.

You should also define “protect from what/who” and “attack scenario” in these types of questions.

Anyway, our own applications pretty much work like the samples. For example your users might wish to change the default certificate (e.g. https://forum.prosysopc.com/forum/opc-ua-simulation-server/how-to-set-custom-server-application-instance-certificate/). As a rule of thumb the user of the application is the one who “owns the certificate”. Thus there shouldn’t be a need to protect the password from them. So the only general scenario is that someone else would steal the private key, and it shouldn’t not be useable if you do not know the password. However, if the attacker was able to access the machine (since the priv.key shouldn’t leave that), it might be impossible to protect it.

OK, it would be possible to make a system to ask the priv.key password from the user. In a client application this could be easier. But in a server app you most likely do not have that option. So, you will need to somehow store the password and have it back in the cleartext form. As far as I’m aware, there is basically almost none ways to do this in a secure way (depends on the attack scenario). IF you happen to have a TPM (Trusted Platform Module) chip on the hardware, you could in theory maybe store it there. Though, at this point my knowledge ends, I’m not sure is even that 100% secure. And it wouldn’t probably help if someone just steals the whole machine. Or like you can encrypt the disk, but then the machine wouldn’t start without human interaction and if you can have human interaction at the start you can just have a human enter the password via some prompt when the machine starts.
In theory you could store main password in code, but since java basically perfectly decompiles (and it is easy enough to look for strings in binary anyway), it doesn’t really help. Most likely if the attacker could read the priv key file, they could also read the program jar(s).

Thus, it depends on what exactly you wish to protect it from.

What do you think?

P.S.
The best way would be if the crypto operation itself and the priv key would be external e.g. within a TPM module, and then it would do all crypto operations. However we do not support this nor we have tried. Also it wouldn’t no longer be pure java at that point. So this is a theory-only level comment. Basically the operations SDK does via Java/BouncyCastle do need the key. In some distant future we might support this.