Need a secure field mechanism for setting RTC

[reuben]

Repair tech's need to set RTC. Perhaps a deployment signed bootfw.zip with a forth script with hard coded date that can be updated by deployment HQ.

[wmb@…]

I hope we talking about a deployment with their own signing keys. It is probably not a good idea for OLPC to sign a script that will force the date.

The script would be:

\ OLPC Boot script to update RTC to a hardcoded time - e.g. 2011-11-9 12:00:00
decimal
0 0 12  9 11 2011  " set-time" clock-node @ $call-method

Another alternative would be to use NTP.

This recipe assumes that you have an open access point named MYAP, and either:

a) A DHCP server that reports the IP address of an NTP time server

b) A DNS server that resolves the name "time" to the IP address of an NTP time server

c) An NTP server at the address 172.18.0.1

or

d) A router that allows access to one of 0.pool.ntp.org, 1.pool.ntp.org or 2.pool.ntp.org

\ OLPC Boot script to set RTC via NTP
essid MYAP
ntp-set-clock

Instead of the specific wireless AP, you could plug in a USB ethernet adapter, in which case the recipe would reduce to:

\ OLPC Boot script to set RTC via NTP
ntp-set-clock

The above reduced recipe would also apply if the AP SSID happened to be the OFW default "OLPCOFW".

In the event that the default NTP search order "DHCP time 172.18.0.1 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org" is unacceptable, it can be overridden with, for example:

\ OLPC Boot script to set RTC via NTP
: my-time-server  " 192.168.1.1"  ;  ' my-time-server to ntp-servers
ntp-set-clock

I'm reassigning back to reuben to choose one of those recipes, or if none is acceptable, to provide additional guidance about other constraints.

[ebordon]

Is there possible to associate the laptop with an AP than starts with the same prefix? For instance, inside school we can have 3 APs, schoolXX-1, schoolXX-2 and schoolXX-3. XX represents the school number. In this case we must to connect to AP called "school*"

\ OLPC Boot script to set RTC via NTP
essid school*
ntp-set-clock

[Quozl]

Yes, it is possible, but not in current OpenFirmware version, to associate to an AP given a prefix. This is yet to be implemented.

Meanwhile, with current version, you can provide a list of SSIDs to be tried, and they will be tried in order until one works. Disadvantage of this method is that each SSID must be listed, which may be impractical for a large deployment.

\ OLPC Boot script to set RTC via NTP
: deployment-ssids " schoolXX-1"nschoolXX-2"nschoolXX-3"nschoolXY-1"nschoolXY-2"nschoolXY-3"nOLPCOFW" ;
' deployment-ssids to default-ssids
ntp-set-clock

Output:

ok ntp-set-clock
Scan for: schoolXX-1 failed
Scan for: schoolXX-2 failed
Scan for: schoolXX-3 failed
Scan for: schoolXY-1 failed
Scan for: schoolXY-2 failed
Scan for: schoolXY-3 failed
Scan for: OLPCOFW found
Associate with: OLPCOFW 
DHCP got 10.0.0.1
2011-11-21 02:20:21 UTC
ok 

The following code fragment may be added to olpc.fth to set the SSID to the last scanned SSID that matches a prefix "school*". This works for me, but may not work where there are more networks that fit into the scan buffer.

\ OLPC Boot script to set RTC via NTP using access point prefix.
: prefix$  " school"  ;

d# 34 buffer: an-ssid
: an-ssid0  ( -- )        0 an-ssid c!  ;
: an-ssid!  ( ssid$ -- )  d# 32 min  an-ssid pack drop  ;
: an-ssid@  ( -- ssid$ )  an-ssid count  ;

dev /supplicant
: capture-ssid  ( ssid$ -- )
   \ test for hidden access point, first byte of essid is zero
   over c@  if          ( ssid$ )
      2dup
      prefix$           ( ssid$ ssid$ prefix$ )
      rot drop comp     ( ssid$ comparison )
      0= if
         \ a match by prefix, capture the ssid for re-use
         2dup an-ssid!
      then
   then                 ( ssid$ )
   type                 ( )
;
patch capture-ssid type .ie-short
dend

scan-wifi an-ssid@ $essid
ntp-set-clock

Also, if a USB to ethernet adapter is used, then no SSID is required.

Relates to #11230, request for a test that would scan for any open SSID.

[lpendas]

If i would like to test this, where should I include this code (which part of olpc.fth file?) and could it be posible to include this logic only if date has been previously set to 2000-00-00?, this is the error symptom ('invalid-system-date')

[Quozl]

Any part of an olpc.fth can be used, provided it is executed. I can't be more specific without more information; such as the existing olpc.fth file, and whether it is executed on every boot or only when a USB drive is inserted.

Yes, the code can test the year. For example, the following code tests that the year is less than 2012, and skips the ntp-set-clock if the year is 2012 or later. The code would replace the last two lines in my previous comment on this ticket.

: get-year  ( -- year )  time&date 2nip 2nip nip  ;

get-year d# 2012 < if
   scan-wifi an-ssid@ $essid
   ntp-set-clock
then

[Quozl]

Per Martin, no longer required, implemented in initramfs.

[reuben]

In conversations with deployment. They cannot use initramfs method immediately; it will have to be phased in. Consider using custom initrd method similar to Customization stick.

[wmb@…]

http://tracker.coreboot.org/trac/openfirmware/changeset/3016

That change checks in a file "oatstime.fth" which is a script that sets the clock based on a response from an OATS server. I have tested it on an unsecure laptop talking to an oatslite server running on my local net. The oatslite server was using a test private key, and the corresponding public key is inside the oatstime.fth script.

To deploy this, it would be necessary to change the public inside the script to a deployment-specific one, and to change the IP address of the server inside the script. Both are near the top of the file, clearly identified.

[Quozl]

A deployment guide has been prepared.

[reuben]

Thanks James. Is there a reason why this cannot just be included in standard firmware and check a known OLPC OATStime server?

[Quozl]

Please ensure I am CC'd on tickets you want a response on. I only just found your message.

Thanks for your question. To include it in standard firmware the requirements are:

• internet connectivity to each XO,
• a key pair,
• an OLPC OATS time server,
• a bug fix on XO-1, (it depends on random-long which is unavailable there),
• enough free space in every build of standard firmware (it costs 5k).

[Quozl]

Question was answered, there being no obvious reason why this ticket should be open, I'm closing it again. Please reopen if required.