Chain of Trust

From Vexi

Contents 1 Introduction 1.1 Stage 1 1.2 Stage 2 1.3 Stage 3

Introduction

Several stages are involved in launching a Vexi application. Security is achieved by each stage verifying the next. Altogether these verifications from a chain, termed here the 'Chain of Trust'.

1. Browser verifies Launcher
2. Launcher verifies Core
3. Core verifies Vexi Archives

Each verification stage depends completely on the previous stages.

When executing a Vexi application from an untrusted source you want to allow the provider to send you Vexi code to execute - which is sandboxed and so in principal securely isolated from your system, but you do not wish to let them execute application code. The issue is that the Launcher and the Core both require access to the underlying system and so must be given permissions that would be dangerous to trust an arbitrary 3rd party with (this was shown in the past with insecure ActiveX controls).

Stage 1

These days (post the ActiveX debacle) a browser will only launch code with the users express permission (at least the first time). To help the user with his decision the dialog will indicate whether the application is signed or not, and whether the signing can be trusted.

Stage 2

For stand alone applications this is enough, but the Launcher downloads and runs Vexi. A trusted launcher that does not verify its downloads could easily be configured to download untrusted code (a modified version of the core). So it is necessary that the launcher verifies the cores. Signed cores are to be provided by the Vexi Team, who will not insert malicious code into them.

Stage 3

Less importantly it may be desirable to sign the Vexi application code. This provides additional security against 'Man in the middle attacks', and is desirable when the application itself is handling sensitive data.