Zeroization of sensitive data in Erlang

[Amit K]

Hi Eric,
I like your suggestion, but would it be a reasonable performance overhead,
especially for those who are already using the sensitive flag for certain
processes? If the answer is likely yes I may well try to implement this and
possibly create a PR for that :)

On Sun, Oct 27, 2019 at 9:21 AM Eric Pailleau <eric.pailleau@REDACTED>
wrote:

> Hi,
>
> 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>
> wrote:
>
>> 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
>> <http://erlang.org/doc/man/erl_nif.html>). 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:
>>> https://www.commoncriteriaportal.org/files/ppfiles/pp_nd_v1.0.pdf).
>>>
>>> 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: <http://erlang.org/pipermail/erlang-questions/attachments/20191027/a6008783/attachment.htm>