Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
t35

OETF #20: Secure boot for Lua Architectures

Recommended Posts

Abstract

This document describes how a chain of trust can be established for Lua architectures, like the real secure boot.

Later versions or documents may describe the interaction with the Open Extensible Firmware Interface, which is not considered in this version.

Later documents or versions may describe a fully secure boot compliant operating system.

 

Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

"OR" between 2 "MUST"s in a sentence means one of the things specified by "MUST" MUST be fulfilled, not both.

 

Rationale

On a server you may want all people to have general access to a computer, but in a limited way. If all people have access, someone can change the OS to include malicious programs.

Or maybe the computer only has you as a registered user, but it has network services which may be vulnerable.

To ensure that the OS has not been tampered with, you can use a chain of trust, but every link in it has to support it for it to be effective.

If an OS, BIOS or bootloader supports secure boot, you can establish a chain of trust leading back to the EEPROM in the computer.

To achieve maximum security, you can have an EEPROM with a secure boot BIOS with your public key in your inventory, so you can use it in every computer and can be sure no-one has tampered with it.

That way, you have a chain of trust that is secure up to the player inventory system of the game, which is maybe the highest the chain of trust can go.

 

Terminology

OS: Operating system. The program that is booted last.

BIOS: The program stored on the EEPROM of a computer.

bootloader: An optional program that is started by the BIOS and then boots the real OS.

private key: Data which can be used to generate a signature for other data. The private key MUST NOT be derivable from the signature. The private key MUST be the only way to generate a valid signature.

public key: Data which can be used to verify a signature. The public key MUST NOT recognize data not signed with the private key as valid and MUST NOT recognize a signature not generated with the private key as valid.

MOK: Machine owner key. The MOK is the private key with which the bootloader and OS are signed. Real secure boot only has the platform key, which users don't control, and the MOK has to be managed by shim. OpenComputers however is open, and users should decide themselves which applications to trust.

OEFI: Open Extensible Firmware Interface

 

Scope

This document describes how a conformant BIOS and bootloader and a minimally conformant OS have to behave. The behaviour of the minimally compliant OS is largely implementation-defined.

The behaviour of a fully compliant OS is not in the scope if this document.

A later document will define a fully secure boot compliant OS. When it is finished, the document will be linked here.

 

Requirements for a secure boot BIOS

A secure boot BIOS MUST save the public key corresponding to the MOK. The BIOS MUST store the public key in such a way that it cannot be altered by an unauthorized user, OR it MUST be able to know when the public key was changed and refuse to boot with an error message.

An example of that would be making the EEPROM read-only.

The BIOS MAY allow an authorized user to change the MOK after secure boot has been set up. The key MUST be set when setting up secure boot.

The BIOS MUST NOT boot a bootloader or OS that has no valid signature and it.

If the BIOS cannot verify signatures (e.g. because the computer has no data card), it MUST tell the user why it cannot verify signatures at the moment.

The BIOS MUST give the OS or bootloader a global variable called "secure_boot" if secure boot is enabled. The BIOS MUST NOT give the OS or bootloader a global variable called "secure_boot" if secure boot is disabled.

The "secure_boot" variable MUST be a table.

The table MUST contain the entry "keyformat", which describes what type of key the public key is.

The BIOS MUST support the key types "ec-public-256" and "ec-public-384" (these are the key type and the lengths that data cards support).

The table MUST contain the entry "pubkey", which stores the key. If the key type is "ec-public-256" or "ec-public-384", the key MUST be in the userdata format returned by the data card, not in the string representation.

The BIOS MAY support additional key types.

The BIOS MAY call itself "secure boot compliant" or "secure boot BIOS".

 

Requirements for a secure boot bootloader

The bootloader MUST NOT boot an OS or another bootloader that has no valid signature.

The bootloader MUST support the key types "ec-public-256" and "ec-public-384".

If the bootloader doesn't support the key type of the BIOS, it MUST NOT continue booting and MUST tell the user it doesn't support the key type.

The bootloader MAY store additional public keys and accept signatures verified with them as valid signatures. If an OS or bootloader is booted with a signature verified with a key different than the MOK, the "keyformat" and "pubkey" fields of the table "secure_boot" MUST be changed to match the key.

The bootloader MUST store the additional keys in such a way that they cannot be altered by an unauthorized user, OR it MUST be able to know when a key was changed and MUST NOT view a signature from that key as valid if it was changed.

The additional keys MAY be signed with the MOK to ensure their validity.

The bootloader MAY allow an authorized user to change the additional keys after secure boot has been set up.

The BIOS MAY call itself "secure boot compliant" or "secure boot bootloader".

 

Requirements for a minimal secure boot OS

The OS MUST support the key types "ec-public-256" and "ec-public-384".

If the OS doesn't support the key type of the BIOS, it MUST NOT continue booting and MUST tell the user it doesn't support the key type.

The OS MUST give applications a way to check if secure boot is enabled, and if it is, give the applications access to the key format and the public key.

The OS SHOULD prevent certain actions, such as loading unsigned OS modules. Which actions should be prevented is not in the scope of this document.

The OS MUST tell the user which actions are prevented when in secure boot mode and explain the security implications to the user.

The OS MAY call itself "minimally secure boot compliant".

 

Requirements for a secure boot OS

The requirements a fully secure boot compliant OS MUST fulfill are not in the scope of this document.

The OS MAY call itself "secure boot compliant" or "fully secure boot compliant".

A later document will define a fully secure boot compliant OS. When it is finished, the document will be linked here.

 

Reference implementation

A reference implementation of a secure boot BIOS can be found here:

https://github.com/oc-t35/secure-boot-lua-BIOS

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.