CIAA principles of security

We have already outlined these principles in Sicurezza delle reti and talked about the concepts of authentication and integrity. Here we try to deepen these concepts and delve a little bit more on the attack vectors. This note mainly focuses on the principles summarized by the acronyms CIA and AAA.

Confidentiality

This is one concerns about the secrecy of the sent message. We do not want others to be able to access and read what we are doing.

Eavesdropping

This is an example of attack of confidentiality. The setting is usually like this: Eve that intercepts the message sent by each other. For example in network security, it is quite easy to eavesdrop with Wireshark or similars.

Integrity

Integrity concerns with message tampering. The received message should be the same as the sent one (man in the middle are common attacks).

Authentication

Authentication is important when we need to know to whom we are talking to. We should need to be sure that that is exactly the person (or the machine) we are trying to connect (or talk to). In this framework it is about integrity. For more in depth analysis see User authentication.

Spoofing attacks

When an attacker authenticates as another user.

Manipulation attacks

This is tampering.

Availability

The system should be available, that is accessible by its users. Attacks that prevent this cornerstone are attacks that make system less performant or inaccessible to the user.

Denial of service attacks

For example if you have limited number of ports, a common example of denial of service attack is the Syn flooding where multiple services ask to open a TCP connection, but it doesn’t continue with the communication, leaving the port occupied but useless.

Anonymity

On the internet we are not anonymous we are always tracked by ISP, cookies and many other strategies that I am not even aware of. This is a problem we we want to be anonymous, so how can we reach this target??

Anonymity by proxy

We just use another computer to repeat my information, this computer doesn’t have access to the underlying information, but it substitutes his IP to ours, so the end receiver doesn’t exactly know where the initial message comes from.

AAA principles of security

See Sicurezza OS, we describe these notions more in detail, but in the context of computer operating systems.

Authentication

Answers: who are you?

Authorization

Answers: what can you do?

Accounting

Answers: what have you done?

Other Notions

Basic Notions

Trusted Computing Base

A trusted computing base (TCB) defines the parts of the system that are trusted by the host or guest. It is important to keep in mind whose perspective are we taking.

In cloud computing systems hypervisor hardware and host software are trusted by the host, but not guest software.

Theoretical Notions of Security-20250520112631542

Attack Surface

The attack surface is the sum of the different points (attack vectors) in a computing device or network that are accessible to an unauthorized user (attacker). In cloud VMs examples are:

  • CPU instruction set for the VM
  • Hypercall API (virtual I/O, memory management, etc.)
  • Network interfaces

Dense in Depth

This is the idea where you need to be able to exploit multiple layers in order to actually gain control of the machine. One example is hypervisor models, for example with firecracker or QEMU, you should need to exploit also the hypervisor to gain control on the machine.

Threat Model

A threat model is a structured representation of all the information that affects the security of an application. Usually it is more used in academic contexts to analyze security principles of the system. It includes:

  • the assets to be protected
  • the potential threats to those assets
  • What the attacker can and cannot do (e.g. the infinite computational power assumptions, we explored in Asymmetric Cryptography proofs).
  • This helps also to define out-of-scope threats.

There is a real example of 2018 attacks on side channels (see Spectre and Meltodown. They proved that the Intel CPU microarchitecture is vulnerable to side-channel attacks. They exploited the speculative execution feature of modern processors to leak sensitive data (kernel memory) from the CPU cache, in user mode, there was no isolation anymore. This was a huge problem for cloud computing, as it affected the security of virtual machines running on shared hardware. The whole industry had to pivot to care about side-channel attacks.

Memory Safety

There are mainly two notions of memory safety:

Temporal safety:

  • No use-after-free errors
  • Meaning, every pointer should point to a valid memory address.

Spatial safety:

  • No out-of-bounds errors
  • Meaning, every pointer should point to a valid memory address within the allocated memory region.
    • It should not be able to read or write where you should not.

Most of the bugs are memory safety errors. Programs like rust solve this problem, but it is often infeasible to rewrite large codebases in memory safe languages like Rust. Other fixes are:

  • Software fault isolation
    • Example: out of bound checks on each memory access, WebAssembly does it.
  • Hardware support for memory safety:
    • Memory capabilities or protection keys see Sicurezza OS.
    • Idea -> fat pointer, that also has information about read-write range permissions.
    • One example is CHERI (university of Cambridge 2010 with ARM), now we have the first chips that have this feature.

Trust Relations

Trust in the cloud

Trust relationships

  • Everyone trusts the hardware

  • Users do not trust each other

  • Users trust the enterprise (administrators etc.)

  • Enterprise does not trust users Who has access to what?

  • Users have physical access to hardware

  • Enterprise has physical access

  • VM isolation is the de-facto standard

    • Even when the user doesn’t see/manage the VM (functions, containers)
  • Some notable exceptions:

    • Bare metal servers
    • gVisor (Google “application kernel” for Linux)
    • Drawbridge (Microsoft process-level isolation for Windows applications with a library OS)
    • Cloudflare workers (language sandbox for serverless functions, based on V8 JIT)
  • Why VMs?

    • Perception of greater security
    • Lowest common denominator when mitigating security vulnerabilities
    • Overhead has come down (e.g., AWS firecracker (Cloud Computing Services))

Trust in Enterprise systems

Trust relationships

  • Everyone trusts the hardware
  • Users do not trust each other
  • Users trust the enterprise (administrators etc.)
  • Enterprise does not trust users Who has access to what?
  • Users have physical access to hardware
  • Enterprise has physical access

Side Channel and Covert Channel

Definitions

Other Types of attacks with side channels

Notions of Security-20250527223226223

Spectre Attack

This type of attack is enabled by speculation mechanisms (branch prediction) in the CPU hardware. It is very hard to fix without degrading the performance, and changing hardware is quite costly. They basically show that with VM colocation, they are able to read kernle memory of the other VM.

Structure of the Attack Set some microarchitectural state, for example:

  • Clear 256 (these are the characters in ASCII code) cache blocks at a certain address
  • Prime a branch to taken state and read some violated memory. The idea is very simple.
  • Then you can try to extract the cache values, if there is a hit, then it is faster (slightly faster) and you know that that was the byte read.

Fixes to spectre

  • Never share at the same time the same CPU (so L1 or L2 cache) to different VMs using multithreading for example.
  • Sequential sharing is ok, you just do context switch.
  • Last level cache can be shared, the attack to this cache level is much more difficult.