This document provides a brief introduction to cryptography concepts for developers. It covers asymmetric (public key) encryption using mathematical problems like prime factorization or elliptic curves. It also discusses symmetric encryption, hashing, digital signatures, standards like SSL/TLS, and hardware security mechanisms like smart cards.

1. TIMS Crypto Academy
Brief but deep intro to Cryptography for TIMS Developers
Paul Gillingwater
October 2015

2. Public Key (Asymmetric) encryption
• Relies on mathematical functions which are simple in one direction,
but extremely difficult to solve in reverse – e.g., multiplying together
two large prime numbers is simple and fast – but finding the two
prime factors of such a product is hard, and can take many decades
• Another popular source of such encryption is Elliptic Curve – finding
the discrete logarithm of a random elliptic curve with regard to one of
its base points (ECDLP). Larger curves make more difficult solutions.
• Third is Lattice based algorithms – using discrete points in a non-
Euclidian space. These *may* be better resistant to quantum
solutions, unlike prime factors and ECC

3. Public Keys & Private Keys
• RSA is first popular algorithm based on prime product factor problem
• Primes must be chosen with good randomness, and have similar
lengths
• Compute the product p*q – this gives the key length
• Derive two keys mathematically – one private, and one public
• The public key may be freely shared, while private is kept secret
• This method is known as “asymmetric encryption”
• It’s not perfect – bad keys result in poor protection. Attacks in future
based on quantum computing might be effective. Key length critical!

4. Using Public Keys
• Use PUB to encrypt a plain text – the recipient must use the matching
PRIV to decrypt the text
• Use PRIV to sign a text (which may or may not be encrypted) – the
recipient uses matching PUB to validate the signature (which is based
on an encrypted hash of the message)
• Usually used for short messages, or for protecting a secret key
• Examples include: Diffie-Hellman key exchange, DSA/DSS, RSA & ECC
• N.B. Key length is not comparable between Symmetric and
Asymmetric algorithms

5. Symmetric Encryption
• Uses a single shared secret key for both encrypting and decrypting
• Problem: how to transfer the secret key securely
• Popular algorithms: Twofish, AES (Rijndael), TDES, RC4, IDEA
• Two types: block and stream ciphers. Block works with fixed size
groups of bits, while stream does each bit sequentially
• This method is *much* faster than public key algorithms
• Typically, modern systems combine both methods, public and secret
key – start with asymmetric for key distribution, then switch to
symmetric for the session (e.g. SSL, PGP)

6. Hashes and Digests
• Algorithm used to computer a fixed-length unique code based on
arbitrary input length – from 1 byte to petabytes if desired
• Hash lengths typically 256 bits, 512 bits, etc.
• These are one-way functions – impossible to retrieve original text
from a given hash, and very unlikely in extreme to find collision
• Much stronger than checksums, but more complex to compute
• Algorithms include MD5, SHA1, SHA2 (latter preferred, typically with
256, 384 or 512 bits)
• Not the same as HMAC or TMAC (see later)

7. Using XOR and One Time Pads
• Simplest method of encryption, but can be strongest – but only if the
key chosen is perfectly secure and perfectly random
• Protects a stream of bits by flipping bit depending on key bit
• Key length must be identical to plain text length
• This is the basis of one-time pads
• Problem: distribution of and security of key material
• Ideally, keys should be generated by a truly random physical process,
and not generated by an algorithm

8. DES, 3DES and TDES
• DES was one of earliest symmetric key algorithms [Data Encryption
Standard]
• Original size of 56 bits was overtaken by technology – so Triple DES
was designed using the same encryption three times
• Heavily used in online payment industry (EMV)
• Most cryptographers prefer AES as replacement

9. Public Key Infrastructure
• Centralized database which stores Public Keys for users and devices
• Certificate Authority (CA) manages certificates which contain public
and private keys (often with HSM anchor)
• Registration Authority (RA) verifies identities of users/devices
• CA’s sign and publish the public keys of entities to whoever wants it
• CA is trusted third party – its private key is used to sign the
certificates, which means the trust can be verified
• OCSP is popular protocol to check revocation status
• CA’s handle whole certificate life cycle management

