A few words of praise for mitmproxy.  This useful tool lets you monitor TLS-encrypted communications from a device, provided you can install a trusted Certificate Authority (CA) key on it (and provided the application on the device accepts TLS certificates signed by this CA key).

The idea is that TCP traffic from the device, and HTTP traffic in particular, is routed through mitmproxy.  Whenever the device acts as TLS client to establish a TLS connection with a TLS server, mitmproxy intercepts the certificate that the server returns, extracts the Common Name and Subject Alternative Name fields, copies those into a new certificate with a public key for which it knows the private key, and signs this new certificate using the mitmproxy CA key before passing it back to the device.  In this way the device believes it is communicating with the TLS server it was expecting, while mitmproxy can establish a link with the TLS server, and forward device traffic to the server, and server traffic to the device, while logging both. In fact, mitmproxy generates a 2048-bit RSA key as CA key when it first runs, and uses this same key on subsequent runs.  The certificates it generates for TLS sessions are RSA keys, with the same cryptographic parameters as the CA key.

mitmproxy is open source, and can be installed to run on Linux, OS X or Windows, and the target device can be a computer running one of those operating systems or iOS or Android device – there are doubtless other possibilities.  The code is written in Python, and uses the pyOpenSSL library for its cryptography.  The excellent documentation includes advice on how to install the mitmproxy CA key on the target – this can usually be done easily by browsing to mitm.it and selecting the appropriately formatted CA key from the page that mitproxy returns.  Traffic from the device can by routed to mitmproxy by explicitly setting up an HTTP proxy in the device, or transparently by setting up the device to use the IP address of the machine running mitmproxy as gateway: in this latter case, some additional setup is required for mitmproxy to discover the correct destination host name. Other proxy modes are available too.

While mitmproxy is primarily organised around capturing HTTP/HTTPS traffic, it can also be configured to decrypt and log non-HTTP TLS traffic.  And it is not limited to passive capture: powerful addons can be programmed (in Python) to add active manipulation of data.

Recently, Mathy Vanhoef from the University of Leuven published, with his supervisor Frank Piessens, a Key Re-initialisation Attack on WPA/WPA2.  This was significant because these standards are so widely used, and also because there were proofs of strength for the the protocol they attacked (in models which consequently are shown to be inadequate).

WPA and WPA2 are very similar, and each can use either Temporal Key Integrity Protocol (TKIP) or CCMP (CTR with CBC-MAC protocol) for data encryption/authentication. TKIP was included as way for older, insecure, WEP WiFi standard hardware to attain higher security levels, but AES-based CCMP is more secure, so for simplicity we'll assume that's being used in what follows.

In CCMP (Counter mode with Cipher block chaining with Message authentication code Protocol), AES-128 is used in counter mode for traffic encryption – a block cipher used as a stream cipher – with CBC MAC for data authentication, as defined in RFC 3610 (with M = 8, L = 2).  Each encrypted packet is accompanied by a 48-bit packet number PN, which is set to 1 for the first encrypted packet, and incremented by 1 for each encrypted packet until a new PTK is established using the 4-message protocol (see below).  The CCM nonce is constructed from PN and other data static from packet to packet.

Traffic keys for CCMP are established when a device connects to a WiFi access point (AP).  A four-message protocol is used, as defined in 802.11i-2004, and the messages are conveyed in EAPOL packets.  In the first, the AP sends the device a message containing a 256-bit value ANonce.  Then in the second, the device replies with a 256-bit value SNonce.  Both ends of the link compute a 376-bit “Pairwise Transient Key” PTK from a secret password (the WiFi key), the name of the network (SSID), ANonce and SNonce, and the MAC addresses of both AP and device.  This calculation starts by deriving an intermediate value PMK from the secret key using PBKDF2, an intentionally intensive calculation intended to provide some protection against password search.   Once computed, the PTK is split into 3 keys: 128-bit Key Confirmation Key KCK for authenticating messages 2-4, 128-bit Key Encryption Key KEK used for message 3 confidentiality, and 128-bit Temporal Key TK for encrypting and authenticating packet data.  Message 3, sent by the AP, conveys a group key for encryption of broadcast packets, and message 4 is sent by the device to tell the AP it is about to start using the new keys for packet encryption.  Messages 2-4 all incorporate a message integrity code, which both parties, now knowing the KCK, can compute/verify.  They also contain another counter to protect against replay: this counter is set to 0 when the device first associates with the AP, and is incremented by the AP for each EAPOL message it sends; the device replies to any AP message with the same counter value; and the counter is reset to 0 when a PTK is established.

If message 4 is not received by the AP, it will send a new message 3 to the device (with incremented counter); and whenever a device receives a valid message 3 the standard states that it should install the PTK established in messages 1 and 2 for encrypting subsequent 802.11 traffic packets.  The main observation the paper makes is that this is problematic, because the device might already have started using a new PTK, and if it is reinstalled, PN is reset to 1, resulting in repeated use of keystream potentially compromising the encryption, and susceptibility to replay attacks.

