Zeroization of sensitive data in Erlang

Eric Pailleau eric.pailleau@REDACTED
Sun Oct 27 08:13:41 CET 2019

Note that there is a sensitive flag for processes. 
Would be neat that variables used by sensitive processes get their memory zeroed. 

Envoyé depuis mon mobile 

---- Amit K a écrit ----

>Hi Daniel,
>Good to know about that workaround, thank you. However as you already
>pointed out, I really do want to be able to handle such "sensitive"
>variables in Erlang code and use the standard "crypto" library of the OTP.
>With regards to GC - that's a great direction I think, and perhaps a more
>finer grained approach would be to add a new "sensitive" flag for typed
>variables that the GC can recognize. Then only those variables get zeroized
>when the GC runs.
>Would probably be better for performance than always zeroizing everything
>that we free...
>BTW - so far I didn't find any FP language that can do something like that,
>and please correct me if I'm wrong. It would be cool if Erlang would be the
>first to the gold here (again!) :)
>On Sun, Oct 27, 2019 at 1:42 AM Dániel Szoboszlay <dszoboszlay@REDACTED>
>> Hi Amit,
>> A NIF could use a resource object to implement a zeroable memory location.
>> The Erlang program will only see a handle to the resource, which is
>> immutable. But the contents of the object can be changed by the NIF (it's
>> better explained in the docs <>).
>> So you could create an API that looks like this for the Erlang program:
>> Handle = create_secret(Some, Input, Values),
>> ok = use_secret(Handle),
>> ok = destroy_secret(Handle), % The NIF zeroes out the memory in the
>> resource object
>> {error, destroyed} = use_secret(Handle). % The secret is no more at this
>> point
>> The big problem is that your secret shall never leave the native library.
>> E.g. you cannot hide a cryptographic key behind a zeroable resource object
>> and then pass it to the crypto library. As soon as you convert it into an
>> Erlang term, it is copied onto the non-zeroed stack or heap or a process.
>> Considering this, you may just as well use a port program to hold and work
>> with the secret outside of the Erlang VM.
>> Probably the only real solution within the VM would be to patch the GC to
>> zero any reclaimed memory. Or maybe not even the GC, but the memory
>> allocators, in case a secret is copied to some non-GC-d memory area, such
>> as an ETS table.
>> Cheers,
>> Daniel
>> On Sat, 26 Oct 2019 at 22:39, Amit K <klg.amit@REDACTED> wrote:
>>> Hi all,
>>> Concerning the security practice of Zeroizing sensitive data from memory
>>> after you're finished with it, such as Cryptographic keys, passwords, etc,
>>> I wanted to ask if any of you ever had to implement such a thing in Erlang,
>>> and if so, how? :)
>>> Also note that often this is a requirement that you must fulfill if you
>>> want your product to pass a security standard evaluation such as the
>>> "Common Criteria" one (As an example requirement see FCS_CKM_EXT.4 here:
>>> The problem of course is that in Erlang (and I suppose - FP in general)
>>> once a variable gets assigned, you are not allowed to change its value, and
>>> in particular of course overwrite it with zero bytes.
>>> One option I thought about is doing it with a NIF, but from my
>>> understanding a NIF isn't supposed to change its input values, it should
>>> treat them as constants, which understandable as well (basic FP language
>>> property).
>>> Any feedback can be helpful :)
>>> Regards,
>>> Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list