[OE-core] how to *securely* do a remote install of an OE image?

[Enrico Scholz]

"Robert P. J. Day" <rpjday-L09J2beyid0N/H6P543EQg at public.gmane.org>
writes:

>   here's a puzzler someone just presented me with ... given an
> established OE build, and a way to download and install it to a
> remote system, how would one set up root and/or non-root accounts
> and passwords to then allow an *authorized* someone to log in to the
> newly-installed system and configure it?
>
>   as in, if the installed image contains a "root" account and default
> password, there is the potential of someone sneaking in there in the
> interval between installation and when the "authorized" user connects
> to do the configuration, even if the first act of the authorized user
> is to change the root password.

I do not think that this can be prevented.  When an attacker gains root
access, he can do everything with the system.  E.g. he can replace your
intrusion detection system with a custom one which does not report his
login.

You could use hardware features like burning fuses, or erasing keys in
TPM chips or increasing login counters there.  But again, an attacker
can alter the underlying login mechanism to report an untouched system.

So, you should try to prevent that an attacker can login to the systsem.


>   my immediate reaction was to use SSH keys, where the
> newly-installed system would require SSH logins, and would have to
> match the corresponding private key.

Yes; public key authentication is the way to go... You will never get
the system secure with a static default root password.

For SSH keys we are using [1] for ages.

OpenSSH supports CA keys[2]; e.g. you do not need to add every allowed
pubkey to 'authorized_keys' but only a CA pubkey.  This CA signs user
keys which are allowed to login.

Alternatively, you can implement something which sets the default
root password based on some serial number of the device.  But this is
difficultly to implement and brute force attacks might be very simple
(serial numbers are usually predictable).

Or, you can implement an OTP mechanism based on DSS or so.  E.g. device
contains a public key and presents a random number at login.  You have
to sign it with the corresponding secret key and enter it as a password.

 


Enrico

Footnotes: 
[1]  https://github.com/sigma-embedded/elito-de.sigma-chemnitz/blob/master/meta/classes/elito-image.bbclass#L56

[2]  https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

-- 
SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz