Acquire Entropy for embedded platform

Jakob Bohm jb-openssl at wisemo.com
Fri Aug 16 11:05:46 UTC 2019


Not just dedicated black box rngs in verious chips (such as
multifunction I/O chips or the old Intel BIOS chip), but also
general hardware that happens to have plenty of inherent
randomness due to its design or implementation.

The simple easy to add RNG circuits include some completely
open discrete designs if that's desired.

On 16/08/2019 12:53, Dr Paul Dale wrote:
> I agree.  Using internal hardware in the processor for entropy depends 
> on everything.  Each processor needs to be independently quantified 
> and not doing so becomes a risk assessment.
>
> As for hardware sources, they are essentially black boxes and could 
> contain anything.  It is extremely difficult, if not impossible, to 
> tell if the hardware RNG is good or not.  This doesn’t mean that they 
> should not be used, it just means that using them involves another 
> risk assessment.
>
>
>
>> On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
>> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>>
>> [Top posting for consistency]
>>
>> More than OS dependency, this depends on the exact hardware on the 
>> platform:
>> CPU, support chips, peripheral chips.   Usually some of these can provide
>> much more randomness than the highly predictable time of day/year RTC 
>> clock.
>>  And if none do, there are simple RNG hardware designs that could be 
>> added
>> in a corner of the circuit, either on a plugin board or as part of a 
>> board
>> already customized to the application.
>>
>>
>> On 16/08/2019 11:33, Dr Paul Dale wrote:
>>> Two bits of RTC is nowhere near enough entropy.  I could break two 
>>> bits by hand in a few seconds — there are only four possibilities.
>>>
>>> The best outcome is an hardware random number generator.  These are 
>>> often not readily available.
>>>
>>> Next would be waiting for enough entropy from interrupts, timers and 
>>> the like.
>>>
>>> You didn’t specify what operating system/kernel you are using so 
>>> further advise is less than useful.
>>>
>>>
>>>> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
>>>> <chitrang.srivastava at gmail.com 
>>>> <mailto:chitrang.srivastava at gmail.com> 
>>>> <mailto:chitrang.srivastava at gmail.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am working on an embedded platform and now ported openssl 1.1.1b
>>>> TLS 1.2/1.3 is working fine.
>>>> While analysing random number , Rand pool initialization calls 
>>>> where I am returning like this ,
>>>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
>>>> {
>>>>         return rand_pool_entropy_available(pool);
>>>> }
>>>> As noticed that *rand_unix.c* has an implementation wcih samples 2 
>>>> bits of RTC, would that give enough entropy or any other 
>>>> recommendation to have enough entropy for embedded platforms?
>>>>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the openssl-users mailing list