10. Managing Trust with PKI
• Importance of separation of duties (each person has half of key)
• Centralized trust makes for a single point of failure – very top-down
• Hardware Security Module used to protect private keys of CA
• Standards include PKCS#11 and PKCS#15 for certificate operations
• Certificates can be issued with different purposes – e.g., signing
email, encrypting data, etc.
• Certificates based on X.509 standard – these usually do NOT contain
the private keys, which are stored separately in HSM, or in extreme
cases never leave the smart card which generates them

11. Public Key Topics
• Certificate Pinning – a method of keeping a local copy of a certificate,
which can be relied upon, and which can detect unauthorized
changes
• Certificate Stapling is used with OCSP to improve performance of
revocation checking; signed cert attached in SSL startup sequence
• PKCS#11 is API for handling certificates, e.g. with CA’s, HSMs, smart
cards, etc. Designed for all crypto-related functions, including
generating, reading, enrolling, creating and deleting such objects.
• PKCS#8 is standard for storing private keys
• PKCS#15 is standard for smart card objects

12. Standards and Certification
• Evaluation Assurance Levels:
• 1.1 EAL1: Functionally Tested
• 1.2 EAL2: Structurally Tested
• 1.3 EAL3: Methodically Tested and Checked
• 1.4 EAL4: Methodically Designed, Tested and Reviewed
• 1.5 EAL5: Semiformally Designed and Tested
• 1.6 EAL6: Semiformally Verified Design and Tested
• 1.7 EAL7: Formally Verified Design and Tested
• Requires published Security Target for evaluation
• Based on Common Criteria ISO15408 international standard

13. Other Relevant Standards
• FIPS140-2 Specifications for Cryptographic Modules
• ISO17799, replaced by ISO27002 – Information Security Management
• PCI/DSS – Payment Card recommendations (EMV)
• NIST (whole range of various US government standards)
• ANSI X9 series (mostly encryption and key exchange)
• ITU SG17 – Identity Management standards
• ETSI – Identity and Access Management working group
• FIDO Alliance – token for authentication
• OIX – Open Identity Exchange framework (LoA)

14. PGP/GNU Privacy Guard
• Public key encryption and signing using chain of peer-to-peer trust
• Allows creation of keys, which can then be used for encryption and
message confirmation through digital signatures
• Uses standard implementation of popular algorithms (e.g. IDEA)

15. Smart Cards
• Tiny computer embedded in protected chip which runs simple
programs in response to requests (typically, PKCS#11 or PKCS#15)
• Designed to be tamper-resistant – destroys data if broken into
• Contains protected areas which cannot be read by external system
• May require use of PIN, BIO (MoC) or other protections before
releasing sensitive information
• Can perform operations such as signing or encryption/decryption,
based on requests sent to it by driver
• Also can generate its own keys; private key never leaves the chip

16. Smart Card Interfaces
• ISO7816 – uses contacts to interface with a card
• ISO14443 – uses NFC (based on RFID) to communicate with smart
card device
• In both cases, ADPU commands used to request services from cards
• EMV Cards have Card Verification Methods (e.g., local PIN check)
• Cards can detect tampering, e.g. velocity checking
• Some cards support key rotation (replacing or phasing out old keys if
they are compromised)
• Keys managed with ISO11568

17. ePP and ICAO9303
• Methods of mutual authentication of readers and cards, as well as
means to protect card or document reading
• BAC – Basic authentication, requires access to OCR of MRZ as key
• SAC – Supplementary Access Control; anti-eavesdropping used in
parallel with EAC (replaces BAC)
• EAC – Extended Access Control, requires cryptographic checking of
keys used by reader before access is permitted
• Two requirements for EAC: Chip and Terminal authentication (mutual)
• Based on PKI with CVC certificates (available as PKD for offline checks)

18. Network Security and Encryption
• SSL/TLS
• IPSec and VPN implementation
• SSH (tunneling too)
• FIDO tokens and U2F/UAF
• WEP; WPA2/PSK
• JWE/JWT

19. Any questions?