Earlier in the year I was digging deep into the .Net x509certificate2 and x509certificate objects (I was building a full blown CA from scratch) and noticed that both the certificate classes serialize the private key to disk by default due to the verifiable use of Persist-Key options in the constructors of the x509certificate2 and x509certificate classes using a default option set for CspProviderFlags that does not include CspProviderFlags.CreateEphemeralKey. This is verifiable via any number of web sites that show the source for .Net as well as with many different tools should you choose to do it yourself.
Looking further, In fact these .Net objects simply seem to be wrappers for a central old style crypto32.dll cryptographic context. What worries me about this is that looking at the code deeper I find that it seems to explicitly look in an on-disk file storage for public and private keys in the getters and setters for the PublicKey field on the x509certificate2 and x509certificate object.. despite the fact that I would otherwise expect them to only exist in memory. Based on this knowledge it seems to store my private key in this storage even if I do not want it to do so, because the constructor does not allow you to change this option and turn it off based on the constructor list I am seeing when I look at the documentation; So if you set() or get() from the PrivateKey field it is really just collecting it from this file/registry store behind the scenes.
I was very happy to see the .Net Core uploaded here, but I am not able to find the System.Security.Cryptography.X509Certificates namespace or the objects so described in this repro.
Please add them so that we can as a community validate the security of these objects as they currently looks to be insecure / backdoored if one wanted to be paranoid.
Earlier in the year I was digging deep into the .Net x509certificate2 and x509certificate objects (I was building a full blown CA from scratch) and noticed that both the certificate classes serialize the private key to disk by default due to the verifiable use of Persist-Key options in the constructors of the x509certificate2 and x509certificate classes using a default option set for CspProviderFlags that does not include CspProviderFlags.CreateEphemeralKey. This is verifiable via any number of web sites that show the source for .Net as well as with many different tools should you choose to do it yourself.
Looking further, In fact these .Net objects simply seem to be wrappers for a central old style crypto32.dll cryptographic context. What worries me about this is that looking at the code deeper I find that it seems to explicitly look in an on-disk file storage for public and private keys in the getters and setters for the PublicKey field on the x509certificate2 and x509certificate object.. despite the fact that I would otherwise expect them to only exist in memory. Based on this knowledge it seems to store my private key in this storage even if I do not want it to do so, because the constructor does not allow you to change this option and turn it off based on the constructor list I am seeing when I look at the documentation; So if you set() or get() from the PrivateKey field it is really just collecting it from this file/registry store behind the scenes.
I was very happy to see the .Net Core uploaded here, but I am not able to find the System.Security.Cryptography.X509Certificates namespace or the objects so described in this repro.
Please add them so that we can as a community validate the security of these objects as they currently looks to be insecure / backdoored if one wanted to be paranoid.