Zeroization of sensitive data in Erlang

[Amit K]

Thank you Bob,
Note though that the "gotcha" in the documentation that says: "...there can
be strange situations in multi-threaded application where the memory is not
wiped out..." is why I think ideally something like that should be built
into the language and not provided as an external package, which at best
will work only as long the run-time obeys certain rules which are bound to
change over time, and at worst will work "most of the time" :) (as this is
not acceptable in real security applications that need to go through
security certifications).

On Sun, Oct 27, 2019 at 2:16 AM Bob Ippolito <bob@REDACTED> wrote:

> With regard to other FP languages, Haskell has a crypto library called
> raaz that makes an effort to ensure that sensitive memory gets cleared
> eagerly. Other Haskell libraries might have similar functionality, it's a
> bit easier to do with GHC than with the Erlang VM for various reasons.
>
>
> http://hackage.haskell.org/package/raaz-0.2.1/docs/Raaz-Core-Types.html#v:allocaSecureAligned
>
> On Sat, Oct 26, 2019 at 4:02 PM Amit K <klg.amit@REDACTED> wrote:
>
>> 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/d26c82d7/attachment.htm>