Having observed this, Vanhoef went on to examine what happens in WiFi client implementations.  He did this by implementing a Man-in-the-Middle attack, where the MitM presents an access point to the client on a different WiFi channel, with the same MAC address as the real AP.  This MitM can prevent message 4 from reaching the AP, and then delays the transmission of the new message 3 the AP generates.  He found that some devices (Windows 7, Windows 10, iOS 10.3.1) don't accept subsequent message 3 transmissions (in violation of the standard), others don't accept plaintext subsequent message 3 transmissions (OS X 10.9.5 and 10.12, Open BSD 6.1), but others do (wpa_supplicant 2.3 - 2.6, Android 6.0.1, MediaTek).  The authors also describe an attack on some systems that only accept encrypted message 3 transmissions.  In this case, message 3 is not passed on to the device until a second message 3 is generated by the AP, and then both passed on in close succession.  When the device receives the first it installs the new PTK, and uses it with PN=1 to encrypt message 4, but implementation delays may mean that the second message, encrypted under the old PTK, is also accepted; and then the next message the device sends will be encrypted under repeated keystream.

All the systems examined were also susceptible to re-initialisation attacks on the group key exchange protocol.  A Group Temporal Key (GTK), used instead of the TK to protect message broadcast by the AP to multiple devices, is first established using the 4-message handshake discussed above, but is then subsequently updated (e.g. every hour) in a Group Key Handshake.  To do this update, the AP sends the device a new GTK in an EAPOL packet, encrypted with the KEK and integrity-protected with the KCK, and the device replies with an integrity-protected EAPOL message to say that it is now using the new GTK with associated PN reset to 1.  In once variant of the attack, where the AP starts using the new GTK immediately, a MitM prevents the device's Group Handshake Message from reaching the AP; the AP then resends its handshake message with incremented EAPOL counter; finally, the MitM can replay this before an encrypted broadcast from the AP to cause PN to be reset again, compromising broadcast message protection – for example, previous broadcast message can be replayed.

Apparently the standards 802.11 standards are to be updated to prevent these attacks.

Bitcoin has attracted a lot of interest recently, due to its recent high value.  Here we give a quick overview of how it works.

In the bitcoin system, transactions are stored in a distributed e-ledger, the blockchain, which is hard to forge for reasons we'll explore shortly.

A bitcoin transaction consists essentially of a list of inputs, and a list of outputs.  Each output defines an amount of bitcoin (BTC) in units of \(10^{-8}\) BTC, or Satoshi, after the alias Satoshi Nakamoto of the inventor of the bitcoin system, and a corresponding script – a short program in a custom Forth-like language – which typically serves to allocate the bitcoin value to a particular bitcoin address.  Each input to a transaction contains a link to an output of a previous transaction, and has its own accompanying script.  A transaction is only accepted as valid if, for every input, running the input script followed by the script of the linked output gives the result "true".  Elaborate scripts can be used, but usually they follow a simple predefined form to prove that the author of the transaction is a legitimate recipient according to the bitcoin address specified in each of the references outputs.  This proof comes by way of a digital signature using ECDSA, the elliptic curve digital signature algorithm.  In fact, each bitcoin address is a one-way function of an ECDSA verification key (public key).  Usually, the input script simply provides the ECDSA verification key, and a signature of transaction-related data under the corresponding signing key; the output script checks the signature, and that the verification key corresponds to the bitcoin address.  Note that an output of a transaction can only be used once as an input to a subsequent transaction.  Although referenced outputs are fully used up by the transaction, one of the transaction outputs can act as "change".

Transactions are listed in blocks of the blockchain.  Each block consists of a short (80 byte) block header, followed by a list of valid transactions. The block header contains a cryptographic hash dervied (via a Merkle hash tree) from hashes of the transactions, a 32 bit "nonce", the current time, a difficulty target value, the hash of the previous block – hence "block chain", and a hash of all the other data in the block header. The nonce (and the hash on the transactions, via data in a special transaction) are constructed so that the block hash, computed by two applications of the SHA-256 hash function, satisifies a particular criterion: the 256-bit hash considered as a 256-bit integer should be \(\leq\) the difficulty target.

Computing valid blocks is a demanding task, requiring a search over many nonce values.  The search for the next valid block is distributed over nodes in the bitcoin network (which makes a pool of new transactions available), and the difficulty target set by the system (every 2016 blocks, about 2 weeks) so that the expected time for search to succeed is about 10 mins..  When the search succeeds, the updated chain is communicated to other nodes, and the race starts to compute the next block.  Nodes accept the longest chain as the valid one.  Consequently it's hard to replace the blockchain with a forged alternative. The reward for taking part in the block searches is given in bitcoins. The first transaction in a new block is a special transaction with no input (replaced by a text field) and output including the reward amount. The reward was initially 50BTC, and halves every 210,000 blocks: it's curently 12.5 BTC – a consequence is that at most 210,000 × 50 × (1+1/2+1/4+…) = 21,000,000 BTC will ever be minted. Block "miners" are also rewarded with transaction fees: typically the total BTC value of transaction inputs exceeds the total value of outputs by a small amount, and this difference is claimed by the block miner in the output of the first block.  The transactions fees are an incentive to include many transactions in a block.