---
tags: Master
---

# ICNS Summary (Adi)

[TOC]

## Introduction

**Topics:**

1. Basic notions
2. Authentication I
3. Introduction to cryptography
4. Application of cryptography
5. Introduction to blockchain
6. Authentication II
7. Access Control
8. Web application security
9. Privacy & GDPR

**Tools used during workshops:**

- `Jupyter notebooks` with `python`
- `TLSAssistant`: https://sites.google.com/fbk.eu/tlsassistant
- `Micro-Id-Gym`: https://sites.google.com/fbk.eu/micro-id-gym
- `MQTTSA`: https://sites.google.com/fbk.eu/mqttsa

## 1. Basic notions :globe_with_meridians:

### Security definitions :shield:


- **Information** security ([definition](https://en.wikipedia.org/wiki/Information_security))

- **Cyber** security: the ability to protect or defend the use of `cyberspace` from `cyber` attacks.

- **Cyberspace:** domain consisting of the interdependent network of information systems infrastructures.

(including the Internet, telecommunications networks, computer systems, and embedded processors and controllers)

- **CSR (**`Cyber Security Readness`**):** ability to have critical information and tools rapidly available and in place in order to proactively identify vulnerabilities, combat threats, deter attacks, and quickly remediate risks.

(allows organization to remain compliant with policy, regulations, and laws)

- **Network** security ([definition](https://www.sans.org/network-security/))

- **Computer** security ([definition](https://www.britannica.com/technology/computer-security))

#### Observations

Systems may fail for various reasons:

- **Reliability** deals with `accidental failures`
- **Usability** addresses problems arising from `operating mistakes` made by users
- **Security** deals with `intentional failures`

### The CIA triad :trident:


- **Confidentiality:** prevent un-authorised `disclosure` of information
- **Integrity:** prevent un-authorised `modification` or `destruction` of information
- ensures information `non-repudiation` and `authenticity`
- **Availability:** prevent un-authorised `withholding` of information or resources
- ensures `timely` and `reliable` access for `authorized` users

### Risk :radioactive:

**Vulnerability:** a weakness in a certain system (`information`, `network`, `computer` system, …)

**Threat:** an `activity`, deliberate or unintentional, with the `potential for causing harm` to an
automated information system or activity (eg: organizational operations).

- **Breaking into a computer** (`Hackers`, …)
- **Attacking a computer** (`DoS`, …)
- **Viruses** and **Worms**
- `Virus:` self-replicating program that **requires user action** to activate
- `Worm:` self-replicating program that **does not require user action** to activate, it propagates through the network
- **Stealing information** (use `criptography`)
- **Using a machine to attack others** (`E-mail viruses`, `worms`, `DoS`, `spam`, …)
- **Interfering with the physical world** (`power systems`, `traffic control`, `medical devices`, `smart vehicles`, `IoT`, …)

**Risk:** probability that a particular security `threat` will exploit a system `vulnerability`.

- **Risk Matrix**


### Security Policy, Service and Mechanisms

- Security **policy**: `rules` and `requirements` established by an organization that governs the acceptable use of its information and services.
- [examples](https://www.sophos.com/en-us/medialibrary/PDFs/other/sophos-example-data-security-policies-na.pdf?la=en)
- Security **service**: a `capability` that supports one, or more, of the security requirements (`CIA`).
- Security **mechanism**: a `device` or function designed to provide one or more `security services`, implementation of a `security policy`.
- examples: `Authentication`, `Authorization`, `Access control`

### GDPR :eu:

**GDPR (**`General Data Protection Regulation`**):** regulation in **EU law** about data protection.

- **Controllers** and **processors** of personal data must put in place `appropriate technical and organizational measures` to implement the data protection principles.


The GDPR aims primarily to `give control to individuals over their personal data` and to simplify the regulatory environment for international business by unifying the regulation within the EU.

### Wrap-up

- Make yourself comfortable with the `definitions` of and `relationships` among **Computer**, **Network** and **Cyber** Security
- Remember the definitions of the **CIA** properties and try to find examples of such properties in systems you routinely use (e.g., Esse3, on-line banking)
- What is the **`risk-based` approach to security**?
- What is a **security policy** and how does it relate to the CIA properties? What is a **security mechanism**?

## 2. Authentication I :ticket:

**Authentication:** process of verifying a `user’s identity`.

- user identity is a parameter in `access control decisions`
- user identity is recorded when `logging` security relevant events in an **audit trail**

👁‍🗨 It is not always necessary or desirable to base access control on user identities.

### User Authn

**User authentication:** the process of verifying a `claimed user identity`.

- entering `username`: you **announce** who you are
- entering `password`: you **prove** that you are who you claim to be

### Passwords overview

#### Bootstrapping

How do you bootstrap a system so that the password ends up in the right places, but nowhere else?

- password delivery might be **intercepted**
- password may be delivered to an **impersonator**

**In person** withdrawal should be secure enough.

**Remote delivery:**

1. Do not give the password to the caller! **Call back an authorized phone number.**
2. Send only passwords valid for a `single log-in request`. **User has to change it to a password not known to the sender.**
3. Send **mail by courier** with personal delivery.
4. Request **confirmation on a different channel** to activate user account.
(`SMS` in authN has been recently deprecated by [NIST](https://www.nist.gov/))

👁‍🗨 Procedures for **resetting passwords** are the same as listed previously, but reaction **should be instant**.

#### Attacks Overview

- **Exhaustive search (**`Brute force`**):** try all possible combinations of valid symbols up to a certain length
- **Restricted name space (**`popular passwords`, `dictionary attack`, `exploit info about victim`, …**)**

#### Mitigation

**Some random tips:**

- set a password: grazie al ca**o.
- change default password: grazie al ca**o.
- avoid guessable passwords: grazie al ca**o.

**New `NIST` password limitations:**

- forbid common ones
- no password hints, or knowledge-based authn
- limit password attempts

### Phishing vs Spoofing

In **phishing** and **spoofing** attacks, a party voluntarily sends the password over a channel, but is misled about the end point of the channel.

- **authn is unilateral:** no guarantees about the destination identity

| SPOOFING :eyes: | PHISHING :fishing_pole_and_fish: |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| Hacker tries to steal the identity to act as another individual. | Hacker tries to steal the sensitive information of the user. |
| It doesn’t require fraud. | It is operated in a **fraud manner**. |
| **Information is not theft.** | Information is theft. |
| Spoofing can be part of the phishing. | Phishing can’t be the part of the spoofing. |
| Needs to download some malicious software in victim computer. | No such malicious software is needed. |
| Spoofing is basically done to **get a new identity**. | Phishing is done to **get secret information**. |
| **Types:** `IP Spoofing`, `Email Spoofing`, `URL Spoofing` etc. | **Types:** `Phone Phishing`, `Clone Phishing` etc. |

### HASH

Is a **1-way function**: easy to compute, hard to reverse.

**Can be used to protect the real password:**

- Instead of the password $x$, the value $f(x)$ is `stored in the password file`
- when a user logs in entering a password $x’$, the system applies the one-way function $f$ and compares $f(x’)$ with the expected value $f(x)$.

**Hash function requirements:**

1. `Ease of computation:` $x \rightarrow f(x)$
2. `Compression:` from arbitrary input to fixed length output
3. `One-way:` input $x$ is computationally infeasible to find given the output $f(x)$
4. `Weak collision resistance:` given $x$, it is computationally infeasible to find another input $x’≠x$ with the same hash output
- (ndr) deve essere computazionalmente impossibile ottenere lo stesso digest modificando i dati
5. `Strong collision resistance:` it is computationally infeasible to find any two
inputs that return the same hash output
- many collisions usually exists, but **no one should be able to find one** given a good enough implementation

👁‍🗨 **Collision:** situation in which two inputs $x$ and $x’$ map to the same hash, $h(x) = h(x’)$.

**Hash implementations:**

- `MD4:` weak, easy to find meaningful collisions
- `MD5:` standard in some Internet protocols, no longer recommended
- `SHA-1:` 160b hash value, collision attacks reported
- `RIPEMD-160:` …
- `SHA-256:` bigger hash output, more secure
- SHA-512, ecc…

#### Salting

**Hashing passwords is not enough:**

- need to add `salt` and/or `pepper` in order to slow down **rainbow tables attacks**
- randomly generated string to **add to password before encryption**
- original salt need to be **stored for each user**
- `iterate` hash function as much as possible in order to slow down **brute force attacks**


👁‍🗨 (ndr) Is it necessary to re-concatenate to salt at every iteration?

### SSO (Single Sign On)

Allows users to access multiple apps through a **single authentication act**.

- **only one password needed:**
- :heavy_plus_sign: easier for users
- :heavy_minus_sign: weak point (game over if it gets hacked)

Need balance between **usability** and **security**:


**Solution:** `SSO + Multi-Factor Auth`, combine for maximum security

- something you know (`password`)
- something you own (`card`)
- who you are (`biometrics`)

**Contextual authentication:**

- `consider context` when user is logging in
- login from an **unusual** place, **unusual** hour and **unusual** activity $\Longrightarrow$ **high risk score** (`warn user`)

## 3. Cryptography: Introduction :closed_lock_with_key:

- **Cryptography:** how to `hide` secrets
- **Cryptanalysis:** how to `break` ciphers
- **Cryptology:** both

Cryptography used in:

1. data `confidentiality` (hide content)
2. data `integrity`
3. `entity authentication`
4. data `origin authentication`

### Cryptosystem

**5-tuple $(E, D, M, K, C)$**

- $E$: `encryption` $M \times K \rightarrow C$
- $D$: `decryption` $C \times K \rightarrow M$
- $M$: set of `plaintexts` (also $P$)
- $K$: `keys`
- $C$: set of `ciphertexts`

**Kerckhoff’s principle:** Algorithm should NOT be SECRET, **KEYS ARE THE ONLY SECRET!**

### Key essentials

👁‍🗨 A **`key`** can be used to obtain `confidentiality`, `integrity`, `authenticity` or other property over some data.

- **Key management**: generate, store, share/DELIVER etc
- **Keyspace**: all possible keys
- **Entropy**: variance in keys
- **Computationally secure key:** at least one of
- `cost` of breaking $>$ data `value`
- `time` of breaking $>$ data `lifetime`

👁‍🗨 **Cryptography** is rarely a solution for a security problem, **is a translation mechanism:**

- `communication security` issue $\rightarrow$ `key management` issue $\rightarrow$ `computer security` issue
- **moral of the story:** keys are vulnerable data, `access control mechanisms` in the **computer system** `have to protect these keys`

### Encryption essentials

Two types of transformation:

- **Substitution:** replace each byte/letter/block with a fixed one (A->M, B->N, …)
- ex: `Caesar cipher` (aka `ROTk`, _rotate by k_)
- **Transposition:** move byte/letter/block:
- ex: `columnar cipher`

👁‍🗨 **Requirement:** transformations are **reversible**, and **no information is lost**.


### Symmetric key


- `same key` on every host interested, for **encryption and decryption**
- **management of keys determines who has access to encrypted data**
- :heavy_check_mark: much faster than asymmetric
- :x: key exchange is a big problem
- :warning: **Properties:** `confidentiality` (encryption)

Symmetric key `ciphers`:

- **stream ciphers**: encrypt bit by bit
- encrypt with **key as long as the data**
- security relies on design of `key stream generator`
- :heavy_plus_sign: faster
- **block ciphers**: 64-256 bits (`DES`, `AES`, …)
- encrypt with **same key for every block**
- security relies on design of `encryption function`

#### DES (Data Encryption Standard)

- uses **Feistel** block-cipher (`56b key` on `64b blocks`)


#### AES (Advanced Encryption Standard)

- DES successor, `bigger keys`
- uses **Rijndael** block-cipher
- :heavy_check_mark: ​`variable block and key length`

### Asymmetric key


- aka **PKC (**`Public Key Cryptography`**)**
- :heavy_check_mark: **No shared secret:** `private key is never shared!`
- 👁‍🗨 based on **one-way functions** (usually `prime multiplication` or `exponentiation`)
- :x: slower than symmetric (2-3 orders of magnitude)
- symmetric encryption is typically used to encrypt communications (`key exchanged through PKC`)
- PKC is more used for data exchange
- :heavy_check_mark: key agreement is not a problem
- :warning: **Properties:** `confidentiality` (encryption), `authentication` (if signer is trusted), `integrity` (digital signature), and `non-repudiation` (digital signature)

#### RSA (Rivest, Shamir, Adleman)

- :heavy_check_mark::heavy_check_mark: can be used for anything: `key exchange`, `digital signatures`, or `encryption` of small blocks of data
- 💭`Reasoning:` products are easy, **factorizations are hard** to compute


#### DH (Diffie-Hellman)

- used **for secret key exchange only**
- :x: does not provide authentication $\Longrightarrow$ `vulnerable to MITM attacks`
- 💭`Reasoning:` exponents are easy, **discrete logarithms are hard** to compute (`DLP`)
- $x → g^x (\text{mod } p)$ is the `one-way function`


### Takeaways

- **Avoid to design your own crypto algorithms:** amateur designs are usually broken quite easily
- Do not use DES!!! **Use AES for block cipher.**
- `PKC` $\ne$ `RSA`
- do not forget **key management:**
- how to `share`?
- hot to `keep the secret`?
- $n$ participants $\implies$ $n^2$ total keys needed

## 4. Cryptography at work: PKI and TLS :credit_card:

### Birthday Attack on Signatures

`Abuses the limited outputs` a HASH function can return:

1. Suppose $n$ is the bit-length of a hash function $h()$
2. $A$ wants to trick $B$ into signing a fraudulent contract
3. $A$ prepares `fair contract` $m$ and `fraudulent contract` $m’$
4. $A$ generates $1.25*2^{n/2} $(equivalent) variants of $m$
5. $A$ generates $1.25*2^{n/2}$ (equivalent) variants of $m’$
6. $A$ computes hash function $h()$ on variants of $m$ and $m’$ `until she finds a collision`
7. $A$ sends $B$ the variant of $m$ identified at step $6$
8. When $A$ `receives the signed contract` from $B$, she computes the signature and attaches it to the fraudulent variant of $m’$ identified at step $6$
9. $A$ can prove that $B$ signed the fraudulent contract $m’$

**Fix:** make very `big hash` => hard to find collisions

### Digital Certificates

:warning: `Digital signature problem:` **why trust who the signer claims to be?**

**Digital Certificate:** certifies `binding between pub-key and entity` (person, hardware, etc).

- signed by **TTP (**`Trusted Third Party`**):** should be trusted

**X.509 Certificate structure:**


**Main elements:**

1. Issuer (CA)
2. Subject (User)
3. Subject Public Key (`bond to subject`)
4. CA Digital Signature (`validates the certificate`, until expiration)

### PKI (Public Key Infrastructure)

System used by `TTP` for validating and distributing certificates.

**Components:**

- **CA (**`Certificate Authority`**):** authorizes sub-CAs
- `Subordinate CA:` signs and hands out certificates
- **RA (**`Registration Authority`**):** verifies certificate requests
- **VA (**`Validation Authority`**):** verifies certificate validity
- optional (`CA can do this job`)
- uses `CRLs` updated from CAs
- **CPS (**`Cryptographic Practices Statement`**):** how good security is
- **CRL (**`Certificate Revocation List`**):** revoked certificates

### SSL/TLS

- **SSL (**`Secure Sockets Layer`**):** way to secure communications between the client and server on the web, **deprecated**
- **TLS (**`Transport Layer Security`**):** evolution of SSL

**SSL/TLS** provides:

- `identification` (Digital Certificate)
- `authentication` (Handshake encrypted with each other’s public key)
- `confidentiality` (shared symmetric key)
- `integrity` (HMAC on every message, hash check at the end of the handshake)

**Components:**

- `Handshake protocol:` see [**`Reti Avanzate’s PDF`**]()
1. decide algoz and version
2. authenticate both parties (optional)
3. use PKC to establish symmetric key
- `Cipher Change Protocol`
- `Alert Protocol`
- `Record Protocol:`


#### Vulnerabilities

- **3-shake:**


- **Sweet32:** possible Birthday attack for `3DES cypher` (32 bit hash). 3DES removed in v1.3
- **CRIME:** when using DEFLATE compression. Deflate removed in v1.3

## 5. Blockchain Technology :chains:

- **linked list** of records (ex: of transactions)
- allows `only adding` operation
- `Integrity:` links are `hashes` of the **previous block** $+$ hash of the **block itself**
- 👁‍🗨 is a **DLT (**`Distributed Ledger Technology`**):** several copies of the data structure that are in synch
- `no central authority` that guarantees the coherence of the various copies
- decentralized in the nodes of a **`P2P network`** (full copy for each peer)
- `every node can update the ledger`

**Consensus:** use algorithms to sync different copies of the chain

- **PoW (**`Proof of Work`**):** mechanism that slows down the validation of blocks, power hungry

- solve a `computational problem for each block:` for example, find a code that makes the hash of the whole block begin with $n$ zeros
- :heavy_check_mark: `hard to solve, easy to check`
- **validation power:** comes from computation power
- :disappointed: `Problems for its own sake:` the hard computations have no other purpose
- `Cryptomining:` miners solve problem, attach new block, **get reward**
- 👁‍🗨 **reward is brand new currency**, registered as a transaction in the bock that gets validated by the miner itself
- :heavy_check_mark: **Properties:** `chain integrity`, `Byzantine fault` resistance, `double spending` immunity
- :x: **`10+` minutes to validate** the block
- :x: miners group in `centralized communities over time`
- :x: vulerable to `51% attacks` if miners centralize or are not incentived (leave) enough

- **PoS (**`Proof of Stake`**):**

- **validation power:** comes from owned coins
- **No hard computations:** potentially more cost and energy efficient, but less proven
- :heavy_check_mark: **`<1` second to validate** the block
- :heavy_check_mark: `no miners`
- :x: vulerable to token capitalism: have more $\rightarrow$ validate more $\rightarrow$ earn more fees

**Types of blockchain**

- `public:` no access restrictions, is permissionless
- Bitcoin
- Ethereum, …
- `private:` restricted access, is permissioned
- `permissioned:` **access control layer**, a central authority (`consortium`) assigns permissions in the peer network
- `permissionless:` no permission needed to join

### Bitcoin

- **Consensus** paradigm: `proof of work`
- no need for exclusion or access controls, `anyone can participate`
- `transparent blockchain`: all transactions are visible
- `scripts` can be used to create **`smart contracts:` allow logic based transactions**
- execution controled exlusively by the ufficial platform


:crown: **Byzantine generals problem:** when faults present `different symptoms to different observers`.

- Bitcoin is resistant to this by using the `Proof-of-Work` approach
- the `leader` is the one who is the first to find the solution

:heavy_dollar_sign::heavy_dollar_sign: **Double spending problem:** when digital money can be duplicated.

- Bitcoin is resistant to this by using the `Proof-of-Work` approach
- waiting more confirmations helps against uncertainties (`5+ successive blocks`)
- **51% attacks** are a double spending problem

## 6. Authentication II :busts_in_silhouette:

### SSO in Depth

SSO is a property of `access control` of multiple related, yet independent, software systems.

- **Multiple systems:** `multiple sign-on`
- :x: burden for administrations and users
- :x:/:heavy_check_mark: more security domains $=$ more sign-ons
- **Single Sign-on**
- `less time` spent re-entering password
- less IT costs (low help desk for forgotten passwords)
- :heavy_check_mark: more complex passwords
- :heavy_check_mark: shared sessions
- :heavy_check_mark: only one password to remember
- :x: less security, one password for everything

**SSO Types:**

- **Pseudo-SSO**
- separate auth to each service
- `client software manages credentials`
- login hidden from user
- **Proxy-based SSO**
- **pseudo-SSO** but implemented in a proxy
- `proxy manages user credentials`
- login hidden from client
- **True SSO**
- user auth to a **one auth service**
- this auth service `asserts user identity to other services`
- **Federated SSO**
- auth between administrative domains

### SAML

**SAML (**`Security Assertion Markup Language`**):** standard for exchanging `authentication` and `authorization` data between parties.

- set of **XML-based protocol messages** for:
- `user authentication`
- `attribute information`

- defines **3 roles:**
1. **User:** requests service from SP
2. **Service provider (**`SP`**):** requests user identity from trusted IdP
- `access control` on own services/resources
- can `trust many IdPs`
3. **Identity provider (**`IdP`**):** asserts user identity to SP
- user is authenticated to the IdP
- authentication method not specified by SAML
- could provide `SAML assertions to many SPs`

🎯 **SAML goal:** promote `web-browser SSO` interoperability across multiple security domains.

- SSO is easy within one security domain (cookies, ….)
- SAML **does not** perform auth
- SAML **does not** grant access to resource X

#### Advantages

- **Platform Neutrality:** security layer is more `indipendent` (external framework)
- **Loose coupling of directories:** no need to keep and sync user info through directories
- **Improved online experience for end users:** SAML enables `Single Sign-On` (auth to `IdP`)
- **Reduce administrative costs and risks for service providers:**
- reduce the cost of maintaining account information
- `tracking of users done by IdP`

❓ SAML `Web SSO vs Attribute Based` Authz❓

#### SAML Components

There are $6$ components:


**1. Assertions**

Package of information supplying one or more statements made by a SAML authority.

- 3 kinds of `assertions statements`:
- **Authentication**
- `tells how` the subject was authenticated *(*💭*SAML DOES NOT AUTHENTICATE)*
- typically generated by the `IdP`
- **Attribute**
- subject is `associated` with the given attributes
- **Authorization Decision**
- A request to allow a subject `to access a resource` has been granted or denied

`Authentication assertion example:`


**2. Protocols**

Are a number of **`request/response protocols`** that allow service providers to request:

- one or more `assertions` from a SAML authority
- to an `identity provider to authenticate` a principal and return assertion
- the `registration of a name identifier`
- to `end the use of an identifier`
- near-simultaneous logout of a collection of related sessions (`single logout`)

**3. Bindings**

`Mapping of SAML protocols` onto standard messaging and communication protocols.

- `HTTP` redirection binding
- `SOAP` messages binding

**4. Profiles**

Combination of SAML `assertions`, `protocols`, and `bindings` to support a defined use case (*application*).

- **goal:** `++interoperability` with less flexibility

- **Web Browser SSO Profile:** most important use case


- SP-Initiated SSO is more common
- 👁‍🗨 **login is always done by IdP**, SP simply redirects (ndr from watching examples)
- 👁‍🗨 from the examples, the `auth statement` (SAML assertion) <u>CAN</u> pass signed through the User

**5. Metadata**

Defines how to express `configuration` and `trust-related data`.

- identifies actors for profiles. (`SSO IdP`, `SSO SP`, `SSO Requester`, etc…)
- data that must be agreed on between system entities:
- supported roles
- identifiers
- URLs
- certificate and keys
- supported profiles

**6. Authentication Context**

Permits the augmentation of `assertions with additional information` pertaining to the authentication of the Principal at the IdP.

- 🧐 IdP may need extra info for doing an assertion with *“confidence”*
- details of multi-factor authentication can be included

#### SAML Security

How does the relying party `trust received assertions?`

- `MITM` could exploit assertions

**Security mechanisms:** described for each SAML binding in the standard (`non mandatory❔`)

- relying party and asserting party **trust with PKI** (`Public Key Infrastructure`)
- for message `integrity` & `confidentiality` $\longrightarrow$ use **SSL/TLS**
- for `assertion messages` between relying and asserting parties $\longrightarrow$ SSL/TLS + **mutual authentication**
- for assertion message delivered via User (`integrity`) $\longrightarrow$ use **XML Signature** (POST, PUT bindings…)

#### SAML Privacy

**Problems:**

- `user’s identity` data management
- `inhibit inappropriate correlations` of user actions

**Privacy mechanisms**

- **pseudonyms:** between identity and service provider
- set a `different user identifier for each SP` $\longrightarrow$ protection from inappropriate correlations
- **one-time/transient identifiers:** SPs won’t be able to recognize multiple accesses from the same user
- **Authentication Context:** user authenticated at a sufficient assurance level (not more than necessary)
- ❔ SAML allow the fact of a **user consenting to certain operations** to be expressed between providers

#### **Conclusion**

- with SAML, **SPs don’t have to care about Identity Management**
- :heavy_minus_sign: administration burden
- :heavy_plus_sign: `interoperability`, `usability`, `security` and `privacy`
- **SAML profiles are useful** use case scenarios
- **Web SSO** most adopted
- SSO has increasing importance and is gaining wider and wider adoption
- SAML is ideal **starting point to build infrastructures** for digital Identity Management
- key enablers in an increasing digital world (`SPID`, `eIDAS`)
- first line of defense against attackers

### Identity Infrastructures

Combination of technologies and processes that helps the management of the digital identities.

#### SPID

**SPID (**`Sistema Pubblico di Identità Digitale`**):** enables to citizens and enterprises an SSO for all online services of public administrations and member companies.

- based on SAML 2.0
- `4 assurance levels` authentication for an SPID user (`different privileges`)
1. self asserted (social networks)
2. login + password: `minimum for services access`
3. login + password + $2_{nd}$ factor
4. smart-card

#### eIDAS

Is an `EU regulation` on electronic identification and trust services for electronic transactions in the European Single Market.


- interoperable with `SPID`
- ❕ signature verification **vulnerability**: attacker could impersonate any EU citizen
- patched (ndr)

## 7. Access Control I

## 8. Access Control II

### OAUTH

### ABAC

### XACML
## 9. Web application security :spider_web:

## 10. Privacy and Data Protection :eyes:

## 11. Recap Questions :grey_question:

1. **Basic notions**
2. **Authentication I**

- What is `authentication`?
- What is a `hash` function?
- What is `salting`?
- What is a `brute force` guessing attack? How can it be mitigated?
3. **Cryptography: Introduction**

- What is a `cryptosystem`?
- Why `key managemen`t is crucial for cryptography?
- What does it mean for a cryptographic technique to be `computationally secure`?
- What are `substitution` and `transposition` ciphers? Given an example for each one.
- What is `symmetric` cryptography?
- What are block and stream `ciphers`?
- Why is `DES` deprecated? Why is `AES` still used?
- What is `asymmetric` (or public key) cryptography?
- What are the main advantages and disadvantages of symmetric and asymmetric cryptography
- What is `RSA` and for what it can be used?
- What is `Diffie-Hellma`n and for what it can be used?
- What is a possible attack to Diffie-Hellman?
- What is a `one-way function`?
- What is the one-way function used in RSA?
- What is the one-way function used in Diffie-Hellman?
4. **Cryptography at work: PKI and TLS**

- `Digital Certificates:`
- How are Digital Certificates `issued`?
- Who is issuing them?
- Why should I `trust` the Certificate issuer?
- How can I `check` if a Certificate is valid?
- How can I `revoke` a Certificate?
- Who is revoking Certificates?
- ONE ANSWER: **PKI (**`Public Key Infrastructure`**)**
- What are the advantages and disadvantages of Symmetric and Asymmetric Cryptography?
- How can PKC be used to `sign messages`?
- What is the role of hash functions in this process?
- What is a `digital certificate` and what are its main components?
- What is the `Public Key Infrastructure` (PKI) and which are its main entities?
- What is `SSL/TLS`? Where is it used?
- How does the `handshake protocol` of TLS work?
- What is the role of Diffie-Hellman technique?
- What are the potential security problems of TLS?
5. **Blockchain Technology**

- Describe the structure of the `blockchain datastructure`
- Why are `digital signatures important` in blockchain? What kind of problem they solve?
- What is the `double spending problem`? How can it be solved?
- What is the `Byzantine General Problems` and why is it relevant for the blockchain?
- What is the Proof-of-Work approach to solving the `consensus problem`?
- What is the different between a blockchain and a `distributed ledger`?
- Explain the terms public, private, `permission-less` and `permissioned`
6. **Authentication II**
- What are the goals of `SAML`?
- What is the structure of a SAML assertion?
- What is a `SAML profile`? Give an example of SAML profile.
- What is the difference between `IdP-Initiated` and `SP-Initiated` **Web SSO**?
- What is the flow of an IdP-Initiated Web SSO?
- What is the flow of an SP-Initiated Web SSO?
- What are the main `security concerns` underlying the deployment of SAML? What are the main `mitigations measures`?
- What is `SPID`? What is `eIDAS`? Is there a relationship between the two?
- Give an example of scenario in which eIDAS is useful.
7. **Access Control I**
8. **Access Control II**
9. **Web application security**
10. **Privacy and Data Protection**