Zeroization of sensitive data in Erlang

[Amit K]

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/bd6d79f0/attachment.htm>