NC Bootblock Functional Specification

Contents

1.0 Overview

This technical note explains the format of boot block files as stored on the Network Computer's smartcard. It is proposed that the smartcard will contain one boot file for each interface type it is required to work with, potentially allowing one smartcard to access network services via a number of different connection strategies. Each boot file will contain all the information the NC needs to boot from the relevant network.

In particular, this specification defines the second major version of the smartcard bootblock format. A separate document is available which addresses the details of the previous format.

The smartcard will contain one boot block file for each network interface type, up to a maximum of 8 files, potentially allowing a smartcard to be used on multiple NCs with different network interfaces, depending on how it has been configured. Alternatively, multiple boot files may be specified for the same phsycial interface, allowing, for example, connection to multiple ISPs with one smartcard. The total number of bootblock files in either case must not exceed 8. The mapping from bootblock files to network interface types is kept in an index file within the NC system directory on the smartcard.

bootblock files are stored in an NC system folder within the directory hierarchy of the smartcard, as follows:

In addition, the top-level directory may contain other user-specific data, such as DES keys, NCAS session tickets, etc. Details on these files are still pending.

2.0 Outstanding issues

Parts of this specification which are italicised like this are either undecided issues or are liable to change.

• Extra hard tags will need to be added to support NC managed access protocols once these have been decided upon

3.0 Technical background

The original bootblock format comprised an ordered list of tags of fixed sizes - unused tags were left blank. A few variable length tags ( special tags ) were able to be encoded into the send-expect script which was stored on the card.

This format proved unwieldy and difficult to extend. In the light of our improved knowledge of smartcards in general and requirements in the field, a more flexible approach was implemented.

Briefly, this comprises:

1. bootblock entries are stored as tagged, byte counted entities, thus all entries are variable-length. Entry lengths may be modified up to a maximum hard limit, which is currently 65535 bytes.
2. the registry will maintain a mapping of tag names (as used by registry clients) to tag values (as stored in the bootblock). In addition, each tag mapping will include some flags, stating whether this entry is mandatory or optional, whether it is updateable, and whether it is overwriteable by a softloaded bootblock, as per the current mechanism. Maximum permissable tag data sizes will also be stored, as well as some bitfield manipulation data, so that multi-bit tag values may be dereferenced properly (eg reading the AUTH_ENABLE bit from the SYSTEM_FLAGS3 word).
3. extra tag mappings may be soft loaded into the registry from the bootblock, giving an extra degree of flexibility in the format without new registry code releases.
4. the complication of special tags is no longer needed - they can be removed from the dial up script and be replaced by regular bootblock entries.

800 bytes will be used as the new size for bootblocks on minted smartcards. This size may change as necessary - the registry is unaffected. It is also feasible for bootblocks of different sizes to be created on one smartcard during the minting process. The registry will be able to interpret bootblocks of any length, within the limits imposed by available free memory on the NC.

Note that this size restriction is the maximum total amount of data which may be stored in a given bootblock. Existing smartcards will work with the new registry software, but new bootblocks will be limited in this case to 440 bytes in total.

The registry supports a minimum of 1 and a maximum of 8 bootblocks per smartcard. The bootblock size is suggested by the formula:

  max_bootblock_size = 1 (sc_size - index_size - sizeof(other_data) )
                       -
                       8

4.0 User interface

In use, smartcard bootblocks are governed by the NC Registry module, which provides a single point of access for all operations concerning smartcard bootblocks.

5.0 Programmer interface

In use, smartcard bootblocks are governed by the NC Registry module, which provides a single point of access for all operations concerning smartcard bootblocks.

6.0 Data interchange

7.0 Data formats

The Name field denotes the tag name by which a client application refers to this field in the NC Registry.

byte
0	WORD SCF_ID	the bootblock format version number (see below)
4	ENTRY A	a tagged, byte counted bootblock entry
n	ENTRY B	etc
...	...
m	ENTRY Z	last bootblock entry
p	CKSUM	a special case tag - checksums the bootblock
rest	NULL	null entries

Bootblock entry format

TAG_ID is an 8 bit quantity, giving us 256 maximum possible tags.

TAG_LEN is a 16 bit quantity, giving a max. tag length of 65536 bytes.

Bootblock entries may appear in any order in a bootblock.

The ISP_DOMAIN, NFS_MOUNT, URL_INIT, and NCD_INFO fields have been removed from the dial-up script to become entries in their own right.

Tag IDs

Special case tag entries

NULL TAG 0x00 - to pad out bootblocks

TAG_ID          0
TAG_LEN_LSB     0
TAG_LEN_MSB     0
TAG_DATA        none

CHECKSUM TAG 0xff - terminates and verifies a bootblock

