Category: Security

Stack and Heap are not executable
W^X policy enforced on code pages
Prevents code-injection attacks

Passcodes and Touch ID
– touch ID provides convenience
– passcode enables data protection
– Maximum failed attempts
– Progressive passcode timeout

Android Security Overview
Applications, Application Framework, Libraries, Android Runtime, Linux Kernel

Each application runs with its UID in its own Dalvik virtual machine
– provides CPU protection, memory protection
Applications announces permission requirement
– create a whitelist model -user grant access
ask user at install time
– Inter – component communication reference monitor checks permissions

Android
App announces permission requirement
Installation-time approval
App may have more powerful permissions

Code Signing
All apps self-signed by developers
Code signing is used for
facilitating application upgrades
code/data sharing between applications
lets apps run in the same process

Third party app -> Guidelines -> App Store -> End users
Third-party apps have to be reviewed by Apple. The apps that passed the review are signed by Apple
iOS devices are only allowed to download apps through the App store

Sandboxing
App -> MyApp.app, Documtents, Library, tmp
Each app has a unique home directory for its files
Apps are restricted from accessing files stored by other apps or from making changes to the device

Address Space Layout Randomization
stack, heap, main executable, and dynamic libraries
Lib A, Lib B, Lib C: Memory Layout

Data Execution Prevention
Stack <- execute, Code <- write

WIFI security
iOS security
Android security

Introduction to WiFi
– no inherent physical protection
– Broadcast communications

Early solution was based on WEP
seriously flawed
not recommended to use
New security standard for WiFi is 802.11i, implemented as WiFi Protected Access II(WPA2)

Overview of 802.11i
Main advantages over WEP
access control model is based on 802.1X
flexible authentication framework(based on EAP – Extensible Authentication Protocol)
– Carrier protocol designed to transport the messages of real authencitation protocols(e.g., TLS -Transport Layer Security)

authentication process result in a shared session key
different functions(encryption, integrity) use different keys derived from the session key using a one-way function
integrity protection is improved
encryption function is improved

Overview of iOs security
Software
Hardware and Firmware (crypto engine, device key, group key, apple root cerftificate)

Data protection class, app sandbox, user partition, os partition, encrypted file system, kernel, Hardware and firmware

Each iOS device has a dedicated AES-256 crypto engine
Manufacture keys
apple provides the Device ID(UID) and the device group ID(GID) as AES 256 bit keys
while the UID is unique to each device, the GID represents a processor class (e.g, Apple A5 processor)
The UID and GID keys are directly burned into the silicon and can only be accessed by the Crypto Engine

iOS Trusted Bootchain
Bootrom -> LLB -> iBoot -> Kernel

File Data Encryption
Hardware key -> file system key
passcode key -> class key -> file metadata -> file content

Every file is encrypted with a unique file key, that is generated when the file is created
The file key is wrapped with a class key and stored in the file’s metadata
The metadata is encrypted with the File System Key
The Class key is protected by the Device UID and (if configured for some files) the User passcode

Mandatory Code Signing
All executable code has to be signed by a trusted party
– Apps from App Store are signed by Apple
– No dynamic code generation or self-modifying

code signing check
– enforced by kernel, handled by a user-space daemon
– mandatory code signing

Negotiate protection suite, crypto algorithms
Establish shared secret
e.g., use Diffie-Hellman
Authenticate the shared secret, IKE SA
e.g., using pre-shared secret key, public-key encryption or digital signatures

Secure Socket Layer(ssl) and transport layer security
-one of the most widely used security services
-general-purpose service implemented as a set of protocols that rely on TCP
-subsequently became internet standard: Transport layer security

IPSec and the Internet key exchange protocol
Transport layer security protocol

IP spoofing is a common technique in cyber attacks
– bots spoof the an IP address of a victim web site
– then send DNS queries to DNS servers
– the DNS servers respond, sending large amounts of data to the victim
– Result: a denial-of-service attack

Goals of IPSec
– Verify sources of IP packets
Provide authentication that is lacking in IPv4
protect integrity and/or confidentiality of packets
prevent replaying of old packets
provide security automatically for upper layer protocols and applications

IPSec Modes
transport mode
gateway <-> gateway

New IP Header -> AH or ESP Header -> Orig IP Header -> TCP -> Data

ESP(Encapsulating security payload) <-> AH(Authentication Header)

Encapsulated Security Payload(ESP)
– encrypt and authenticate each packet
– encryption is applied to packet payload
– autentication is applied to data in the IPSec header as well as the data contained as payload, after encryption is applied

ESP in Transport Mode
orig IP Hdr -> TCP Hdr -> Data

Authentication is applied to the entire packet, with the mutable fields in the IP header “zeroed out”

If both ESP and AH are applied to a packet, AH follows ESP

Internet Key Exchange
Exchange and negotiate security policies

Establish parameters
security associations
Key exchange

One-way relationship between a sender and a receiver, defined by IPSec parameters
one SA for inbound traffic, another SA for outbound
Security Association Database(SADB)
Security Parameter Index(SPI)
Security Policy Database(SPD)

Anti-Replay
sequence number checking
anti-replay is used only if authentication is selected
window should not be advanced until the packet has been authenticated
Duplicates are rejected!

Authentication first
A new key is used for each session
Using shared (master) secret
encrypt the new key
Using public keys

Establish a shred key for the session even if a there is already a shared secret key
Typically a long term secret key is called a Master key, possibly derived from a password.
The master key is used to authenticate and establish a new session key.

Alice -> Bob: E(PRa, E(PUb, K))
diffie-Hellman with signing,i.e.,
Alice -> Bob:E(PRa, Y^a)
Bob -> Alice:E(PRb, Y^b)

Each communication pair needs to share a master key

Authentication protocols
Key exchange protocols
Kerberos

Alice and Bob want to communicate securely over the Internet, they need to:
– authenticate
– establish and exchange keys
– agree to cryptographic operations and algorithms
Building blocks:
public-key (asymmetric) and secret-key(symmetric) algorithms, hash functions

Mutual Authentication: Shared Secret
– R1 and R2 should not be easily repeatable and predictable
otherwise and adversary, Trudy, can record and replay challenge and/or response to impersonate Alice or Bob
– Use large random values
– Kap needs to be protected at Alice and Bob(end points of communication)

Reflection Attack
I’m Alice R2 -> connection -> R1, E[Kab,R2]

Fixes:
Different keys for initiator and res ponder
Trudy can’t get Bob to encrypt using Alice’s key

Different type of challenges for initiator and responder
e.g., even number for initiator and odd number for responder

Developed by NIST, specified in the Secure Hash Standard, originally 1993
Revised as SHA-1 in 1995
160 bit hash
NIST specified SHA2 algorithms in 2002
Hash value lengths of 256, 384, and 512
Similar to SHA-1

SHA-1, SHA-256, SHA-384, SHA-512
Message digest size, Message size, Block size, Word size, Number of steps, Security

Message Processing
Message Digest Generation using SHA-512

SHA-512 Processing of a Single 1024-bit block

Hash based message authentication
– cryptographic hash functions generally execute faster
– library code is widely available
– SHA-1 was not designed for use as a MAC because it does not rely on a secret key
– issued as RFC2014
– Has been chosen as the mandatory-to-implement MAC for IP security
– Used in other Internet protocols such as Transport Layer Security(TLS)

HMAC Security
– security depends on the cryptographic strength of the underlying hash function
– It’s much harder to launch successful collision attacks on HMAC because of secret key

How many people do you need in a room before you have a greater than 505 chance that two of them will have the same birthday?
Assume 356 birthdays(our containers)

% chance that two people in the room have the same birthday
100% requires 366 people (the pigeonhole principle)

Compute probability of different birthdays
Random sample of n people(birthdays) taken from k (365)days
k^n samples with replacement
(k)n=k(k-1)…(k-n+1) sample without replacement
Probability of repetition:
p = 1 – (k)n/k^n = n(n-1)/2k = 0.5 if n = √k

1-(k)n/k^n = the probability that a pair share the same birthday
If k = 365, n = 19
If there are 19 people in a room, there is a good chance that two of them share the same birthday!

There are many more ‘pigeons’ than ‘pigeonholes’
Many inputs will be mapped to the same output. That is, many input messages will have the same hash.
Conclusion: The longer the length of the hash, the fewer collisions.

Compute message digest of data of any size
Fixed length output:128-512 bits
Easy to compute H(m)
Given H(m), no easy way to find m
One-way function
Given m1, it is computationally infeasible to find m2 = m1 s.t. H(m2) = H(m1)
weak collision resistant
Computionally infeasible to find m1=m2 s.t. H(m1)=h(m2)
strong collision resistant

Requirements for a practical application of a hash function
The one way property
Hash functions are unique to each message

Sender: Message with encrypted hash code
-> generate an un-encrypted hash code
-> create an alternate message
-> Receiver: Forged message with encrypted hash code

Hash Function Weaknesses
-> Pigeonhole principle
-> The Birthday Paradox

n = numbers of pigeons
m = number of holes
n = m There is one pigeon per hole
n > m Then at least one hole must have more than one pigeon