DOCSLIB.ORG

FIPS 140-2 Non-Proprietary Security Policy

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Kernel Crypto API Cryptographic Module version 1.0

FIPS 140-2 Non-Proprietary Security Policy

Version 1.3
Last update: 2020-03-02

Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.com

© 2020 Canonical Ltd. / atsec information security
This document can be reproduced and distributed only whole and intact, including this copyright notice.

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

Table of Contents

1. Cryptographic Module Specification .....................................................................................................5

1.1. Module Overview .....................................................................................................................................5 1.2. Modes of Operation .................................................................................................................................9

2. Cryptographic Module Ports and Interfaces ........................................................................................10 3. Roles, Services and Authentication .....................................................................................................11

3.1. Roles .......................................................................................................................................................11 3.2. Services...................................................................................................................................................11 3.3. Algorithms ..............................................................................................................................................13
3.3.1. 3.3.2. 3.3.3. 3.3.4.
Ubuntu 16.04 LTS 64-bit Little Endian Running on POWER System...............................................13 Ubuntu 16.04 LTS 64-bit Running on Intel® Xeon® Processor .......................................................17 Ubuntu 16.04 LTS 64-bit Running on z System...............................................................................24 Non-Approved Algorithms..............................................................................................................27
3.4. Operator Authentication ........................................................................................................................29

4. Physical Security ................................................................................................................................30 5. Operational Environment...................................................................................................................31

5.1. Applicability ............................................................................................................................................31 5.2. Policy.......................................................................................................................................................31

6. Cryptographic Key Management.........................................................................................................32

6.1. Random Number Generation.................................................................................................................32 6.2. Key Generation.......................................................................................................................................33 6.3. Key Agreement / Key Transport / Key Derivation ..................................................................................33 6.4. Key Entry / Output..................................................................................................................................33 6.5. Key / CSP Storage....................................................................................................................................33 6.6. Key / CSP Zeroization..............................................................................................................................33

7. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ............................................34 8. Self-Tests...........................................................................................................................................35

8.1. Power-Up Tests.......................................................................................................................................35
8.1.1. 8.1.2.
Integrity Tests.................................................................................................................................35 Cryptographic Algorithm Tests.......................................................................................................35
8.2. On-Demand Self-Tests............................................................................................................................37 8.3. Conditional Tests ....................................................................................................................................37

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 2 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

9. Guidance ...........................................................................................................................................38

9.1. Crypto Officer Guidance.........................................................................................................................38
9.1.1. 9.1.2.
Module Installation.........................................................................................................................38 Operating Environment Configuration...........................................................................................38
9.2. User Guidance ........................................................................................................................................39
9.2.1. 9.2.2. 9.2.3. 9.2.4.
AES GCM IV.....................................................................................................................................39 AES XTS ...........................................................................................................................................40 Triple-DES encryption.....................................................................................................................40 Handling FIPS Related Errors ..........................................................................................................40

10. Mitigation of Other Attacks................................................................................................................41

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 3 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

Copyrights and Trademarks

Ubuntu and Canonical are registered trademarks of Canonical Ltd. Linux is a registered trademark of Linus Torvalds.

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 4 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

1. Cryptographic Module Specification

This document is the non-proprietary FIPS 140-2 Security Policy for version 1.0 of the Ubuntu Kernel Crypto API Cryptographic Module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a Security Level 1 software module.

The following sections describe the cryptographic module and how it conforms to the FIPS 140-2 specification in each of the required areas.

1.1. Module Overview

The Ubuntu Kernel Crypto API Cryptographic Module (hereafter referred to as “the module”) is a software module running as part of the operating system kernel that provides general purpose cryptographic services. The module provides cryptographic services to kernel applications through a C language Application Program Interface (API) and to applications running in the user space through an AF_ALG socket type interface. The module utilizes processor instructions to optimize and increase the performance of cryptographic algorithms.

For the purpose of the FIPS 140-2 validation, the module is a software-only, multi-chip standalone cryptographic module validated at overall security level 1. The table below shows the security level claimed for each of the eleven sections that comprise the FIPS 140-2 standard.

  • FIPS 140-2 Section
  • Security

Level

123456789
Cryptographic Module Specification Cryptographic Module Ports and Interfaces Roles, Services and Authentication Finite State Model
1111

  • Physical Security
  • N/A

  • 1
  • Operational Environment

