[ECOS] Protecting RedBoot in the field

[ECOS] Protecting RedBoot in the field

[Andrew Lunn]

Hi Folks

The devices we send out into the field still have redboot installed on
them. We are thinking this is a bit dangerous. Anyone can connect to
the serial port and hijack the devices, download tetris, destroy the
flash etc.

I don't want to remove the functionality of redboot. Its useful for
getting dead devices back to life and we do all our development work
with redboot starting the system. I don't like the idea of change to a
ROMRAM application.

Putting a password login onto the console seems the obvious
solution. Does anyone have any other ideas or other solutions they are
already using?

        Thanks
                Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Daniel Morris]

On a related note, many flash devices have a sector protect facility
to prevent modification of whole devices and/or critical segments. I 
know of at least two applications in the aeronautical field that had 
been corrupted due to wild electrostatic conditions induced at take 
off - putting the write/erase patterns onto the bus. These were a 
few years ago & perhaps shielding/EMC awareness has improved, but
it is worth remembering even that it is not only loosers that can be 
hostile.

 Daniel

On Mon, Oct 28, 2002 at 11:31:11AM +0100, Andrew Lunn wrote:
> Hi Folks
> 
> The devices we send out into the field still have redboot installed on
> them. We are thinking this is a bit dangerous. Anyone can connect to
> the serial port and hijack the devices, download tetris, destroy the
> flash etc.
> 
> I don't want to remove the functionality of redboot. Its useful for
> getting dead devices back to life and we do all our development work
> with redboot starting the system. I don't like the idea of change to a
> ROMRAM application.
> 
> Putting a password login onto the console seems the obvious
> solution. Does anyone have any other ideas or other solutions they are
> already using?
> 
>         Thanks
>                 Andrew
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Gary Thomas]

On Mon, 2002-10-28 at 03:31, Andrew Lunn wrote:
> Hi Folks
> 
> The devices we send out into the field still have redboot installed on
> them. We are thinking this is a bit dangerous. Anyone can connect to
> the serial port and hijack the devices, download tetris, destroy the
> flash etc.
> 
> I don't want to remove the functionality of redboot. Its useful for
> getting dead devices back to life and we do all our development work
> with redboot starting the system. I don't like the idea of change to a
> ROMRAM application.
> 
> Putting a password login onto the console seems the obvious
> solution. Does anyone have any other ideas or other solutions they are
> already using?

Most units in the field that use RedBoot either don't have a serial
port at all (!) or simply "cover it up" for production use.

That said, I think a password (stored in 'fconfig') would be a
great addition.

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Andrew Lunn]

> That said, I think a password (stored in 'fconfig') would be a
> great addition.

I wondered about encrypting the passwd so its not plain text. But does
that get is into US export regulation problems? Is crypt(3) still
under restrictions? Can anybody suggest an alternative?

      Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Gary Thomas]

On Mon, 2002-10-28 at 08:17, Andrew Lunn wrote:
> > That said, I think a password (stored in 'fconfig') would be a
> > great addition.
> 
> I wondered about encrypting the passwd so its not plain text. But does
> that get is into US export regulation problems? Is crypt(3) still
> under restrictions? Can anybody suggest an alternative?

The restrictions on most simple algorithms (IIRC less than 56 bit
keys) have been lifted for a couple of years.

That said, the encryption could be quite simple as this is only
a first level defense.  Anyone who could be attempting to use
this to get into RedBoot will most likely have physical access
to the unit anyway, so heroic attempts at security probably are
not warranted.  (Of course, feel free to contradict me on this)

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Jonathan Larmour]

Gary Thomas wrote:
> On Mon, 2002-10-28 at 08:17, Andrew Lunn wrote:
> 
>>>That said, I think a password (stored in 'fconfig') would be a
>>>great addition.
>>
>>I wondered about encrypting the passwd so its not plain text. But does
>>that get is into US export regulation problems? Is crypt(3) still
>>under restrictions? Can anybody suggest an alternative?
> 
> 
> The restrictions on most simple algorithms (IIRC less than 56 bit
> keys) have been lifted for a couple of years.

Alas it isn't as simple as that: there are different regulations depending 
on the nature of the thing containing encryption and key length among 
other things. In summary, you can be granted an export licence for freely 
downloadable software fairly readily, but each submission requires a 
submission to the US BXA. Any times the encryption code is modified a new 
application is required. Who knows what happens with download mirror sites.

Note that things would become more difficult for commercial 
redistributors/vendors of eCos (especially with the GPL involved) if stuff 
like OpenSSL was properly integrated. It would no longer have the 
exemptions associated with being "freely available", primarily the onerous 
post-export reporting ones.

After a google, this is the best summary of the current status I could find:
http://www.fas.org/irp/news/2000/01/000113-crypto-bxa.htm

That's why (unfortunately) OpenSSL is best left distributed only in the 
Free world.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Gary Thomas]

