Zeroization of sensitive data in Erlang

[Bob Ippolito]

Sure, that’s why I said it makes an effort. Most languages with threads (or
even certain uses of signals) can have similar edge cases. Having the edge
cases documented such that they can be avoided is likely the best you’re
going to find anywhere.

On Sat, Oct 26, 2019 at 17:34 Amit K <klg.amit@REDACTED> wrote:

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