BSc. Thesis hopefully progressing with peer pressure from OUSPG Open.
Research question/problem (Msc.): How to securely deploy/provision Linux installations over insecure network/Internet using trusted starting point?
Research question/problem (BSc.): Smaller subset of the above :)
-
Layers to consider:
- Hardware, boot, OS, configuration management, application
- e.g. Physical server + USB media, iPXE, Alpine, cloud-init, Docker
- e.g. Virtualization + PXE, iPXE, Some OS, ... (See #2)
- UEFI Secure Boot out of scope?
- Trusted Computing out of scope?
- How high to climb in this thesis?
-
Chain of trust:
- We have to trust something. then pass the trust forward.
- -> boot image which GPG signed which is verified and then written into USB media (See #3)
- -> trusted USB media includes X.509 certificate pinned HTTPS URL
- -> Next step (HTTPS) could use HTTP Basic Auth or X.509 client cert for authentication
- -> HTTPS delivers e.g. GPG public keys for Alpine/CentOS/Debian repository validation
- -> drop root SSH authorized_keys into installed OS
- Lots of steps can be public on Internet
- How to deal with things which can't?
- Preshared password? X.509 client cert auth?
- What are "impossible" (beyond reasonable effort) or hard to trust?
- Hardware backdoors/vulnerabilities, OS distribution backdoors/vulns
- We have to trust something. then pass the trust forward.
-
What existing software and features there already is?
- Network booting: iPXE?
- Certificate pinning: is iPXE's pinning sufficient?
- Repository and package signing: GPG signatures? OpenBSD Signify?
- Configuration management: cloud-init? Ansible? Salt? Puppet?
- Applications: Docker?
-
Implementation
- Easy to copy and adjust ("Personal Boot Infrastructure")
- git clone, $EDITOR config, scripts/build, git push https://example.com/own/repo
- Trust of the build environment
- Building certificate pinnings with TLS MITM not worth it
- Signing keys, etc. need to be protected
- Easy to build
- Dockerize builds?
- Generate as much as possible from simple configuration
- Future work (easily out of scope for this thesis):
- Maybe everything into one USB stick to work without Internet
- Boot verifies signed commits from Git repo
- Easy to copy and adjust ("Personal Boot Infrastructure")
-
Describe experiments
- Attack the implementation
- MITM
- Broken keys
-
Describe attack vectors
- For every layer (hardware, boot, HTTPS, X.509/TLS, OS install, etc)
- What we can fight against and what we can't do
-
stuff to read:
-
Waste of time: Secure Server Provisioning and Communication Mechanism in Cloud
-
Information security auditing tool for authorities – Katakri 2015
-
x86 Network Booting: Integrating gPXE and PXELINUX
-
An Updated Performance Comparison of Virtual Machines and Linux Containers
-
An Approach for Secure Software Installation
-
signify: Securing OpenBSD From Us To You
-
Developing Software in a Hostile Environment
-
CAIA Testbed for TEACUP Experiments
- Notes: Unsecure boot (DHCP, TFTP, HTTP)
- version 1: http://caia.swin.edu.au/reports/140314B/CAIA-TR-140314B.pdf
- version 2: http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf
-
Operating System Support for Run-Time Security with a Trusted Execution Environment
-
Fedora's Secure Boot FAQ
-
Trusted Computing
-
Android Verified Boot
-
Device-Mapper's "verity" target
-
1989: License of Science in Technology. Helsinki University of Technology, department of Electrical Engineering. Hannu H. Kari: "Diskless Workstations in a Local Area Network".
-
Docker Security Cheat Sheet
-
CIS CentOS Linux 6 Benchmark
-
CIS CentOS Linux 7 Benchmark
-
CIS Distribution Independent Linux
-
Red Hat Enterprise Linux 6 Security Guide
-
Red Hat Enterprise Linux 7 Security Guide
-
Trusted images
-
ETSI GS NFV-SEC 001 V1.1.1 (2014-10): Network Functions Virtualisation (NFV); NFV Security; Problem Statement
-
Secure lazy provisioning of virtual desktops to a portable storage device a * https://dl.acm.org/citation.cfm?id=2287068&CFID=641474301&CFTOKEN=92782901
-
Characterizing and Avoiding Routing Detours Through Surveillance States
-
- iPXE management:
- iPXE supports local keyboard & display, serial console and syslog over TLS
- Maybe it's possible to use local keyb&disp, have serial console available and log everything to syslogs?
- syslogs: http://ipxe.org/cfg/syslogs