TAG_ID          0xff
TAG_LEN_LSB     4
TAG_LEN_MSB     0
TAG_DATA        (checksum word) 

NAMED_RECORD 0xfe - a datum providing it's own tag symbol.

TAG_ID          0xfe
TAG_LEN_LSB     n
TAG_LEN_MSB     m
DATA[n]         BYTE flags {
                     BIT updateable
                     BIT overrideable
                }
                BYTE[a] TAG_NAME/0
                BYTE[b] TAG_DATA

This tag will add a soft mapping to the registry's tag mapping table. The TAG_DATA may be fetched by registry clients using the TAG_NAME encoded in the entry. Soft mappings have no mandatory bit, as it doesn't make any sense in this context.

Named records may be used to add new information to a bootblock, eg an interface could store it's unique paramaters.

The system flags fields are used to encode various status options. Tag sizes and quantities listed below denote the layout of the system flags as understood by the current registry software. Briefly, system flags comprise 2 words organized as 8 bit quantities and 1 word organized as single bit flags. Note that the smartcard format version ID and the three system flags words are always present, but the remainder of the boot data block may be different for soak test or PLIP enabled smartcards.

SYSTEM_FLAGS (1)

Bits	Name	Info
0-7	IP_SCHEME	IP scheme (e.g. SLIP, PPP, ethernet etc.)
8-15	MAIL_RX	mail RX protocol (e.g. POP, SMTP
16-23	MAIL_TX	mail TX protocol (e.g. SMTP, IMAP)
24-31	BOOTP	boot protocol (e.g. BOOTP, DHCP)

SYSTEM_FLAGS (2)

Bits	Name	Info
0-7	LINK_AUTH	link authentication method (e.g. getty, PAP, CHAP)
8-15	NFS_TYPE	network filing system type (e.g. NFS, FTP)
16-23	USER_PREFS	user preferences
24-31	-	spare

SYSTEM_FLAGS (3)

Bits	Name	Info
0	SC_REGISTERED	smartcard registered
1	AUTH_ENABLE	authorization enable (ie prompt for login/passwd)
2	SOAK_ENABLE	Soak test enable
3	PLIP_ENABLE	PLIP bootstrap enable
4	STATE_ENABLE	state-saving enable
5	WRITE_ENABLE	This block is writeable
6	CLIENT_UPDATE	The bootblock is updateable en-masse by the NC
7-31	-	spare

The ISP_SCRIPT field contains a script which is responsible for taking an NC with a validated smartcard from an initially unconnected state to full network connectivity. This field is generated by a compiler which interprets a simple scripting language to produce compact byte code.

NC scripting language syntax

The NC scripting language is interpreted on a line by line basis, and supports a number of different statements, and limited conditional execution. Currently understood statements are:

Statement	Parameters	Purpose
waitfor(s,t)	string, timeout	await text from server
send(s)	string	send string to server
pause(t)	timeout	pause execution
address()	-	read IP address from server
start_ppp()	-	stop executing script, begin PPP
start_slip()	-	stop executing script, begin SLIP

In addition, the NC scripting language supports the following simple conditions, which preceed functional statements:

Statement	Condition
any	always execute
ppp	execute if configured for PPP
slip	execute if configured for SLIP
static	execute if configured for static IP addressing
dynamic	execute if configured for dynamic IP addressing

Smartcard format version ID

The smartcard format version ID (SCF_ID) is present in all bootblocks and denotes version information for the bootblock it references. In the previous (version 0) bootblock format this field was accessible as a registry tag, and defined to be a single 32 bit quantity, written to the smartcard in big-endian format. All version 0 bootblocks have the SCF_ID value 0x1, written as the byte stream 0x1, 0x0, 0x0, 0x0.

>From bootblocks of version 1 onwards, this field is redefined to be 2 16 bit quantities, the first being the bootblock minor version number and the second being the bootblock major version number. These are written to the card in the order minor version LSB, minor version MSB, major version LSB, major version MSB. Thus, the bootblock format described in this document (major version 1, minor version 0) is written to the card as the byte stream 0x0, 0x0, 0x1, 0x0.

Version 0 bootblocks are therefore interpreted by the new registry code as major version 0, minor version 1.

SCF_ID is no longer readable as a registry tag from bootblock major version 1 onwards.

8.0 External dependencies

9.0 Acceptance test

Since the bootblock format is so closely coupled with the functionality of the NCRegistry, its acceptance test is the same as the NCRegistry acceptance test.

10.0 Non compliances

11.0 Development test strategy

Since the bootblock format is so closely coupled with the functionality of the NCRegistry, its development test strategy is the same as the NCRegistry development test strategy.

12.0 Product organisation

13.0 Future enhancements

14.0 Glossary

15.0 References

16.0 History