Cryptographic Key Management EMI/EMC
11

  • Self-Tests
  • 1

10 Design Assurance 11 Mitigation of Other Attacks Overall Level
1N/A
1

Table 1 - Security Levels

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 5 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

The cryptographic logical boundary consists of all kernel objects and the integrity check files used for Integrity Tests. The table below enumerates the components that comprise the module with their location in the target platform.

  • Description
  • Components

  • Integrity test utility
  • /usr/bin/sha512hmac

Integrity check HMAC file for the integrity test utility.
/usr/bin/.sha512hmac.hmac

  • Static kernel binary
  • On Power system:

/boot/vmlinux-4.4.0-1002-fips

On x86_64 and z system: /boot/vmlinuz-4.4.0-1002-fips

Integrity check HMAC file for static kernel binary
On Power system: /boot/.vmlinux-4.4.0-1002-fips.hmac

On x86_64 and z system: /boot/.vmlinuz-4.4.0-1002-fips.hmac

Cryptographic kernel object files
On Power system: /lib/modules/4.4.0-1002-fips/kernel/crypto/*.ko /lib/modules/4.4.0-1002-fips/kernel/arch/powerpc/crypto/*.ko /lib/modules/4.4.0-1002-fips/kernel/drivers/crypto/vmx/*.ko

On x86_64 system: /lib/modules/4.4.0-1002-fips/kernel/crypto/*.ko /lib/modules/4.4.0-1002-fips/kernel/arch/x86/crypto/*.ko

On z system: /lib/modules/4.4.0-1002-fips/kernel/crypto/*.ko /lib/modules/4.4.0-1002-fips/kernel/arch/s390/crypto/*.ko

Table 2 - Cryptographic Module Components

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 6 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

The software block diagram below shows the module, its interfaces with the operational environment and the delimitation of its logical boundary, comprised of all the components within the BLUE box.

Figure 1 - Software Block Diagram

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 7 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

The module is aimed to run on a general purpose computer (GPC); the physical boundary of the module is the tested platforms. Figure 2 shows the major components of a GPC.

Figure 2 - Cryptographic Module Physical Boundary

The module has been tested on the test platforms shown below.

  • Test Platform
  • Processor
  • Processor
  • Test Configuration

Architecture

IBM Power System S822L (PowerNV 8247-22L)

  • POWER8
  • Power system

Power system Power system
Ubuntu 16.04 LTS 64-bit Little Endian with/without Power ISA 2.07 (PAA)

IBM Power System S822LC (PowerNV 8001-22C)
POWER8 POWER8
Ubuntu 16.04 LTS 64-bit Little Endian with/without Power ISA 2.07 (PAA)

IBM Power System S822LC (PowerNV 8335-GTB)
Ubuntu 16.04 LTS 64-bit Little Endian with/without Power ISA 2.07 (PAA)

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 8 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

  • Test Platform
  • Processor
  • Processor
  • Test Configuration

Architecture

Supermicro SYS-5018R-WR IBM z13
Intel® Xeon® CPU x86_64 E5-2620v3
Ubuntu 16.04 LTS 64-bit with/without AES-NI (PAA)

  • z13
  • z System

x86_64
Ubuntu 16.04 LTS 64-bit running on LPAR with/without CPACF (PAI)

Supermicro A1SAi

Supermicro SMX11SPL-F

  • Intel®Atom™
  • Ubuntu 16.04 LTS 64-bit with/without

  • AES-NI (PAA)
  • C2750

Intel® Xeon® Silver 4216

  • x86_64
  • Ubuntu 16.04 LTS 64-bit with/without

AES-NI (PAA)

Table 3 - Tested Platforms

Note: Per [FIPS 140-2_IG] G.5, the Cryptographic Module Validation Program (CMVP) makes no statement as to the correct operation of the module or the security strengths of the generated keys when this module is ported and executed in an operational environment not listed on the validation certificate.

1.2. Modes of Operation

The module supports two modes of operation:



FIPS mode (the Approved mode of operation): only approved or allowed security functions with sufficient security strength can be used.

non-FIPS mode (the non-Approved mode of operation): only non-approved security functions can be used.

The module enters FIPS mode after power-up tests succeed. Once the module is operational, the mode of operation is implicitly assumed depending on the security function invoked and the security strength of the cryptographic keys.

Critical security parameters used or stored in FIPS mode are not used in non-FIPS mode, and vice versa.

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 9 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

2. Cryptographic Module Ports and Interfaces

As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-2 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs.

The logical interfaces are the API through which kernel modules request services, and the AF_ALG type socket that allows the applications running in the user space to request cryptographic services from the module. The following table summarizes the four logical interfaces:

FIPS Interface

Data Input

  • Physical Port
  • Logical Interface

Keyboard Display
API input parameters from kernel system calls, AF_ALG type socket.

Data Output

Control Input
API output parameters from kernel system calls, AF_ALG type socket.

  • Keyboard
  • API function calls, API input parameters for

control from kernel system calls, AF_ALG type socket, kernel command line.

Status Output

Power Input

  • Display
  • API return codes, AF_ALG type socket,

kernel logs.

  • PC Power Supply Port
  • N/A

Table 4 - Ports and Interfaces

© 2020 Canonical Ltd. / atsec information security

  • This document can be reproduced and distributed only whole and intact, including this copyright notice.
  • 10 of 46

  • Kernel Crypto API Cryptographic Module
  • FIPS 140-2 Non-Proprietary Security Policy

3. Roles, Services and Authentication

3.1. Roles

The module supports the following roles:

User role: performs cryptographic services (in both FIPS mode and non-FIPS mode), key zeroization, show status, and on-demand self-test.

Crypto Officer role: performs module installation and initialization.
The User and Crypto Officer roles are implicitly assumed by the entity accessing the module services.

Recommended publications
  • Fast Hashing and Stream Encryption with Panama

    Fast Hashing and Stream Encryption with Panama

    Fast Hashing and Stream Encryption with Panama Joan Daemen1 and Craig Clapp2 1 Banksys, Haachtesteenweg 1442, B-1130 Brussel, Belgium [email protected] 2 PictureTel Corporation, 100 Minuteman Rd., Andover, MA 01810, USA [email protected] Abstract. We present a cryptographic module that can be used both as a cryptographic hash function and as a stream cipher. High performance is achieved through a combination of low work-factor and a high degree of parallelism. Throughputs of 5.1 bits/cycle for the hashing mode and 4.7 bits/cycle for the stream cipher mode are demonstrated on a com- mercially available VLIW micro-processor. 1 Introduction Panama is a cryptographic module that can be used both as a cryptographic hash function and a stream cipher. It is designed to be very efficient in software implementations on 32-bit architectures. Its basic operations are on 32-bit words. The hashing state is updated by a parallel nonlinear transformation, the buffer operates as a linear feedback shift register, similar to that applied in the compression function of SHA [6]. Panama is largely based on the StepRightUp stream/hash module that was described in [4]. Panama has a low per-byte work factor while still claiming very high security. The price paid for this is a relatively high fixed computational overhead for every execution of the hash function. This makes the Panama hash function less suited for the hashing of messages shorter than the equivalent of a typewritten page. For the stream cipher it results in a relatively long initialization procedure. Hence, in applications where speed is critical, too frequent resynchronization should be avoided.
  • The Xen Port of Kexec / Kdump a Short Introduction and Status Report

    The Xen Port of Kexec / Kdump a Short Introduction and Status Report

    The Xen Port of Kexec / Kdump A short introduction and status report Magnus Damm Simon Horman VA Linux Systems Japan K.K. www.valinux.co.jp/en/ Xen Summit, September 2006 Magnus Damm ([email protected]) Kexec / Kdump Xen Summit, September 2006 1 / 17 Outline Introduction to Kexec What is Kexec? Kexec Examples Kexec Overview Introduction to Kdump What is Kdump? Kdump Kernels The Crash Utility Xen Porting Effort Kexec under Xen Kdump under Xen The Dumpread Tool Partial Dumps Current Status Magnus Damm ([email protected]) Kexec / Kdump Xen Summit, September 2006 2 / 17 Introduction to Kexec Outline Introduction to Kexec What is Kexec? Kexec Examples Kexec Overview Introduction to Kdump What is Kdump? Kdump Kernels The Crash Utility Xen Porting Effort Kexec under Xen Kdump under Xen The Dumpread Tool Partial Dumps Current Status Magnus Damm ([email protected]) Kexec / Kdump Xen Summit, September 2006 3 / 17 Kexec allows you to reboot from Linux into any kernel. as long as the new kernel doesn’t depend on the BIOS for setup. Introduction to Kexec What is Kexec? What is Kexec? “kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is indepedent of the system firmware...” Configuration help text in Linux-2.6.17 Magnus Damm ([email protected]) Kexec / Kdump Xen Summit, September 2006 4 / 17 . as long as the new kernel doesn’t depend on the BIOS for setup. Introduction to Kexec What is Kexec? What is Kexec? “kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel.
  • The Linux 2.4 Kernel's Startup Procedure

    The Linux 2.4 Kernel's Startup Procedure

    The Linux 2.4 Kernel’s Startup Procedure William Gatliff 1. Overview This paper describes the Linux 2.4 kernel’s startup process, from the moment the kernel gets control of the host hardware until the kernel is ready to run user processes. Along the way, it covers the programming environment Linux expects at boot time, how peripherals are initialized, and how Linux knows what to do next. 2. The Big Picture Figure 1 is a function call diagram that describes the kernel’s startup procedure. As it shows, kernel initialization proceeds through a number of distinct phases, starting with basic hardware initialization and ending with the kernel’s launching of /bin/init and other user programs. The dashed line in the figure shows that init() is invoked as a kernel thread, not as a function call. Figure 1. The kernel’s startup procedure. Figure 2 is a flowchart that provides an even more generalized picture of the boot process, starting with the bootloader extracting and running the kernel image, and ending with running user programs. Figure 2. The kernel’s startup procedure, in less detail. The following sections describe each of these function calls, including examples taken from the Hitachi SH7750/Sega Dreamcast version of the kernel. 3. In The Beginning... The Linux boot process begins with the kernel’s _stext function, located in arch/<host>/kernel/head.S. This function is called _start in some versions. Interrupts are disabled at this point, and only minimal memory accesses may be possible depending on the capabilities of the host hardware.
  • Kdump, a Kexec-Based Kernel Crash Dumping Mechanism

    Kdump, a Kexec-Based Kernel Crash Dumping Mechanism

    Kdump, A Kexec-based Kernel Crash Dumping Mechanism Vivek Goyal Eric W. Biederman Hariprasad Nellitheertha IBM Linux NetworkX IBM [email protected] [email protected] [email protected] Abstract important consideration for the success of a so- lution has been the reliability and ease of use. Kdump is a crash dumping solution that pro- Kdump is a kexec based kernel crash dump- vides a very reliable dump generation and cap- ing mechanism, which is being perceived as turing mechanism [01]. It is simple, easy to a reliable crash dumping solution for Linux R . configure and provides a great deal of flexibility This paper begins with brief description of what in terms of dump device selection, dump saving kexec is and what it can do in general case, and mechanism, and plugging-in filtering mecha- then details how kexec has been modified to nism. boot a new kernel even in a system crash event. The idea of kdump has been around for Kexec enables booting into a new kernel while quite some time now, and initial patches for preserving the memory contents in a crash sce- kdump implementation were posted to the nario, and kdump uses this feature to capture Linux kernel mailing list last year [03]. Since the kernel crash dump. Physical memory lay- then, kdump has undergone significant design out and processor state are encoded in ELF core changes to ensure improved reliability, en- format, and these headers are stored in a re- hanced ease of use and cleaner interfaces. This served section of memory. Upon a crash, new paper starts with an overview of the kdump de- kernel boots up from reserved memory and pro- sign and development history.
  • Cryptanalysis of MD4

    Cryptanalysis of MD4

    Cryptanalysis of MD4 Hans Dobbertin German Information Security Agency P. O. Box 20 03 63 D-53133 Bonn e-maih dobbert inQskom, rhein .de Abstract. In 1990 Rivest introduced the hash function MD4. Two years later RIPEMD, a European proposal, was designed as a stronger mode of MD4. Recently wc have found an attack against two of three rounds of RIPEMD. As we shall show in the present note, the methods developed to attack RIPEMD can be modified and supplemented such that it is possible to break the full MD4, while previously only partial attacks were known. An implementation of our attack allows to find collisions for MD4 in a few seconds on a PC. An example of a collision is given demonstrating that our attack is of practical relevance. 1 Introduction Rivest [7] introduced the hash function MD4 in 1990. The MD4 algorithm is defined as an iterative application of a three-round compress function. After an unpublished attack on the first two rounds of MD4 due to Merkle and an attack against the last two rounds by den Boer and Bosselaers [2], Rivest introduced the strengthened version MD5 [8]. The most important difference to MD4 is the adding of a fourth round. On the other hand the stronger mode RIPEMD [1] of MD4 was designed as a European proposal in 1992. The compress function of RIPEMD consists of two parallel lines of a modified version of the MD4 compress function. In [4] we have shown that if the first or the last round of its compress function is omitted, then RIPEMD is not collision-free.
  • Efficient Collision Attack Frameworks for RIPEMD-160

    Efficient Collision Attack Frameworks for RIPEMD-160

    Efficient Collision Attack Frameworks for RIPEMD-160 Fukang Liu1;6, Christoph Dobraunig2;3, Florian Mendel4, Takanori Isobe5;6, Gaoli Wang1?, and Zhenfu Cao1? 1 Shanghai Key Laboratory of Trustworthy Computing, East China Normal University, Shanghai, China [email protected],fglwang,[email protected] 2 Graz University of Technology, Austria 3 Radboud University, Nijmegen, The Netherlands [email protected] 4 Infineon Technologies AG, Germany [email protected] 5 National Institute of Information and Communications Technology, Japan 6 University of Hyogo, Japan [email protected] Abstract. RIPEMD-160 is an ISO/IEC standard and has been applied to gen- erate the Bitcoin address with SHA-256. Due to the complex dual-stream struc- ture, the first collision attack on reduced RIPEMD-160 presented by Liu, Mendel and Wang at Asiacrypt 2017 only reaches 30 steps, having a time complexity of 270. Apart from that, several semi-free-start collision attacks have been published for reduced RIPEMD-160 with the start-from-the-middle method. Inspired from such start-from-the middle structures, we propose two novel efficient collision at- tack frameworks for reduced RIPEMD-160 by making full use of the weakness of its message expansion. Those two frameworks are called dense-left-and-sparse- right (DLSR) framework and sparse-left-and-dense-right (SLDR) framework. As it turns out, the DLSR framework is more efficient than SLDR framework since one more step can be fully controlled, though with extra 232 memory complexi- ty. To construct the best differential characteristics for the DLSR framework, we carefully build the linearized part of the characteristics and then solve the cor- responding nonlinear part using a guess-and-determine approach.
  • The Missing Difference Problem, and Its Applications to Counter Mode

    The Missing Difference Problem, and Its Applications to Counter Mode

    The Missing Difference Problem, and its Applications to Counter Mode Encryption? Ga¨etanLeurent and Ferdinand Sibleyras Inria, France fgaetan.leurent,[email protected] Abstract. The counter mode (CTR) is a simple, efficient and widely used encryption mode using a block cipher. It comes with a security proof that guarantees no attacks up to the birthday bound (i.e. as long as the number of encrypted blocks σ satisfies σ 2n=2), and a matching attack that can distinguish plaintext/ciphertext pairs from random using about 2n=2 blocks of data. The main goal of this paper is to study attacks against the counter mode beyond this simple distinguisher. We focus on message recovery attacks, with realistic assumptions about the capabilities of an adversary, and evaluate the full time complexity of the attacks rather than just the query complexity. Our main result is an attack to recover a block of message with complexity O~(2n=2). This shows that the actual security of CTR is similar to that of CBC, where collision attacks are well known to reveal information about the message. To achieve this result, we study a simple algorithmic problem related to the security of the CTR mode: the missing difference problem. We give efficient algorithms for this problem in two practically relevant cases: where the missing difference is known to be in some linear subspace, and when the amount of data is higher than strictly required. As a further application, we show that the second algorithm can also be used to break some polynomial MACs such as GMAC and Poly1305, with a universal forgery attack with complexity O~(22n=3).
  • Taming Hosted Hypervisors with (Mostly) Deprivileged Execution

    Taming Hosted Hypervisors with (Mostly) Deprivileged Execution

    Taming Hosted Hypervisors with (Mostly) Deprivileged Execution Chiachih Wu†, Zhi Wang*, Xuxian Jiang† †North Carolina State University, *Florida State University Virtualization is Widely Used 2 “There are now hundreds of thousands of companies around the world using AWS to run all their business, or at least a portion of it. They are located across 190 countries, which is just about all of them on Earth.” Werner Vogels, CTO at Amazon AWS Summit ‘12 “Virtualization penetration has surpassed 50% of all server workloads, and continues to grow.” Magic Quadrant for x86 Server Virtualization Infrastructure June ‘12 Threats to Hypervisors 3 Large Code Bases Hypervisor SLOC Xen (4.0) 194K VMware ESXi1 200K Hyper-V1 100K KVM (2.6.32.28) 33.6K 1: Data source: NOVA (Steinberg et al., EuroSys ’10) Hypervisor Vulnerabilities Vulnerabilities Xen 41 KVM 24 VMware ESXi 43 VMware Workstation 49 Data source: National Vulnerability Database (‘09~’12) Threats to Hosted Hypervisors 4 Applications … Applications Guest OS Guest OS Hypervisor Host OS Physical Hardware Can we prevent the compromised hypervisor from attacking the rest of the system? DeHype 5 Decomposing the KVM hypervisor codebase De-privileged part user-level (93.2% codebase) Privileged part small kernel module (2.3 KSLOC) Guest VM Applications … Applications Applications Applications … Guest OS Guest OS De-privilege Guest OS Guest OS DeHyped DeHyped KVM KVM’ HypeLet KVM ~4% overhead Host OS Host OS Physical Hardware Physical Hardware Challenges 6 Providing the OS services in user mode Minimizing performance overhead Supporting hardware-assisted memory virtualization at user-level Challenge I 7 Providing the OS services in user mode De-privileged Hypervisor Hypervisor User Kernel Hypervisor HypeLet Host OS Host OS Physical Hardware Physical Hardware Original Hosted Hypervisor DeHype’d Hosted Hypervisor Dependency Decoupling 8 Abstracting the host OS interface and providing OS functionalities in user mode For example Memory allocator: kmalloc/kfree, alloc_page, etc.
  • Linux Core Dumps

    Linux Core Dumps

    Linux Core Dumps Kevin Grigorenko [email protected] Many Interactions with Core Dumps systemd-coredump abrtd Process Crashes Ack! 4GB File! Most Interactions with Core Dumps Poof! Process Crashes systemd-coredump Nobody abrtd Looks core kdump not Poof! Kernel configured Crashes So what? ● Crashes are problems! – May be symptoms of security vulnerabilities – May be application bugs ● Data corruption ● Memory leaks – A hard crash kills outstanding work – Without automatic process restarts, crashes lead to service unavailability ● With restarts, a hacker may continue trying. ● We shouldn't be scared of core dumps. – When a dog poops inside the house, we don't just `rm -f $poo` or let it pile up, we try to figure out why or how to avoid it again. What is a core dump? ● It's just a file that contains virtual memory contents, register values, and other meta-data. – User land core dump: Represents state of a particular process (e.g. from crash) – Kernel core dump: Represents state of the kernel (e.g. from panic) and process data ● ELF-formatted file (like a program) User Land User Land Crash core Process 1 Process N Kernel Panic vmcore What is Virtual Memory? ● Virtual Memory is an abstraction over physical memory (RAM/swap) – Simplifies programming – User land: process isolation – Kernel/processor translate virtual address references to physical memory locations 64-bit Process Virtual 8GB RAM Address Space (16EB) (Example) 0 0 16 8 EB GB How much virtual memory is used? ● Use `ps` or similar tools to query user process virtual memory usage (in KB): – $ ps -o pid,vsz,rss -p 14062 PID VSZ RSS 14062 44648 42508 Process 1 Virtual 8GB RAM Memory Usage (VSZ) (Example) 0 0 Resident Page 1 Resident Page 2 16 8 EB GB Process 2 How much virtual memory is used? ● Virtual memory is broken up into virtual memory areas (VMAs), the sum of which equal VSZ and may be printed with: – $ cat /proc/${PID}/smaps 00400000-0040b000 r-xp 00000000 fd:02 22151273 /bin/cat Size: 44 kB Rss: 20 kB Pss: 12 kB..
  • SUSE Linux Enterprise Server 15 SP2 Autoyast Guide Autoyast Guide SUSE Linux Enterprise Server 15 SP2

    SUSE Linux Enterprise Server 15 SP2 Autoyast Guide Autoyast Guide SUSE Linux Enterprise Server 15 SP2

    SUSE Linux Enterprise Server 15 SP2 AutoYaST Guide AutoYaST Guide SUSE Linux Enterprise Server 15 SP2 AutoYaST is a system for unattended mass deployment of SUSE Linux Enterprise Server systems. AutoYaST installations are performed using an AutoYaST control le (also called a “prole”) with your customized installation and conguration data. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents 1 Introduction to AutoYaST 1 1.1 Motivation 1 1.2 Overview and Concept 1 I UNDERSTANDING AND CREATING THE AUTOYAST CONTROL FILE 4 2 The AutoYaST Control
  • Cryptography and Network Security Chapter 12

    Cryptography and Network Security Chapter 12

    Chapter 12 – Message CryptographyCryptography andand Authentication Codes NetworkNetwork SecuritySecurity • At cats' green on the Sunday he took the message from the inside of the pillar and added Peter Moran's name to ChapterChapter 1212 the two names already printed there in the "Brontosaur" code. The message now read: “Leviathan to Dragon: Martin Hillman, Trevor Allan, Peter Moran: observe and tail. ” What was the good of it John hardly knew. He felt Fifth Edition better, he felt that at last he had made an attack on Peter Moran instead of waiting passively and effecting no by William Stallings retaliation. Besides, what was the use of being in possession of the key to the codes if he never took Lecture slides by Lawrie Brown advantage of it? (with edits by RHB) • —Talking to Strange Men, Ruth Rendell Outline Message Authentication • we will consider: • message authentication is concerned with: – message authentication requirements – protecting the integrity of a message – message authentication using encryption – validating identity of originator – non -repudiation of origin (dispute resolution) – MACs • three alternative approaches used: – HMAC authentication using a hash function – hash functions (see Ch 11) – DAA – message encryption – CMAC authentication using a block cipher – message authentication codes ( MACs ) and CCM – GCM authentication using a block cipher – PRNG using Hash Functions and MACs Symmetric Message Encryption Message Authentication Code • encryption can also provides authentication (MAC) • if symmetric encryption
  • On Comparing Side‑Channel Properties of AES and Chacha20 on Microcontrollers

    On Comparing Side‑Channel Properties of AES and Chacha20 on Microcontrollers

    This document is downloaded from DR‑NTU (https://dr.ntu.edu.sg) Nanyang Technological University, Singapore. On comparing side‑channel properties of AES and ChaCha20 on microcontrollers Najm, Zakaria; Jap, Dirmanto; Jungk, Bernhard; Picek, Stjepan; Bhasin, Shivam 2018 Najm, Z., Jap, D., Jungk, B., Picek, S., & Bhasin, S. (2018). On comparing side‑channel properties of AES and ChaCha20 on microcontrollers. 2018 IEEE Asia Pacific Conference on Circuits and Systems (APCCAS). doi:10.1109/APCCAS.2018.8605653 https://hdl.handle.net/10356/104628 https://doi.org/10.1109/APCCAS.2018.8605653 © 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. The published version is available at: https://doi.org/10.1109/APCCAS.2018.8605653 Downloaded on 30 Sep 2021 18:00:37 SGT On Comparing Side-channel Properties of AES and ChaCha20 on Microcontrollers Zakaria Najm1,2, Dirmanto Jap1, Bernhard Jungk3, Stjepan Picek2, and Shivam Bhasin1 1Temasek Laboratories, Nanyang Technological University, Singapore 2Delft University of Technology, Delft, The Netherlands 3Independent Researcher fzakaria.najm,djap,[email protected], bernhard@projectstarfire.de, [email protected] Abstract—Side-channel attacks are a real threat to many secure When considering countermeasures, it is also the nonlinear systems. In this paper, we consider two ciphers used in the operation which is expensive to implement protected against automotive industry – AES and ChaCha20 and we evaluate their side-channel attacks, unlike other linear components of the resistance against side-channel attacks.