On Mon, 2002-11-04 at 22:40, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > On Mon, 2002-10-28 at 08:17, Andrew Lunn wrote:
> > 
> >>>That said, I think a password (stored in 'fconfig') would be a
> >>>great addition.
> >>
> >>I wondered about encrypting the passwd so its not plain text. But does
> >>that get is into US export regulation problems? Is crypt(3) still
> >>under restrictions? Can anybody suggest an alternative?
> > 
> > 
> > The restrictions on most simple algorithms (IIRC less than 56 bit
> > keys) have been lifted for a couple of years.
> 
> Alas it isn't as simple as that: there are different regulations depending 
> on the nature of the thing containing encryption and key length among 
> other things. In summary, you can be granted an export licence for freely 
> downloadable software fairly readily, but each submission requires a 
> submission to the US BXA. Any times the encryption code is modified a new 
> application is required. Who knows what happens with download mirror sites.
> 
> Note that things would become more difficult for commercial 
> redistributors/vendors of eCos (especially with the GPL involved) if stuff 
> like OpenSSL was properly integrated. It would no longer have the 
> exemptions associated with being "freely available", primarily the onerous 
> post-export reporting ones.
> 
> After a google, this is the best summary of the current status I could find:
> http://www.fas.org/irp/news/2000/01/000113-crypto-bxa.htm
> 
> That's why (unfortunately) OpenSSL is best left distributed only in the 
> Free world.

The way I read it, code which was derived from open source is
exempt, period.  Look at TSU -- §§740.13(e) on this page:
  http://www.bxa.doc.gov/Encryption/lechart1.htm
straight from the BXA themselves.

-- 
------------------------------------------------------------
Gary Thomas                  |
eCosCentric, Ltd.            |  
+1 (970) 229-1963            |  eCos & RedBoot experts
gthomas@ecoscentric.com      |
http://www.ecoscentric.com/  |
------------------------------------------------------------


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Jonathan Larmour]

Gary Thomas wrote:
> On Mon, 2002-11-04 at 22:40, Jonathan Larmour wrote:
> 
>>Alas it isn't as simple as that: there are different regulations depending 
>>on the nature of the thing containing encryption and key length among 
>>other things. In summary, you can be granted an export licence for freely 
>>downloadable software fairly readily, but each submission requires a 
>>submission to the US BXA. Any times the encryption code is modified a new 
>>application is required. Who knows what happens with download mirror sites.
>>
>>Note that things would become more difficult for commercial 
>>redistributors/vendors of eCos (especially with the GPL involved) if stuff 
>>like OpenSSL was properly integrated. It would no longer have the 
>>exemptions associated with being "freely available", primarily the onerous 
>>post-export reporting ones.
>>
>>After a google, this is the best summary of the current status I could find:
>>http://www.fas.org/irp/news/2000/01/000113-crypto-bxa.htm
>>
>>That's why (unfortunately) OpenSSL is best left distributed only in the 
>>Free world.
> 
> 
> The way I read it, code which was derived from open source is
> exempt, period.  Look at TSU -- §§740.13(e) on this page:
>   http://www.bxa.doc.gov/Encryption/lechart1.htm
> straight from the BXA themselves.

Actually, we might be agreeing :-). That also says in the final 
"Restrictions" column that it requires "Notification or copy by time of 
export" which is what I meant - the "submission" I referred to above.

As for incorporating OpenSSL into eCos, yes we could use this for the free 
eCos. The problem arises when a US company wants to distribute its own 
eCos.... say you wanted to distribute your eCos (including openSSL) 
privately to me.... then the encryption in that isn't in the same place 
nor applied for by the same entity as the submission that we would make 
for sources.redhat.com. And as it isn't publically available (despite 
being derived from a publically available source, but if that was all that 
was required no-one would need this ever for OpenSSL), it doesn't come 
under the exemption:

http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html

Or at http://w3.access.gpo.gov/bis/ear/txt/740.txt section 740.13(e)(3) is 
particularly relevant:

"Encryption software controlled
under ECCN 5D002 that would not be considered
publicly available, but which incorporates or is
specially designed to use encryption software that
would be considered publicly available, is not
eligible for export or reexport under this paragraph (e)".

where paragraph (e) is the exemption for publically available code.

In fact one company selling to the other privately doesn't even get the 
"mass market" exemption according to the rigid definitions in section 740.

Jifl
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Protecting RedBoot in the field

[Andrew Lunn]

> You could just store it as plain text, or if you must disguise the password,
> you could use base64 encoding.  I'm concerned with code bloat in RedBoot
> (it's already twice the size I would like).
> 
> Jay Foster

What ever i do will be optional. It should add zero size for those who
don't want it.

If redboot is too big for you, disable parts of it. Nearly every
command can be removed etc...

        Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Protecting RedBoot in the field

[Jay Foster]

-----Original Message-----
From: Andrew Lunn [mailto:andrew.lunn@ascom.ch]
Sent: Monday, October 28, 2002 7:18 AM
To: Gary Thomas
Cc: eCos Disuss
Subject: Re: [ECOS] Protecting RedBoot in the field


> That said, I think a password (stored in 'fconfig') would be a
> great addition.

I wondered about encrypting the passwd so its not plain text. But does
that get is into US export regulation problems? Is crypt(3) still
under restrictions? Can anybody suggest an alternative?

      Andrew

You could just store it as plain text, or if you must disguise the password,
you could use base64 encoding.  I'm concerned with code bloat in RedBoot
(it's already twice the size I would like).

Jay Foster

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss