Mobile App Development 2022W Lecture 19

Video

Video from the lecture given on March 25, 2022 is now available:

• video
• auto-generated captions

Video is also available through Brightspace (Resources->Zoom Meetings (Recordings, etc.)->Cloud Recordings tab). Note that here you'll also see chat messages.

Notes

Lecture 19
----------

March 25:   cryptography  
March 30:   A3 solutions, language runtimes
April 1:    Midterm solutions, operating systems
April 6:    networking, *last regular tutorial checkoffs*
April 8:    A4 solutions, closing thoughts
April 14:   Final Exam (2-4 PM)
April 18-22: Final exam interviews

Midterm interviews will be the week of April 4th


Cryptography and mobile applications (and other things)
 - highly encourage you all to take cryptography
     - it is moving to 2nd year, so you should be able to take it in the fall/winter

Key problem in mobile OSs
  - how do I know what code is "okay" to run?
     - what code is authorized?

Key technology: digital signatures
 - so only run code signed by approved authorities

Note this applies everywhere
 - firmware (code that runs on devices)
 - boot loaders (code to start an operating system)
 - operating systems
 - applications

Four building blocks of modern cryptography
 - secure hashes
 - message authentication codes (MACs)
 - symmetric encryption
 - public key encryption
    - which includes digital signatures

What is a digital signature?

When you install software on Windows, it will say who has published the software
 - under the hood, Windows is checking the digital signature of the software
 - if "unknown publisher", there wasn't a valid signature, or was signed
   by someone Windows didn't know about

Digital signature provides two basic guarantees
 - authenticity  <--- who signed this
 - integrity     <--- is it what was signed, with no changes

Integrity comes from secure hashes (cryptographic hashes)
 - MD5, SHA1 were older ones, don't use them
 - SHA256, SHA512, others are better

On many OSs, can generate a SHA256 hash with the sha256 command or similar
 - produces a 256-bit value (normally displayed in hexadecimal)
    - because in base-16 each digit represents 4 bits

A hash of any kind converts an arbitrary-sized input into a fixed-sized output.

A secure hash should have the following properties
 - given a document, it should be easy to compute the hash
 - given a hash, it should be *difficult* to construct a document
   that has that hash
 - it should be *difficult* to find two documents that have the same hash
 - if you change one bit in the document, it should on average change
   half the bits in the hash.

Note that hash functions have *no key*

So if someone presents you with a secure hash to identify a document and you get the document from another source, the secure hash can tell you that a) you found the right document, and b) it hasn't been changed
 - in effect, a secure hash is a strong identifier of any digital data

Classic use: downloading large files (disk images, etc)
 - main website shows secure hash
 - download file from a mirror
 - check the downloaded file has the same hash

Technologies like bittorrent and git are built on secure hashes

Now, how do you know you have the right hash for a file?
 - if you downloaded it from a website, the website could have been compromised
 - can we have a stronger guarantee?

This is what digital signatures are for.

Symmetric encryption
 - k: the key
 - P: plaintext
 - C: ciphertext (encrypted plaintext)
 - E: encryption algorithm
 - E': decryption algorithm

 - normally E and E' are the same or almost the same
 

 E(P,k) => C
 E'(C,k) => P

This is how secret decoder rings work
This is also how AES works.
  - AES is a symmetric block cipher
     - works on 128 bits at a time
     - key can be 128, 192, or 256 bits
(How do you encrypt something longer that 128 bits?  That's block cipher modes, beyond the scope of this lecture.)


With symmetric key encryption, the key for encryption and the key for decryption are the same.

Symmetric key encryption is *very* secure, but has a fundamental problem
 - how do both parties get the same key?

Public key cryptography is the solution to this problem
 - keys come in pairs, a public and matching private key
 - k: private key is private (don't share with anyone!)
 - k': public key is public (tell everyone!)

So with public key cryptography we get:

  E(P, k) => C
  E'(C, k') => P

If you wanted to send me a private document, you would get my public
key (which is widely available), use it to encrypt the document, and
then send it to me (or even publish it).  Only I can read it since
only I have the corresponding private key.

A digital signature is the same idea, except we reverse the public and private key roles
 - private key is used to sign a document
 - public key is used to verify a signature

(While some algorithms, like RSA, can be used for encryption and signatures,
 nowadays we actually use separate ones mostly)

By the way, public key algorithms only work on small amounts of plaintext/ciphertext
 - so we combine with hash functions (for digital signatures) or symmetric key algorithms (for encryption)
 
PGP/GnuPG  (GNU Privacy Guard) are tools for encrypting and signing documents using hash functions, symmetric key algorithms, and public key algorithms

How do I know I have the right public key for someone?
 - just because I have a public key that says it is from Justin Trudeau,
   do I really think that's the case?

Why not use digital signatures to authenticate public keys?

A public key + metadata => certificate

Note that all the lock icon means in a web browser is that
 - the connection used TLS
 - TLS connection was secured using a certificate signed by a known authority

It says nothing about the security of the website itself

There are almost no proofs in cryptography
 - just puzzles nobody has solved yet
 - so algorithms & protocols regularly are found to be "broken" and
   then we switch to new ones


certificates are used to secure websites, and secure code
 - same tech!

mobile devices only run code signed with approved certificates
  - many many fewer ones than in web browsers!

In Xcode, you have to configure a key that Apple signs
 - otherwise, you wouldn't be able to get an iPhone to run your code
 - that signature is specific to your device, won't work on any iPhone
    - if you want that, you have to go through the App Store