saminiir's hacker blog

Paper storage and recovery of GPG keys

Tue, 16 Oct 2018 10:00:00 +0000

To avoid disastrously losing your private keys, they should be redundantly backed up in a robust manner in a safe location.

As one possible approach, we will store the GPG keyring as QR codes, print them on paper, and demonstrate recovering the keyring. Do note that this method excludes backing up the trust database.

For general GPG usage, consult my previous post on handling GPG keys.

Dependencies
Exporting the key
Backing up the key
Recovering the key
Conclusion
Sources

Dependencies

Consult the Internet or your distro’s package mirrors for the following packages:

Exporting the key

First, we’ll peruse gpg’s manual pages about exporting keys:

--export-secret-keys
--export-secret-subkeys
       Same as --export, but exports the secret keys instead.  The exported keys are written to STDOUT or to the file given with option --output.  This command is often used along with the option  --armor  to  allow  for  easy
       printing  of  the  key  for paper backup; however the external tool paperkey does a better job of creating backups on paper.  Note that exporting a secret key can be a security risk if the exported keys are sent over an
       insecure channel.

Important point being, never transmit private keys over an insecure medium.

Export your private and public keys into a keyring:

$ gpg --export-secret-keys --export-options export-minimal > private-keyring.gpg

The reason I am not using paperkey is that it requires corresponding public keys to be stored elsewhere. I want both private and public keys stored on the paper for easier retrieval in case of emergency.

Backing up the key

Let’s base64 encode the keyring and split it into smaller bytes because of QR code storage limitations¹:

$ base64 private-keyring.gpg > private-keyring.base64
$ split -d -C 2500 private-keyring.base64 splitkey-

Then, we’ll use qrencode² to create QR code pictures:

$ for i in splitkey-*; do qrencode -r $i -o "$i.PNG"; done

Finally, concatenate the pictures into a single photo for printing purposes:

$ montage -mode Concatenate -tile 2x splitkey-*.PNG keyring-qr-codes.PNG

Then, print this on paper.

Recovering the key

Now, what to do when this paper backup is your only option left?

Scan the QR codes from the paper as JPEG, for example (EDIT: Actually, do PNG³).

Use zbarimg to decode the QR codes as data:

$ zbarimg --raw qr-codes.jpg > keyring.base64

Your mileage will probably vary on the scan’s success rate. I had to manually crop the QR codes into separate JPEGs in order to construct the resulting base64 in correct order. zbarimg also adds newlines to the scanned data, so essentially manual reconstruction of the base64 data is needed.

Now, you can import it into a gpg instance:

$ base64 -d keyring.base64 > keyring.gpg
$ mkdir -p .gnupg/private-keys-v1.d
$ gpg --homedir .gnupg --import keyring.gpg
$ gpg -K

You should now be able to decrypt any private data stored.

Conclusion

This approach is just one solution for backing up your GPG keys and recovering them in case of emergency. Also, if disaster strikes, it is good to have some routine/documentation on the recovery actions. This article serves as such document.

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Let's code a TCP/IP stack, 5: TCP Retransmission

Wed, 05 Jul 2017 10:00:00 +0000

At this point we have a TCP/IP stack that is able to communicate to other hosts in the Internet. The implementation so far has been fairly straight-forward, but missing a major feature: Reliability.

Namely, our TCP does not guarantee the integrity of the data stream it presents to applications. Even establishing the connection can fail if the handshake packets are lost in transit.

Introducing reliability and control is our next main focus in creating a TCP/IP stack from scratch.

Automatic Repeat Request
TCP Retransmission
Karn’s Algorithm
Managing the RTO timer
Requesting retransmission
Trying it out
Conclusion
Sources

Automatic Repeat Request

The basis for many reliable protocols is the concept of Automatic Repeat reQuest (ARQ)¹.

In ARQ, a receiver sends acknowledgments for data it has received, and the sender retransmits data it never received acknowledgements for.

As we have discussed, TCP keeps the sequence numbers of transmitted data in memory and responds with acknowledgments. The transmitted data is put into a retransmission queue and timers associated with the data are started. If no acknowledgment for the sequence of data is received before the timer runs out, a retransmission occurs.

As can be seen, TCP builds its reliability on the principles of ARQ. However, detailed implementations of ARQ are involved. Simple questions like “how long should the sender wait for an acknowledgement?” are tricky to answer, especially when maximum performance is desired. TCP extensions like Selective Acknowledgments (SACK)² alleviate efficiency problems by acknowledging out-of-order data and avoiding unnecessary round-trips.

TCP Retransmission

Retransmissions in TCP are described in the original specification³ as:

When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted.

However, the original formula for calculating the retransmission timeout was deemed inadequate for different network environments. The current “standard method”⁴ was described by Jacobson⁵ and the latest codified specification can be found from RFC6298⁶.

The basic algorithm is relatively straightforward. For a given TCP sender, state variables are defined for calculating the timeout:

srtt is smoothed round-trip time for averaging the round-trip time (RTT) of a segment
rttvar holds the round-trip time variation
rto eventually holds the retransmission timeout, e.g. in milliseconds

In short, srtt acts as a low-pass filter for consecutive RTTs. Due to possible large variation in the RTT, rttvar is used to detect those changes and prevent them from skewing the averaging function. Additionally, a clock granularity of G seconds is assumed.

As described in RFC6298⁶, the steps for computation are as follows:

Before the first RTT measurement:
```
rto = 1000ms
```

On the first RTT measurement R:

srtt = R
rttvar = R/2
rto = srtt + max(G, 4*rttvar)

On subsequent measurements:

alpha = 0.125
beta = 0.25
rttvar = (1 - beta) * rttvar + beta * abs(srtt - r)
srtt = (1 - alpha) * srtt + alpha * r
rto = srtt + max(g, 4*rttvar)

After computing rto, if it is less than 1 second, round it up to 1 second. A maximum amount can be provided but it has to be at least 60 seconds

The clock granularity of TCP implementations has traditionally been estimated to be fairly high, ranging from 500ms to 1 second. Modern systems like Linux, however, use a clock granularity of 1 millisecond⁴.

One thing to note is that the RTO is suggested to always be at least 1 second. This is to guard against spurious retransmissions, i.e. when a segment is retransmitted too soon, causing congestion in the network. In practice, many implementations go for sub-second rounding: Linux uses 200 milliseconds.

Karn’s Algorithm

One mandatory algorithm that prevents the RTT measurement from giving false results is Karn’s Algorithm⁷. It simply states that the RTT samples should not be taken for retransmitted packets.

In other words, the TCP sender keeps track whether the segment it sent was a retransmission and skips the RTT routine for those acknowledgments. This makes sense, since otherwise the sender could not distinguish acknowledgements between the original and retransmitted segment.

When utilizing the timestamp TCP option, however, the RTT can be measured for every ACK segment. We will deal with the TCP Timestamp option in a separate blog post.

Managing the RTO timer

Managing the retransmission timer is relatively straightforward. RFC6298 recommends the following algorithm:

When sending a data segment and the RTO timer is not running, activate it with the timeout value of rto
When all outstanding data segments have been acknowledged, turn off the RTO timer
When an ACK is received for new data, restart the RTO timer with the value of rto

And when the RTO timer expires:

Retransmit the earliest unacknowledged segment
Back off the RTO timer with a factor of 2, i.e. (rto = rto * 2)
Start the RTO timer

Additionally, when the backing off of the RTO value occurs and a subsequent measurement is successfully made, the RTO value can shrink drastically. The TCP implementation may clear srtt and rttvar when backing off and waiting for an acknowledgment⁶.

Requesting retransmission

A TCP is usually not only relying on the TCP sender’s timers to fix lost packets. The receiving side can also inform the sender that segments need to be retransmitted.

Duplicate acknowledgment is an algorithm where out-of-sequence segments are acknowledged, but by the sequence number of the latest in-order segment. After three duplicate acknowledgments, the TCP sender should realize that it needs to retransmit the segment that was advertised by the duplicate acknowledgments.

Furthermore, Selective Acknowledgment (SACK) is a more sophisticated version of the duplicate acknowledgment. It is a TCP option where the receiver is able to encode the received sequences into its acknowledgements. Then the sender immediately notices any lost segments and resends them. We will discuss the SACK TCP option in a later blog post.

Trying it out

Now that we’ve gone through the concepts and general algorithms, let’s see how TCP retransmissions look like on the wire.

Let’s change the firewall rules to drop packets after the connection is established and try to fetch the front page of HN:

$ iptables -I FORWARD --in-interface tap0 \
	-m conntrack --ctstate ESTABLISHED \
	-j DROP
$ ./tools/level-ip curl news.ycombinator.com
curl: (56) Recv failure: Connection timed out

Observing the connection traffic we see that the HTTP GET is retransmitted with roughly a doubling interval:

[saminiir@localhost ~]$ sudo tcpdump -i tap0 host 10.0.0.4 -n -ttttt
00:00:00.000000 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [S], seq 3975419138, win 44477, options [mss 1460], length 0
00:00:00.004318 IP 104.20.44.44.80 > 10.0.0.4.41733: Flags [S.], seq 4164704437, ack 3975419139, win 29200, options [mss 1460], length 0
00:00:00.004534 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [.], ack 1, win 44477, length 0
00:00:00.011039 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:00:01.094237 IP 104.20.44.44.80 > 10.0.0.4.41733: Flags [S.], seq 4164704437, ack 3975419139, win 29200, options [mss 1460], length 0
00:00:01.094479 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [.], ack 1, win 44477, length 0
00:00:01.210787 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:00:03.607225 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:00:08.399056 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:00:18.002415 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:00:37.289491 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:01:15.656151 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1
00:02:32.590664 IP 10.0.0.4.41733 > 104.20.44.44.80: Flags [P.], seq 1:85, ack 1, win 44477, length 84: HTTP: GET / HTTP/1.1

Verifying the retransmission back-off and the receiver going silent is easy, but what about the scenario when retransmissions are triggered only for some segments? For optimal performance, the RTO algorithm needs to ‘bounce back’ when the connection is detected as healthy.

Let’s set the firewall rule to only block the 6th packet for 6000 bytes:

$ iptables -I FORWARD --in-interface tap0 \
	-m connbytes --connbytes 6 \
	--connbytes-dir original --connbytes-mode packets \
	-m quota --quota 6000 -j DROP

Now, if we try to send some data, our TCP has to recognize the communication blackout and when it ends. Let’s send 6009 bytes:

$ ./tools/level-ip curl -X POST http://httpbin.org/post \
	-d "payload=$(perl -e "print 'lorem ipsum ' x500")"

Let’s step through the connection phases, see when retransmissions are triggered and how the RTO value changes. Below is a modified tcpdump output with inline comments about our TCP socket’s internal state:

00.000000 10.0.0.4.49951 > httpbin.org.80: [S], seq 1, options [mss 1460]
00.120709 httpbin.org.80 > 10.0.0.4.49951: [S.], seq 1, ack 1, options [mss 8961]
00.120951 10.0.0.4.49951 > httpbin.org.80: [.], ack 1

- Connection established, TCP RTO value of 10.0.0.4:49951 is 1000 milliseconds.

00.122686 10.0.0.4.49951 > httpbin.org.80: [P.], seq 1:174, ack 1: POST /post
00.242564 httpbin.org.80 > 10.0.0.4.49951: [.], ack 174
01.141287 10.0.0.4.49951 > httpbin.org.80: [.], seq 174:1634, ack 1: HTTP
01.141386 10.0.0.4.49951 > httpbin.org.80: [.], seq 1634:3094, ack 1: HTTP
01.141460 10.0.0.4.49951 > httpbin.org.80: [.], seq 3094:4554, ack 1: HTTP
01.263301 httpbin.org.80 > 10.0.0.4.49951: [.], ack 1634
01.265995 httpbin.org.80 > 10.0.0.4.49951: [.], ack 3094

- So far so good, the remote host has acked our HTTP POST 
  and the start of our payload. RTO value is 336ms.

01.526797 10.0.0.4.49951 > httpbin.org.80: [.], seq 3094:4554, ack 1: HTTP
02.259425 10.0.0.4.49951 > httpbin.org.80: [.], seq 3094:4554, ack 1: HTTP
03.735553 10.0.0.4.49951 > httpbin.org.80: [.], seq 3094:4554, ack 1: HTTP

- The communication blackout caused by our iptables rule has started.
  Our TCP has to retransmit the segment multiple times. 
  The RTO value of the socket keeps increasing:
    01.526797: 618ms
    02.259425: 1236ms
    03.735553: 2472ms

06.692867 10.0.0.4.49951 > httpbin.org.80: [.], seq 3094:4554, ack 1: HTTP
06.819115 httpbin.org.80 > 10.0.0.4.49951: [.], ack 4554

- Finally the remote host responds. Our RTO value has increased to 4944ms.
  Karn\'s Algorithm takes effect here: The new RTO value cannot be measured
  with the retransmitted segment, so we skip it.

06.819356 10.0.0.4.49951 > httpbin.org.80: [.], seq 4554:6014, ack 1: HTTP
06.819442 10.0.0.4.49951 > httpbin.org.80: [P.], seq 6014:6182, ack 1: HTTP
06.948678 httpbin.org.80 > 10.0.0.4.49951: [.], ack 6014
06.948917 httpbin.org.80 > 10.0.0.4.49951: [.], ack 6182

- Now we get ACKs on the first try and the network is relatively healthy again.
  Karn\'s Algorithm allows us to measure the new RTO:
    06.948678: 309ms
    06.948917: 309ms
  
06.948942 httpbin.org.80 > 10.0.0.4.49951: [P.], seq 1:26, ack 6182: HTTP 100 Continue
06.949014 httpbin.org.80 > 10.0.0.4.49951: [.], seq 26:1486, ack 6182: HTTP/1.1 200 OK
06.949145 10.0.0.4.49951 > httpbin.org.80: [.], ack 26
06.949816 httpbin.org.80 > 10.0.0.4.49951: [.], seq 1486:2946, ack 6182: HTTP
06.949894 httpbin.org.80 > 10.0.0.4.49951: [.], seq 2946:4406, ack 6182: HTTP
06.950029 10.0.0.4.49951 > httpbin.org.80: [.], ack 2946
06.950030 httpbin.org.80 > 10.0.0.4.49951: [.], seq 4406:5866, ack 6182: HTTP
06.950161 httpbin.org.80 > 10.0.0.4.49951: [P.], seq 5866:6829, ack 6182: HTTP
06.950287 10.0.0.4.49951 > httpbin.org.80: [.], ack 5866
06.950435 10.0.0.4.49951 > httpbin.org.80: [.], ack 6829
06.958155 10.0.0.4.49951 > httpbin.org.80: [F.], seq 6182, ack 6829
07.082998 httpbin.org.80 > 10.0.0.4.49951: [F.], seq 6829, ack 6183
07.083253 10.0.0.4.49951 > httpbin.org.80: [.], ack 6830

- The data communication and connection is finished.
  No significant changes to the RTO measurement occur.

Conclusion

Retransmissions in TCP are an essential part of a robust implementation. A TCP has to survive and be performant in changing network environments, where for example the latencies can suddenly spike or the network path is blocked for a moment.

Next time, we will take a look at TCP Congestion Control for achieving maximum performance without degrading the network’s health.

I’d be happy if you try the project out and give feedback. See Getting Started on how to use it with cURL and Firefox!

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Let's code a TCP/IP stack, 4: TCP Data Flow & Socket API

Tue, 06 Dec 2016 12:00:00 +0000

Previously, we introduced ourselves to the TCP header and how a connection is established between two parties.

In this post, we will look into TCP data communication and how it is managed.

Additionally, we will provide an interface from the networking stack that applications can use for network communication. This Socket API is then utilized by our example application to send a simple HTTP request to a website.

Transmission Control Block
TCP Data Communication
TCP Connection Termination
Socket API
Testing our Socket API
Conclusion
Sources

Transmission Control Block

It is beneficial to start the discussion on TCP data management by defining the variables that record the data flow state.

In short, the TCP has to keep track of the sequences of data it has sent and received acknowledgments for. To achieve this, a data structure called the Transmission Control Block (TCB) is initialized for every opened connection.

The variables for the outgoing (sending) side are:

    Send Sequence Variables
	
      SND.UNA - send unacknowledged
      SND.NXT - send next
      SND.WND - send window
      SND.UP  - send urgent pointer
      SND.WL1 - segment sequence number used for last window update
      SND.WL2 - segment acknowledgment number used for last window update
      ISS     - initial send sequence number

In turn, the following data is recorded for the receiving side:

    Receive Sequence Variables
											  
      RCV.NXT - receive next
      RCV.WND - receive window
      RCV.UP  - receive urgent pointer
      IRS     - initial receive sequence number

Additionally, helper variables of the current segment being processed are defined followingly:

    Current Segment Variables
	
      SEG.SEQ - segment sequence number
      SEG.ACK - segment acknowledgment number
      SEG.LEN - segment length
      SEG.WND - segment window
      SEG.UP  - segment urgent pointer
      SEG.PRC - segment precedence value

Together, these variables constitute most of the TCP control logic for a given connection.

TCP Data Communication

Once a connection is established, explicit handling of the data flow starts. Three variables from the TCB are important for basic tracking of the state:

SND.NXT - The sender will track the next sequence number to use in SND.NXT.
RCV.NXT - The receiver records the next sequence number to expect in RCV.NXT.
SND.UNA - The sender will record the oldest unacknowledged sequence number in SND.UNA.

Given a sufficient time period when TCP is managing the data communication and no transmit occurs, all these three variables will be equal.

For example, when A decides to send a segment with data to B, the following happens:

TCP A sends a segment and advances SND.NXT in its own records (TCB).
TCB B receives the segment and acknowledges it by advancing RCV.NXT and sends an ACK.
TCB A receives the ACK and advances SND.UNA.

The amount by which the variables are advanced is the length of the data in the segment.

This is the basis for TCP control logic over the transmit of data. Let’s see how this looks like with tcpdump(1), a popular utility for capturing network traffic:

[saminiir@localhost level-ip]$ sudo tcpdump -i any port 8000 -nt
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [S], seq 1525252, win 29200, length 0
IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [S.], seq 825056904, ack 1525253, win 29200, options [mss 1460], length 0
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 1, win 29200, length 0

The address 10.0.0.4 (host A) initiates a connection from port 12000 to host 10.0.0.5 (host B) listening on port 8000.

After the three-way handshake, the connection is established and their internal TCP socket state is set to ESTABLISHED. Initial sequence numbers are 1525252 for A, and 825056904 for B.

IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [P.], seq 1:18, ack 1, win 29200, length 17
IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [.], ack 18, win 29200, length 0

Host A sends a segment with 17 bytes of data, which host B acknowledges with an ACK segment. Relative sequence numbers are shown by default with tcpdump to ease readability. Thus, ack 18 is actually 1525253 + 17.

Internally, the TCP of the receiving host (B) has advanced RCV.NXT with the number 17.

IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 1, win 29200, length 0
IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [P.], seq 1:18, ack 18, win 29200, length 17
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 18, win 29200, length 0
IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [P.], seq 18:156, ack 18, win 29200, length 138
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 156, win 29200, length 0
IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [P.], seq 156:374, ack 18, win 29200, length 218
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 374, win 29200, length 0

The interplay of sending data and acknowledging it continues. As can be seen, the segments with length 0 only have the ACK flag set, but the acknowledgement sequence numbers are precisely increment based on the previously received segment’s length.

IP 10.0.0.5.8000 > 10.0.0.4.12000: Flags [F.], seq 374, ack 18, win 29200, length 0
IP 10.0.0.4.12000 > 10.0.0.5.8000: Flags [.], ack 375, win 29200, length 0

Host B informs host A that it has no more data to send by generating a FIN segment. In turn, host A acknowledges this.

To finish the connection, host A also has to signal that it has no more data to send.

TCP Connection Termination

Closing a TCP connection is likewise an involved operation, and can be forcibly terminated (RST) or finished with a mutual agreement (FIN).

The basic scenario is as follows:

The active closer sends a FIN segment.
The passive closer acknowledges this by sending an ACK segment.
The passive closer starts its own close operation (when it has no more data to send) and effectively becomes an active closer.
Once both sides have sent a FIN to each other and they have acknowledged them to both directions, the connection closes.

Evidently, the closing of a TCP connection requires four segments, in contrast to the three segments of the TCP connection establishment (three-way handshake).

Additionally, TCP is a bi-directional protocol, so it is possible to have the other end announce it has no more data to send, but stay online for incoming data. This is called TCP Half-close.

The unreliable nature of packet-switched networks introduce additional complexity to the connection termination - FIN segments can disappear or never intentionally be sent, which leaves the connection in an awkward state. For example, in Linux the kernel parameter tcp_fin_timeout controls how many seconds TCP waits for a final FIN packet, before forcibly closing the connection. This is a violation of the specification, but is needed for Denial of Service (DoS) prevention.¹

Aborting a connection involves a segment with the RST flag set. Resets can occur because of many reasons, but some usual ones are:

Connection request to a nonexistent port or interface
The other TCP has crashed and ends up in a out-of-sync connection state
Attempts to disturb existing connections²

Thus, the happy path of TCP data transmission never involves a RST segment.

Socket API

To be able to utilize the networking stack, some kind of an interface has to be provided for applications. The BSD Socket API is the most famous one and it originates from the 4.2BSD UNIX release from 1983.³ The Socket API in Linux is compatible to the BSD Socket API.⁴

A socket is reserved from the networking stack by calling socket(2), passing the type of the socket and protocol as parameters. Common values are AF_INET for the type and SOCK_STREAM as domain. This will default to a TCP-over-IPv4 socket.

After succesfully reserving a TCP socket from the networking stack, it will be connected to a remote endpoint. This is where connect(2) is used and calling it will launch the TCP handshake.

From that point on, we can just write(2) and read(2) data from our socket.

The networking stack will handle queueing, retransmission, error-checking and reassembly of the data in the TCP stream. For the application, the inner acting of TCP is mostly opaque. The only thing the application can rely on is that the TCP has acknowledged the responsibility of sending and receiving the stream of data, and that it will inform the application of unexpected behavior through the socket API.

As an example, let’s look at the system calls that a simple invocation of curl(1) does:

$ strace -esocket,connect,sendto,recvfrom,close curl -s example.com > /dev/null
...
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("93.184.216.34")}, 16) = -1 EINPROGRESS (Operation now in progress)
sendto(3, "GET / HTTP/1.1\r\nHost: example.co"..., 75, MSG_NOSIGNAL, NULL, 0) = 75
recvfrom(3, "HTTP/1.1 200 OK\r\nCache-Control: "..., 16384, 0, NULL, NULL) = 1448
close(3)                                = 0
+++ exited with 0 +++

We observe the Socket API calls with strace(1), a tool for tracing system calls and signals. The steps are:

A socket is opened with socket, and the type is specified as IPv4/TCP.
connect launches the TCP handshake. Destination address and port are passed to the function.
After the connection is successfully established, sendto(3) is used to write data to the socket - in this case, the usual HTTP GET request.
From that point on, curl eventually reads the incoming data with recvfrom.

The astute reader may have noticed that no read or write system calls were placed. This is because the actual socket API does not contain those functions, but normal I/O operations can also be used. From man socket(7):⁴

In addition, the standard I/O operations like write(2), writev(2), sendfile(2), read(2), and readv(2) can be used to read and write data.

In the end, the Socket API contains multiple functions for just writing and reading data. This is complicated by the I/O family of functions, which can also be used to manipulate the socket’s file descriptor.

Testing our Socket API

Now that our networking stack provides a socket interface, we can write applications against it.

The popular tool curl is used to transmit data with a given protocol. We can replicate the HTTP GET behavior of curl by writing a minimal implementation:

$ ./lvl-ip curl example.com 80

...
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is established to be used for illustrative examples in documents. You may use this
    domain in examples without prior coordination or asking for permission.</p>
    <p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

In the end, sending a HTTP GET request exercises the underlying networking stack only minimally.

Conclusion

We have now essentially implemented a rudimentary TCP with simple data management and provided an interface applications can use.

However, TCP data communication is not a simple problem. The packets can get corrupted, reordered or lost in transit. Furthermore, the data transmit can congest arbitrary elements in the network.

For this, the TCP data communication needs to include more sophisticated logic. In the next post, we will look into TCP Window Management and TCP Retransmission Timeout mechanisms, to better cope with more challenging settings.

The source code for the project is hosted at GitHub.

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Configuring Arch Linux on Dell XPS 15

Sun, 26 Jun 2016 08:00:00 +0000

In the previous post, we’ve successfully booted into Arch Linux from our encrypted root partition.

Let’s now configure it to our (my) liking.

User management
Arch User Repository
X11 and Window Manager: dwm
Terminal: xterm
Input: Trackpad gestures (libinput)
Sound
Storage: NVMe SSD
Graphics: Nvidia and Bumblebee
Power Management
Suspend/hibernate
- Debugging suspend/hibernation
- Locking screen on sleep
Networking: netctl, Unbound
Security
Browser: Firefox
Backups: rsnapshot
Password Management: pass
Gaming: Steam/Wine
- Gamepad
iPhone
Sources

User management

# Add new user
$ useradd -m -G wheel saminiir

# Uncomment wheel group
$ grep wheel /etc/sudoers
%wheel ALL=(ALL) ALL
# %wheel ALL=(ALL) NOPASSWD: ALL

# Harden the root pasword if necessary
$ passwd

Arch User Repository

The Arch User Repository (AUR) contains community-driven packages. yaourt is a popular front-end for it. Enable it by:

$ pacman -S git
$ git clone https://aur.archlinux.org/package-query.git
$ cd package-query
$ makepkg -si
$ cd ..
$ git clone https://aur.archlinux.org/yaourt.git
$ cd yaourt
$ makepkg -si
$ cd ..

X11 and Window Manager: dwm

Determine your 3D card:

$ lspci | grep -e VGA -e 3D
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)

# Install nvidia proprietary drivers (pulls in xorg as well)
# Be sure to select nvidia and libinput if it prompts for the repo extras
$ pacman -S nvidia

$ pacman -S xorg-server-utils xorg-xinit
$ pacman -S openssh slock terminus-font

$ git clone https://github.com/saminiir/dotfiles.git
$ ln -s ~/dotfiles/xorg/xinitrc .xinitrc
$ ln -s ~/dotfiles/xorg/Xresources .Xresources

Configure dwm to e.g. use xterm as terminal and change the modifier key to Windows key (Mod4Mask):

$ git clone https://aur.archlinux.org/dwm-git.git
$ cd dwm-git && makepkg

$ grep "define MODKEY" src/dwm/config.h
#define MODKEY Mod4Mask

$ grep "char \*termcmd" src/dwm/config.h
static const char *termcmd[]  = { "xterm", NULL };

$ makepkg -fi

$ startx

dwm should start.

Terminal: xterm

For some reason, I’m stuck on using xterm. Even its manual page says that it needs to be rewritten, so feel free to go find an alternative.

For the rest of us, at least the following tweaks are useful:

# Make bash auto-complete better
$ pacman -S bash-completion

# Install Google's `noto` font package
$ pacman -S noto-fonts

# For easy command-on-key binding
$ pacman -S xbindkeys

Finally, use the .Xresources from my dotfiles:

$ git clone git@github.com:saminiir/dotfiles.git
$ cd ~ && ln -s ~/dotfiles/xorg/Xresources .Xresources

Important things for me is that Caps Lock is mapped as a Control key, and that the Alt (or whatever is left of space bar) acts as Meta. These can be found from the dotfiles, but I’ll highlight them here too:

# No caps lock - Map it as ctrl instead
$ setxkbmap -option ctrl:nocaps

# Kill X11 with ctrl+alt+backspace
$ setxkbmap -option terminate:ctrl_alt_bksp

# Change keyboard layout on right shift
$ setxkbmap -layout us,fi -option grp:rshift_toggle

$ grep meta~/.Xresources 
xterm*metaSendsEscape: true

Furthermore, I like to have my tilde character lower on the keyboard, on the right side of left-shift:

$ grep tilde /usr/share/X11/xkb/symbols/pc
    key <LSGT> {        [ grave, asciitilde, grave, asciitilde ] };

Additionally, increase the Linux console font size:

$ cat /etc/vconsole.conf
FONT=ter-i32n

And apply it to early userspace too:

$ grep consolefont /etc/mkinitcpio.conf
HOOKS="base udev autodetect modconf block encrypt lvm2 resume filesystems keyboard fsck consolefont"

$ mkinitcpio -p linux

Input: Trackpad gestures (libinput)

I chose to use libinput over synaptics for the touchpad driver.

$ pacman -S libinput xf86-input-libinput
$ libinput-list-devices
$ xinput list-props "DLL06E4:01 06CB:7A13 Touchpad"

# Enable tap-click
$ xinput set-prop "DLL06E4:01 06CB:7A13 Touchpad" "libinput Tapping Enabled" 1

# Increase pointer acceleration
$ xinput set-prop "DLL06E4:01 06CB:7A13 Touchpad" "libinput Accel Speed" 1

These can be found from xutils in my dotfiles (described above).

Sound

Just install alsa-utils, and use alsamixer to unmute the master channel. Should just work.

For keyboard hotkeys, add the following to xbindkeys configuration:

$ grep -A1 amixer ~/.xbindkeysrc
"/usr/bin/amixer set Master 5%+"
    XF86AudioRaiseVolume
--
"/usr/bin/amixer set Master 5%-"
    XF86AudioLowerVolume
--
"/usr/bin/amixer set Master toggle"
    XF86AudioMute

Storage: NVMe SSD

Trimming is an operation SSDs benefit greatly of. However, enabling it for encrypted drives is a security risk¹. The options are to enable trim and suffer the weakened security, or at regular intervals take maintenance on the drive.

One way of minimizing writes, which can especially wear down SSD, is to use the noatime or relatime in the drives mount options. For me, this was enabled by default:

$ grep relatime /etc/fstab

.. relatime ..

Graphics: Nvidia and Bumblebee

Let’s install bumblebee for smart switching of the integrated and dedicated graphics:

$ pacman -S bumblebee primus bbswitch

# Should show the traditional 3D-accelerated gears
$ primusrun glxgears

# Reboot. After rebooting, you should see that bbswitch has disabled the card,
# which is good for saving the battery on the laptop
$ cat /proc/acpi/bbswitch
0000:01:00.0 OFF

Power Management

Powertop

powertop is the best. Install it.

$ pacman -S powertop

Run calibration as many times as you like. Eventually, powertop will start to show accurate power consumption estimates. Additionally, run it also with --auto-tune:

$ powertop --calibrate
$ powertop --auto-tune

Also, add a systemd service for autotuning on startup:

$ cat /etc/systemd/system/powertop.service
[Unit]
Description=Powertop tunings

[Service]
Type=oneshot
ExecStart=/usr/bin/powertop --auto-tune

[Install]
WantedBy=multi-user.target

$ systemctl enable powertop.service

Battery status

I use the command acpi -b for checking battery status. You need the package acpi for it.

Backlight

The display’s backlight is a huge power drain, and it is often convenient to have a hotkey to adjust it.

$ pacman -S light

Now, add commands to xbindkeys for manipulating the backlight:

$ grep -A3 light ~/.xbindkeysrc
"/usr/bin/light -U 5"
    m:0x0 + c:232
    XF86MonBrightnessDown

"/usr/bin/light -A 5"
    m:0x0 + c:233
    XF86MonBrightnessUp

Laptop mode

Also, activate laptop-mode²:

$ cat /etc/sysctl.d/laptop.conf
vm.laptop_mode = 5

Suspend/hibernate

Add resume to the kernel parameters:

$ vi /boot/loader/entries/arch-encrypted-lvm.conf
options ... resume=/dev/mapper/MyVol-swap quiet rw

Add the resume hook to initramfs.

$ vi /etc/mkinitcpio.conf
HOOKS="base ... lvm2 resume ..."

Note that the resume hook should be after lvm2!

Then, regenerate the initramfs:

$ mkinitcpio -p linux

Debugging suspend/hibernation

If suspend/hibernation does not work at first, debug it by setting pm_test

$ cat /sys/power/pm_test
none core processors platform devices freezer

$ echo freezer | sudo /sys/power/pm_test
$ systemctl suspend
$ systemctl hybrid-sleep

Go through the different stages (freezer, devices..) and watch the output of journalctl -r for what goes wrong.

Locking screen on sleep

I want to lock the screen (slock) whenever the system is put to sleep.

This can be achieved by setting systemd units that have the sleep.target activated³. See more examples from dotfiles/systemd:

$ cat /etc/systemd/system/suspend@saminiir.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
ExecStart=/usr/bin/slock
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target

$ systemctl enable suspend@saminiir.service

Networking: netctl, Unbound

Use whatever network manager that rows your boat. I have experience in NetworkManager, but the default netctl in Arch Linux might be worth using too.

I’ve used dnsmasq in the past, but unbound seems like a cool caching DNS resolver that handles DNSSEC as well.

$ pacman -S expat unbound

See the documentation how to configure it. Most importantly your /etc/resolv.conf should point to 127.0.0.1 to use your own DNS program.

$ cat /etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 127.0.0.1

Security

These are the basic steps I took to harden my Arch Linux.

To lockout a user for ten minutes after three failed login attempts:

$ grep pam_tally /etc/pam.d/system-login
#auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
auth       required   pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog

Do not allow SSH login as root:

$ grep PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin no

Restrict access to dmesg:

$ cat /etc/sysctl.d/50-dmesg-restrict.conf

kernel.dmesg_restrict = 1

Configure firewall to drop pretty much all incoming connections, but allow outgoing and already established ones:

$ cat /etc/iptables/iptables.rules
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT

Do the same for IPv6 (ip6tables). You have to adjust some of the rules to IPv6.

Harden the Linux TCP/IP stack:

$ cat /etc/sysctl.d/51-tcp-ip-stack.conf

net.ipv4.tcp_rfc1337 = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.send_redirects = 0

## ICMP routing redirects (only secure)
##net.ipv4.conf.all.secure_redirects = 1 (default)
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

Browser: Firefox

I use Firefox. With a high DPI screen, however, you should increase the pixel density. Go to about:config and set the layout.css.devPixelsPerPx to 2.

Backups: rsnapshot

I use rsnapshot⁴. TODO.

Password Management: pass

This is kind of an extra section, since password management is pretty personal. I, however, have liked the utility pass, which is a simplistic bash script for linux utilities like pwgen.

$ pacman -S pass

# Or if you have an existing pass-store, e.g. in a private cloud, symlink the folder ~/.password-store to it
$ pass init

pass uses your gpg-keys for encrypting/decrypting the files by default. See my earlier blog post on how to establish GPG.

Then, synchronize the ~/.password-store between computers however you like.

Gaming: Steam/Wine

Because Wine uses 32-bit libraries, you have to enable the multilib repo

# Uncomment multilib repo
$ vi /etc/pacman.conf

$ pacman -S wine lib32-alsa-lib lib32-alsa-plugins
$ pacman -S wine-mono wine_gecko winetricks

Setup a 32-bit wine environment:

$ WINEARCH=win32 WINEPREFIX=~/win32 winecfg

# Install .NET Framework 4.0, just for laughs
$ WINEARCH=win32 WINEPREFIX=~/win32 winetricks -q dotnet45 corefonts

Then, use `winetricks to install Steam:

$ WINEARCH=win32 WINEPREFIX=~/win32 winetricks steam

You should be able to start Steam/Wine. Your mileage may vary. It is easy to have missed lib32 packages on a 64-bit system, so you might have to chase down dependencies.

$ WINEARCH=win32 WINEPREFIX=~/wine32 primusrun wine ~/wine32/drive_c/Program\ Files/Steam/Steam.exe

Gamepad

My generic xbox pad just worked out-of-the-box. See the kernel docs for more info⁵.

$ dmesg | tail -n3
[ 3508.420268] usb 1-1: new full-speed USB device number 5 using xhci_hcd
[ 3508.609392] input: Generic X-Box pad as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input21
[ 3508.609619] usbcore: registered new interface driver xpad

You can test the pad:

$ pacman -S joyutils
$ jstest /dev/input/js0

iPhone

I like the robustness of iPhones. I tried a Sony Z5 Compact, but the first drop broke the glass. My iPhone 5 of three years has taken a substantial amount of beating and does not have a dent. Go figure.

Install libimobiledevice to access the iPhone in Linux:

$ pacman -S libimobiledevice usbmuxd
$ systemctl start usbmuxd

Then, connect your iPhone via USB. Have the screen unlocked. It should be detected:

Jun 28 18:43:24 localhost kernel: ipheth 1-2:4.2: Apple iPhone USB Ethernet device attached
Jun 28 18:43:24 localhost kernel: usbcore: registered new interface driver ipheth
Jun 28 18:43:24 localhost kernel: ipheth 1-2:4.2 enp0s20f0u2c4i2: renamed from eth0

$ idevicepair pair

Then, you can backup your iPhone:

$ idevicebackup2 backup ~/Documents/iphone-backups/

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Installing Arch Linux on Dell XPS 15

Fri, 24 Jun 2016 18:00:00 +0000

So after using a Fedora/Macbook for a while, I got a new work laptop. This time I opted for the Dell XPS 15 with all the bells and whistles¹. It has received great reviews and has been compared to the quality of the Macbook Pro’s.

Installing a UNIX distro is always time-consuming and depending on your desires, the configuration varies a lot. This applies especially to bare-bones distros like Arch Linux: It only provides a compiled kernel and a minimal set of system components (systemd). Rest of the system layout you have to devise yourself.

The overall layout of the final Arch Linux system will be:

UEFI for the boot-system
GPT for the partition table
LUKS for full-disk encryption
LVM for managing volumes on top of LUKS
root and home logical volumes (ext4) and a swap volume
systemd-boot for the boot manager

Booting up Arch Linux
Partitioning: UEFI, GPT and ESP
Disk encryption: LUKS
Volume management: LVM
Install Arch Linux
Boot manager: systemd-boot
Sources

Booting up Arch Linux

My favorite way of booting up a Linux distro is just writing the ISO image to a USB drive.

$ dd bs=4M if=~/Downloads/archlinux-2016.06.01-dual.iso of=/dev/sdX status=progress && sync

This is fast and efficient. The USB drive is ready to be booted from. ‘Nuff said.

If the system does not detect the bootable USB drive, try disabling Secure Boot if you have UEFI enabled. Extra note regarding the NVMe-based SSD drive: I had to change SATA configuration to AHCI (not RAID) from BIOS to get it visible as a block device.

Alternatively, you can check out a way of PXE booting Arch Linux from my previous blog post.

Partitioning: UEFI, GPT and ESP

First, wipe the hard disk. This is important for enhancing the security of the disk encryption, since if the disk is full of random data, info about it is harder to deduce:

$ cryptsetup open --type plain /dev/sdXY container --key-file /dev/random
$ dd if=/dev/zero of=/dev/mapper/container status=progress

Now, make sure you have booted with UEFI:

$ efivar -l

Since we zeroed out the main disk, we need to install a partition table to it. GPT is the recommended approach with UEFI:

$ gdisk /dev/nmve0

Next, we’ll set up the EFI System Partition (ESP) and the main root partition:

# Add a partition of size 512M and change its partition table type to EFI System (1).
# Also, add a second partition that spans the rest of the volume
$ fdisk /dev/nmve0

# Should show "esp" in Flags:
$ parted /dev/nvme0n1 print

# Initialize it as FAT32
$ mkfs.fat -F32 -nESP /dev/nvme0n1p1

# Initialize the root filesystem
$ mkfs.ext4 /dev/nvme0n1p2

Disk encryption: LUKS

Several methods for achieving full disk encryption are available. I chose to use LUKS (dm-crypt), since it is pretty standard and performant in Linux. LUKS utilizes block device encryption, meaning that it operates below the filesystem and everything written to the device is guaranteed to be encrypted. LUKS also adds ease-of-use into the key management.

Utilizing full disk encryption is no panacea - you will still be vulnerable to e.g. cold boot attack², bootloader malware and all other sorts of nasty things. And in the end, if your system is compromized while the disk encryption is unlocked, it is absolutely of no help at that point. I am planning a separate blog post on hardening the boot process.

Encrypt your root partition. Choose a strong passphrase (I prefer the diceware³ method). Also notice, that cryptsetup requires an uppercase ‘yes’ for confirmation. :-)

$ cryptsetup luksFormat /dev/nvme0n1p2
$ cryptsetup open --type luks /dev/nvme0n1p2 lvm

Volume management: LVM

The Arch Linux wiki puts it more concisely than I ever could:

Logical Volume Management utilizes the kernel’s device-mapper feature to provide a system of partitions independent of underlying disk layout. With LVM you abstract your storage and have “virtual partitions”, making extending/shrinking easier (subject to potential filesystem limitations).⁴

In other words, it just makes your life easier. I chose the method of using the Logical Volume Manager (LVM) on top of the LUKS-encrypted partition⁵. No real reason as to why, just that it seemed to be the most simple and robust choice. The major disadvantage of it is that the LVM cannot be used to span multiple physical volumes. For a laptop, this shouldn’t be that much of a problem, however.

Let’s now create the Physical Volume (pv) and Logical Volumes (lv’s) for the main partition layout (swap, root, home):

$ pvcreate /dev/mapper/lvm

$ vgcreate MyVol /dev/mapper/lvm

$ lvcreate -L 8G MyVol -n swap
$ lvcreate -L 25G MyVol -n root
$ lvcreate -l 100%FREE MyVol -n home

$ mkfs.ext4 /dev/mapper/MyVol-root
$ mkfs.ext4 /dev/mapper/MyVol-home
$ mkswap /dev/mapper

$ mount /dev/mapper/MyVol-root /mnt
$ mkdir /mnt/home
$ mount /dev/mapper/MyVol-home /mnt/home
$ swapon /dev/mapper/MyVol-swap

Install Arch Linux

Now it is time to install Arch Linux to our root partition.

First, mount your boot partition that we made earlier:

$ mkdir /mnt/boot
$ mount /dev/nvmen1p1 /mnt/boot

Now let’s install the Arch base system with pacstrap:

$ pacstrap /mnt base base-devel

Other configuration, comments inlined:

# Generate filesystem information
$ genfstab -U /mnt >> /mnt/etc/fstab

# Chroot the installation
$ arch-chroot /mnt /bin/bash

# Uncomment en_US.UTF-8 and generate the locale
$ vi /etc/locale.gen
$ locale-gen

# Create locale.conf
$ cat >>/etc/locale.conf
LANG=en_US.UTF-8

# Set timezone
$ ln -s /usr/share/zoneinfo/Europe/Helsinki /etc/localtime

# Sync the hardware clock
$ hwclock --systohc --utc

Then, configure and regenerate a new initial ramdisk environment:

# Change to: HOOKS="... encrypt lvm2 ... filesystems ..."
$ vi /etc/mkinitcpio.conf

# Generate initramfs
$ mkinitcpio -p linux

Boot manager: systemd-boot

systemd-boot is a boot manager for UEFI systems. It only operates on ESPs and EFI-configured images. The project was previously known as ‘gummiboot’, but was merged into systemd in May 2015⁶.

The kernels we boot with systemd-boot have to be configured with CONFIG_EFI_STUB enabled. This allows the UEFI firmware to act as a bootloader and start the kernel, without needing a separate boot loader such as GRUB. Luckily, the Arch Linux kernels have already been configured so.

# Make sure you're booted into EFI mode and can see efivars:
$ efivar -l

# Make sure your ESP partition (described earlier) is mounted at /boot
$ mount -l | grep boot

# Install systemd-boot
$ bootctl install

After that, you should have a folder /boot/loader/entries. Add the following boot entry file there:

# Get the UUID of your root partition
$ blkid -s UUID -o value /dev/nvme0n1p2

$ cat >>arch-encrypted-lvm.conf
title Arch Linux Encrypted LVM
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img
options cryptdevice=UUID=<UUID>:MyVol root=/dev/mapper/MyVol-root quiet rw

The initrd /intel-ucode.img is the microcode for Intel processors - if you have one, install the intel-ucode package.

Now you can exit the chroot (exit) and reboot. If all went well, you should be asked to unlock the root partition’s encryption and be awarded with a login shell.

In the next post, I’ll describe the steps to configure a straightforward userspace setup for Arch Linux.

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Let's code a TCP/IP stack, 3: TCP Basics & Handshake

Sun, 15 May 2016 09:00:00 +0000

Now that our userspace TCP/IP stack has minimal implementations for Ethernet and IPv4, it is time to look into the dreaded Transmission Control Protocol (TCP).

Operating on the fourth OSI networking layer¹, transport, TCP is responsible for repairing erroneous connections and faults in packet delivery. Indeed, TCP is the workhorse of the Internet, providing reliable communications in virtually all computer networking today.

TCP is not exactly a new protocol - the first specification came out in 1974². A lot of has changed since then and TCP has acquired many extensions and corrections³.

This post will delve into the basic theory behind TCP and attempts to give motivation for its design. Furthermore, we will look into the TCP header and discuss establishing a connection (TCP handshaking). As the last step, we’ll demonstrate the first functionality of TCP in our networking stack.

Reliability mechanisms
TCP Basics
TCP Header Format
TCP Handshake
TCP Options
Testing the TCP Handshake
Conclusion
Sources

Reliability mechanisms

The problem of sending data reliably may seem superficial, but its actual implementation is involved. Mainly, several questions arise regarding error-repair in a datagram-style network:

How long should the sender wait for an acknowledgement from the receiver?
What if the receiver cannot process data as fast as it is sent?
What if the network in between (a router, for example) cannot process data as fast as it is sent?

In all of the scenarios, the underlying dangers of packet-switched networks apply - an acknowledgement from the receiver can be corrupted or even lost in transmit, which leaves the sender in a tricky situation.

To combat these problems, several mechanisms can be used. Perhaps the most common is the sliding window technique, where both parties keep an account of the transmitted data. The window data is considered to be sequential (like a slice of an array) and that window “slides” forward as data is processed (and acknowledged) by both sides:

                 Left window edge             Right window edge
                       |                             |
                       |                             |
          ---------------------------------------------------------
          ...|    3    |    4    |    5    |    6    |    7    |...
          ---------------------------------------------------------
                  ^     ^                            ^    ^
                  |      \                          /     |
                  |       \                        /      |
             Sent and           Window size: 3         Cannot be
             ACKed                                     sent yet

The convenient property of using this kind of a sliding window is that it also alleviates the problem of flow control. Flow control is required, when the receiver cannot process data as fast it is sent. In this scenario, the size of the sliding window would be negotiated to be lower, resulting in throttled output from the sender.

Congestion control, on the other hand, helps the networking stacks in between the sender and receiver to not get congested. There are two general methods for this: in the explicit version, the protocol has a field for specifically informing the sender about the congestion status. In the implicit version, the sender tries to guess when the network is congested and should throttle its output. Overall, congestion control is a complex, recurrent networking problem with accompanying research still being done to this day.⁴

TCP Basics

The underlying mechanisms in TCP are much more involved than in other protocols like UDP and IP. Namely, TCP is a connection-oriented protocol, which means that an unicast communication channel is established between exactly two sides as a first step. This connection is being actively taken care of by both sides: Establishing the connection (Handshaking), informing the other party of the data’s state and possible problems.

The other important property of TCP is that it is a streaming protocol. Unlike UDP, TCP does not guarantee applications steady “chunks” of data as they are sent and received. Rather, the TCP implementation has to buffer the data and when packets get lost, reordered or corrupted, TCP has to wait and organize the the data in the buffer. Only when the data is deemed intact, TCP can hand the data over to the application’s socket.

As TCP operates on data as a stream, the “chunks” from the stream have to be converted into packets that IP can carry. This is called packetization, where the TCP header contains the sequence number of the current index in the stream. This also has the convenient property that the stream can be broken into many variable-sized segments and TCP then knows how to repacketize them.

Similarly to IP, TCP also checks the message for integrity. This is achieved through the same checksum algorithm as in IP, but with added details. Mainly, the checksum is end-to-end, meaning that both the header and the data are included to the checksumming. In addition, a pseudo-header built from the IP header is included.

If a TCP implementation receives corrupted segments, it discards them and does not notify the sender. This error is corrected by a timer set by the sender, which can be used to retransmit a segment if it was never acknowledged by the receiver.

TCP is also a full-duplex system, meaning that traffic can flow simultaneously in both direction. This means that the communicating sides have to keep the sequencing of data to both directions in memory. In more depth, TCP preserves its traffic footprint by including an acknowledgement for the opposite traffic in the segments it sends.

In essence, the sequencing of the data stream is the main principle of TCP. The problem of keeping it synchronized, however, is not a simple one.

TCP Header Format

Next, we’ll define the message header and describe its fields. The TCP header is seemingly simple, but contains a lot of information about the communication state.

The TCP header is 20 octets in size⁵:

        0                            15                              31
       -----------------------------------------------------------------
       |          source port          |       destination port        |
       -----------------------------------------------------------------
       |                        sequence number                        |
       -----------------------------------------------------------------
       |                     acknowledgment number                     |
       -----------------------------------------------------------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       -----------------------------------------------------------------
       |         TCP checksum          |       urgent pointer          |
       -----------------------------------------------------------------

The Source Port and Destination Port fields are used to establish multiple connections from and to hosts. Namely, the Berkeley sockets are the prevalent interface for applications to bind to the TCP networking stack. Through ports, the networking stack knows where to direct the traffic to. As the fields are 16 bits in size, the port values range from 0 to 65535.

Since every byte in the stream is numbered, the Sequence Number represents the TCP segment’s window index. When handshaking, this contains the Initial Sequence Number (ISN).

The Acknowledgment Number contains the window’s index of the next byte the sender expects to receive. After the handshake, the ACK field must always be populated.

The Header Length (HL) field presents the length of the header in 32-bit words.

Next, several flags are presented. The first 4 bits (rsvd) are not used.

Congestion Window Reduced (C) is used for informing that the sender reduced its sending rate.
ECN Echo (E) informs that the sender received a congestion notification.
Urgent Pointer (U) indicates that the segment contains prioritized data.
ACK (A) field is used to communicate the state of the TCP handshake. It stays on for the remainder of the connection.
PSH (P) is used to indicate that the receiver should “push” the data to the application as soon as possible.
RST (R) resets the TCP connection.
SYN (S) is used to synchronize sequence numbers in the initial handshake.
FIN (F) indicates that the sender has finished sending data.

The Window Size field is used to advertise the window size. In other words, this is the number of bytes the receiver is willing to accept. Since it is a 16-bit field, the maximum window size is 65,535 bytes.

The TCP Checksum field is used to verify the integrity of the TCP segment. The algorithm is the same as for the Internet Protocol, but the input segment also contains the TCP data and also a pseudo-header from the IP datagram.

The Urgent Pointer is used when the U-flag is set. The pointer indicates the position of the urgent data in the stream.

After the header, several options can be provided. An example of these options is the Maximum Segment Size (MSS), where the sender informs the other side of the maximum size of the segments.

After the possible options, the actual data follows. The data, however, is not required. For example, the handshake is accomplished with only TCP headers.

TCP Handshake

A TCP connection usually undergoes the following phases: connection setup (handshaking), data transfer and closing of the connection. The following diagrams depicts the usual handshaking routine of TCP:

          TCP A                                                TCP B
    	  
    1.  CLOSED                                               LISTEN
    	
    2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
    	  
    3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
    			
    4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
    			  
    5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

Host A’s socket is in a closed state, which means it is not accepting connections. On the contrary, host B’s socket that is bound to a specific port is listening for new connections.
Host A intends to initiate a connection with host B. Thus, A crafts a TCP segment that has its SYN flag set and also the Sequence field populated with a value (100).
Host B responds with a TCP segment that has its SYN and ACK fields set, and acknowledges A’s Sequence number by adding 1 to it (ACK=101). Likewise, B generates a sequence number (300).
The 3-way handshake is finished by an ACK from the originator (A) of the connection request. The Acknowledgement field reflects the sequence number the host next expects to receive from the other side.
Data starts to flow, mainly because both sides have acknowledged each other’s segment numbers.

This is the common scenario of establishing a TCP connection. However, several questions arise:

How is the initial Sequence number chosen?
What if both sides request a connection for each other at the same time?
What if segments are delayed for some time or indefinitely?

The Initial Sequence Number (ISN) is chosen independently by both communication parties at first contact. As it is a crucial part of identifying the connection, it has to be chosen so that it is most likely unique and not easily guessable. Indeed, the TCP Sequence Number Attack⁶ is the situation where an attacker can replicate a TCP connection and effectively feed data to the target, impersonating as a trusted host.

The original specification suggests that the ISN is chosen by a counter that increments every 4 microseconds. This, however, can be guessed by an attacker. In reality, modern networking stacks generate the ISN by more complicated methods.

The situation where both endpoints receive a connection request (SYN) from each other is called a Simultaneous Open. This is solved by an extra message exchange in the TCP handshake: Both sides send an ACK (without knowing that the other side has done it as well), and both sides SYN-ACK the requests. After this, data transfer commences.

Lastly, the TCP implementation has to have a timer for knowing when to give up on establishing a connection. Attempts are made to re-establish the connection, usually with an exponential backoff, but once the maximum retries or the time threshold is met, the connection is deemed to be non-existant.

TCP Options

The last field in the TCP header segment is reserved for possible TCP options. The original specification provided three options, but later specifications have added many more. Next, we’ll look at the most common options.

The Maximum Segment Size (MSS) option informs the maximum TCP segment size the TCP implementation is willing to receive. The typical value for this is 1460 bytes in IPv4.

The Selective Acknowledgment (SACK) option optimizes the scenario when many packets are lost in transmit and the receiver’s window of data is filled with “holes”. To remedy the resulting degraded throughput, a TCP implementation can inform the sender of the specific packets it did not receive with SACK. Thus, the sender receives information about the state of the data in a more straight-forward manner than with the accumulating acknowledment scheme.

The Window Scale option increases the limited 16-bit window size. Namely, if both sides include this option in their handshake segments, the window size is multiplied with this scale. Having bigger window sizes are mainly important for bulk data transfer.

The Timestamps option allows the sender to place a timestamp into the TCP segment, which then can be used to calculate the RTT for each ACK segment. This information can then be used to calculate the TCP retransmission timeout.

Testing the TCP Handshake

Now that we have the TCP handshake routine mocked and it effectively listens for every port, let’s test it:

[saminiir@localhost ~]$ nmap -Pn 10.0.0.4 -p 1337

Starting Nmap 7.00 ( https://nmap.org ) at 2016-05-08 19:02 EEST
Nmap scan report for 10.0.0.4
Host is up (0.00041s latency).
PORT     STATE SERVICE
1337/tcp open  waste

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

Because of the fact that nmap does a SYN-scan (it only waits for the SYN-ACK to decide if the target’s port is open), it is easy to fool it to think we have an application listening on the port by just returning a SYN-ACK TCP segment.

Conclusion

The minimum viable TCP handshake routine can be done relatively effortless by just picking a Sequence number, setting the SYN-ACK flags and calculating the checksum for the resulting TCP segment.

Next time, we’ll look into the most important responsibility of TCP: Reliable data transfer. Managing the window of the stream is essential for transmitting data with TCP and the logic for it can get somewhat complex.

Furthermore, providing applications a way to bind to the TCP implementation is done with sockets. Thus, we’ll look into the Berkeley Socket API and see if we can mock it for applications, enabling them to use our custom TCP implementation.

The source code for the project is hosted at GitHub.

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Let's code a TCP/IP stack, 2: IPv4 & ICMPv4

Sun, 24 Apr 2016 09:00:00 +0000

This time in our userspace TCP/IP stack we will implement a minimum viable IP layer and test it with ICMP echo requests (also known as pings).

We will take a look at the formats of IPv4 and ICMPv4 and describe how to check them for integrity. Some features, such as IP fragmentation, are left as an exercise for the reader.

For our networking stack IPv4 was chosen over IPv6 since it is still the default network protocol for the Internet. However, this is changing fast¹ and our networking stack can be extended with IPv6 in the future.

Internet Protocol version 4
- Header Format
- Internet Checksum
Internet Control Message Protocol version 4
- Header Format
- Messages and their processing
Testing the implementation
Conclusion
Sources

Internet Protocol version 4

The next layer (L3)² in our implementation, after Ethernet frames, handles the delivery of data to a destination. Namely, the Internet Protocol (IP) was invented to provide a base for transport protocols such as TCP and UDP. It is connectionless, meaning that unlike TCP, all of the datagrams are handled independently of each other in the networking stack. This also means that IP datagrams may arrive out-of-order.³

Furthermore, IP does not guarantee successful delivery. This is a conscious choice taken by the protocol designers, since IP is meant to provide a base for protocols that likewise do not guarantee delivery. UDP is one such protocol.

If reliability between the communicating parties is required, a protocol such as TCP is used on top of IP. In that case, the higher level protocol is responsible for detecting missing data and making sure all of it is delivered.

Header Format

The IPv4 header is typically 20 octets in length. The header can contain trailing options, but they are omitted from our implementation. The meaning of the fields is relatively straightforward and can be described as a C struct:

struct iphdr {
    uint8_t version : 4;
    uint8_t ihl : 4;
    uint8_t tos;
    uint16_t len;
    uint16_t id;
    uint16_t flags : 3;
    uint16_t frag_offset : 13;
    uint8_t ttl;
    uint8_t proto;
    uint16_t csum;
    uint32_t saddr;
    uint32_t daddr;
} __attribute__((packed));

The 4-bit version field indicates the format of the Internet header. In our case, the value will be 4 for IPv4.

The Internet Header Length field ihl is likewise 4 bits in length and indicates the number of 32-bit words in the IP header. Because the field is 4 bits in size, it can only hold a maximum value of 15. Thus the maximum length of an IP header is 60 octets (15 times 32 divided by eight).

The type of service field tos originates from the first IP specification⁴. It has been divided into smaller fields in later specifications, but for simplicity’s sake, we will treat the field as defined in the original specification. The field communicates the quality of service intended for the IP datagram.

The total length field len communicates the length of the whole IP datagram. As it is a 16-bit field, the maximum length is then 65535 bytes. Large IP datagrams are subject to fragmentation, in which they are split into smaller datagrams in order to satisfy the Maximum Transmission Unit (MTU) of different communication interfaces.

The id field is used to index the datagram and is ultimately used for reassembly of fragmented IP datagrams. The field’s value is simply a counter that is incremented by the sending party. In turn, the receiving side knows how to order the incoming fragments.

The flags field defines various control flags of the datagram. In specific, the sender can specify whether the datagram is allowed to be fragmented, whether it is the last fragment or that there’s more fragments incoming.

The fragment offset field, frag_offset, indicates the position of the fragment in a datagram. Naturally, the first datagram has this index set to 0.

The ttl or time to live is a common attribute that is used to count down the datagram’s lifetime. It is usually set to 64 by the original sender, and every receiver decrements this counter by one. When it hits zero, the datagram is to be discarded and possibly an ICMP message is replied back to indicate an error.

The proto field provides the datagram an inherent ability to carry other protocols in its payload. The field usually contains values such as 16 (UDP) or 6 (TCP), and is simply used to communicate the type of the actual data to the receiver.

The header checksum field, csum, is used to verify the integrity of the IP header. The algorithm for it is relatively simple, and will be explained further down in this tutorial.

Finally, the saddr and daddr fields indicate the source and destination addresses of the datagram, respectively. Even though the fields are 32-bit in length and thus provide a pool of approximately 4.5 billion addresses, the address range is going to be exhausted in the near-future⁵. The IPv6 protocol extends this length to 128 bits and as a result, future-proofs the address range of the Internet Protocol, perhaps permanently.

Internet Checksum

The Internet checksum field is used to check the integrity of an IP datagram. Calculating the checksum is relatively simple and is defined in the original specification⁴:

The checksum field is the 16 bit one’s complement of the one’s complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.

The actual⁶ code for the algorithm is as follows:

uint16_t checksum(void *addr, int count)
{
    /* Compute Internet Checksum for "count" bytes
     *         beginning at location "addr".
     * Taken from https://tools.ietf.org/html/rfc1071
     */

    register uint32_t sum = 0;
    uint16_t * ptr = addr;

    while( count > 1 )  {
        /*  This is the inner loop */
        sum += * ptr++;
        count -= 2;
    }

    /*  Add left-over byte, if any */
    if( count > 0 )
        sum += * (uint8_t *) ptr;

    /*  Fold 32-bit sum to 16 bits */
    while (sum>>16)
        sum = (sum & 0xffff) + (sum >> 16);

    return ~sum;
}

Take the example IP header 45 00 00 54 41 e0 40 00 40 01 00 00 0a 00 00 04 0a 00 00 05:

Adding the fields together yields the two’s complement sum 01 1b 3e.
Then, to convert it to one’s complement, the carry-over bits are added to the first 16-bits: 1b 3e + 01 = 1b 3f.
Finally, the one’s complement of the sum is taken, resulting to the checksum value e4c0.

The IP header becomes 45 00 00 54 41 e0 40 00 40 01 e4 c0 0a 00 00 04 0a 00 00 05.

The checksum can be verified by applying the algorithm again and if the result is 0, the data is most likely good.

Internet Control Message Protocol version 4

As the Internet Protocol lacks mechanisms for reliability, some way of informing communicating parties of possible error scenarios is required. As a result, the Internet Control Message Protocol (ICMP)⁷ is used for diagnostic measures in the network. An example of this is the case where a gateway is not reachable - the network stack that recognizes this sends an ICMP “Gateway Unreachable” message back to the origin.

Header Format

The ICMP header resides in the payload of the corresponding IP packet. The structure of the ICMPv4 header is as follows:

struct icmp_v4 {
    uint8_t type;
    uint8_t code;
    uint16_t csum;
    uint8_t data[];
} __attribute__((packed));

Here, the type field communicates the purpose of the message. 42 different⁸ values are reserved for the type field, but only about 8 are commonly used. In our implementation, the types 0 (Echo Reply), 3 (Destination Unreachable) and 8 (Echo request) are used.

The code field further describes the meaning of the message. For example, when the type is 3 (Destination Unreachable), the code-field implies the reason. A common error is when a packet cannot be routed to a network: the originating host then most likely receives an ICMP message with the type 3 and code 0 (Net Unreachable).

The csum field is the same checksum field as in the IPv4 header, and the same algorithm can be used to calculate it. In ICMPv4 however, the checksum is end-to-end, meaning that also the payload is included when calculating the checksum.

Messages and their processing

The actual ICMP payload consists of query/informational messages and error messages. First, we’ll look at the Echo Request/Reply messages, commonly referred to as “pinging” in networking:

struct icmp_v4_echo {
    uint16_t id;
    uint16_t seq;
    uint8_t data[];
} __attribute__((packed));

The message format is compact. The field id is set by the sending host to determine to which process the echo reply is intended. For example, the process id can be set in to this field.

The field seq is the sequence number of the echo and it is simply a number starting from zero and incremented by one whenever a new echo request is formed. This is used to detect if echo messages disappear or are reordered while in transit.

The data field is optional, but often contains information like the timestamp of the echo. This can then be used to estimate the round-trip time between hosts.

Perhaps the most common ICMPv4 error message, Destination Unreachable, has the following format:

struct icmp_v4_dst_unreachable {
    uint8_t unused;
    uint8_t len;
    uint16_t var;
    uint8_t data[];
} __attribute__((packed));

The first octet is unused. Then, the len field indicates the length of the original datagram, in 4-octet units for IPv4. The value of the 2-octet field var depends on the ICMP code.

Finally, as much as possible of the original IP packet that caused the Destination Unreachable state is placed into the data field.

Testing the implementation

From a shell, we can verify that our userspace networking stack responds to ICMP echo requests:

[saminiir@localhost ~]$ ping -c3 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=0.191 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.200 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.150 ms

--- 10.0.0.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.150/0.180/0.200/0.024 ms

Conclusion

A minimum viable networking stack that handles Ethernet frames, ARP and IP can be created relatively easily. However, the original specifications have been extended with many new ones. In this post, we skimmed over IP features such as options, fragmentation and the header DCN and DS fields.

Furthermore, IPv6 is crucial for the future of the Internet. It is not yet ubiquitous but being a newer protocol than IPv4, it definitely is something that should be implemented in our networking stack.

The source code for this blog post can be found at GitHub.

In the next blog post we will advance to the transport layer (L4) and start implementing the notorious Transmission Control Protocol (TCP). Namely, TCP is a connection-oriented protocol and ensures reliability between both communicating sides. These aspects obviously bring about more complexity, and being an old protocol, TCP has its dark corners.

If you liked this post, you can share it with your followers and follow me on Twitter!

Sources

Let's code a TCP/IP stack, 1: Ethernet & ARP

Sun, 06 Mar 2016 10:00:00 +0000

Writing your own TCP/IP stack may seem like a daunting task. Indeed, TCP has accumulated many specifications over its lifetime of more than thirty years. The core specification, however, is seemingly compact¹ - the important parts being TCP header parsing, the state machine, congestion control and retransmission timeout computation.

The most common layer 2 and layer 3 protocols, Ethernet and IP respectively, pale in comparison to TCP’s complexity. In this blog series, we will implement a minimal userspace TCP/IP stack for Linux.

The purpose of these posts and the resulting software is purely educational - to learn network and system programming at a deeper level.

TUN/TAP devices
Ethernet Frame Format
Ethernet Frame Parsing
Address Resolution Protocol
Address Resolution Algorithm
Conclusion
Sources

TUN/TAP devices

To intercept low-level network traffic from the Linux kernel, we will use a Linux TAP device. In short, a TUN/TAP device is often used by networking userspace applications to manipulate L3/L2 traffic, respectively. A popular example is tunneling, where a packet is wrapped inside the payload of another packet.

The advantage of TUN/TAP devices is that they’re easy to set up in a userspace program and they are already being used in a multitude of programs, such as OpenVPN.

As we want to build the networking stack from the layer 2 up, we need a TAP device. We instantiate it like so:

/*
 * Taken from Kernel Documentation/networking/tuntap.txt
 */
int tun_alloc(char *dev)
{
    struct ifreq ifr;
    int fd, err;

    if( (fd = open("/dev/net/tap", O_RDWR)) < 0 ) {
        print_error("Cannot open TUN/TAP dev");
        exit(1);
    }

    CLEAR(ifr);

    /* Flags: IFF_TUN   - TUN device (no Ethernet headers)
     *        IFF_TAP   - TAP device
     *
     *        IFF_NO_PI - Do not provide packet information
     */
    ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
    if( *dev ) {
        strncpy(ifr.ifr_name, dev, IFNAMSIZ);
    }

    if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
        print_error("ERR: Could not ioctl tun: %s\n", strerror(errno));
        close(fd);
        return err;
    }

    strcpy(dev, ifr.ifr_name);
    return fd;
}

After this, the returned file descriptor fd can be used to read and write data to the virtual device’s ethernet buffer.

The flag IFF_NO_PI is crucial here, otherwise we end up with unnecessary packet information prepended to the Ethernet frame. You can actually take a look at the kernel’s source code of the tun-device driver and verify this yourself.

Ethernet Frame Format

The multitude of different Ethernet networking technologies are the backbone of connecting computers in Local Area Networks (LANs). As with all physical technology, the Ethernet standard has greatly evolved from its first version², published by Digital Equipment Corporation, Intel and Xerox in 1980.

The first version of Ethernet was slow in today’s standards - about 10Mb/s and it utilized half-duplex communication, meaning that you either sent or received data, but not at the same time. This is why a Media Access Control (MAC) protocol had to be incorporated to organize the data flow. Even to this day, Carrier Sense, Multiple Access with Collision Detection (CSMA/CD) is required as the MAC method if running an Ethernet interface in half-duplex mode.

The invention of the 100BASE-T Ethernet standard used twisted-pair wiring to enable full-duplex communication and higher throughput speeds. Additionally, the simultaneous increase in popularity of Ethernet switches made CSMA/CD largely obsolete.

The different Ethernet standards are maintained by the IEEE 802.3³ working group.

Next, we’ll take a look at the Ethernet Frame header. It can be declared as a C struct followingly:

#include <linux/if_ether.h>

struct eth_hdr
{
    unsigned char dmac[6];
    unsigned char smac[6];
    uint16_t ethertype;
    unsigned char payload[];
} __attribute__((packed));

The dmac and smac are pretty self-explanatory fields. They contain the MAC addresses of the communicating parties (destination and source, respectively).

The overloaded field, ethertype, is a 2-octet field, that depending on its value, either indicates the length or the type of the payload. Specifically, if the field’s value is greater or equal to 1536, the field contains the type of the payload (e.g. IPv4, ARP). If the value is less than that, it contains the length of the payload.

After the type field, there is a possibility of several different tags for the Ethernet frame. These tags can be used to describe the Virtual LAN (VLAN) or the Quality of Service (QoS) type of the frame. Ethernet frame tags are excluded from our implementation, so the corresponding field also does not show up in our protocol declaration.

The field payload contains a pointer to the Ethernet frame’s payload. In our case, this will contain an ARP or IPv4 packet. If the payload length is smaller than the minimum required 48 bytes (without tags), pad bytes are appended to the end of the payload to meet the requirement.

We also include the if_ether.h Linux header to provide a mapping between ethertypes and their hexadecimal values.

Lastly, the Ethernet Frame Format also includes the Frame Check Sequence field in the end, which is used with Cyclic Redundancy Check (CRC) to check the integrity of the frame. We will omit the handling of this field in our implementation.

Ethernet Frame Parsing

The attribute packed in a struct’s declaration is an implementation detail - It is used to instruct the GNU C compiler not to optimize the struct memory layout for data alignment with padding bytes⁴. The use of this attribute stems purely out of the way we are “parsing” the protocol buffer, which is just a type cast over the data buffer with the proper protocol struct:

struct eth_hdr *hdr = (struct eth_hdr *) buf;

A portable, albeit slightly more laborious approach, would be to serialize the protocol data manually. This way, the compiler is free to add padding bytes to conform better to different processor’s data alignment requirements.

The overall scenario for parsing and handling incoming Ethernet frames is straightforward:

if (tun_read(buf, BUFLEN) < 0) {
    print_error("ERR: Read from tun_fd: %s\n", strerror(errno));
}

struct eth_hdr *hdr = init_eth_hdr(buf);

handle_frame(&netdev, hdr);

The handle_frame function just looks at the ethertype field of the Ethernet header, and decides its next action based upon the value.

Address Resolution Protocol

The Address Resolution Protocol (ARP) is used for dynamically mapping a 48-bit Ethernet address (MAC address) to a protocol address (e.g. IPv4 address). The key here is that with ARP, multitude of different L3 protocols can be used: Not just IPv4, but other protocols like CHAOS, which declares 16-bit protocol addresses.

The usual case is that you know the IP address of some service in your LAN, but to establish actual communications, also the hardware address (MAC) needs to be known. Hence, ARP is used to broadcast and query the network, asking the owner of the IP address to report its hardware address.

The ARP packet format is relatively straightforward:

struct arp_hdr
{
    uint16_t hwtype;
    uint16_t protype;
    unsigned char hwsize;
    unsigned char prosize;
    uint16_t opcode;
    unsigned char data[];
} __attribute__((packed));

The ARP header (arp_hdr) contains the 2-octet hwtype, which determines the link layer type used. This is Ethernet in our case, and the actual value is 0x0001.

The 2-octet protype field indicates the protocol type. In our case, this is IPv4, which is communicated with the value 0x0800.

The hwsize and prosize fields are both 1-octet in size, and they contain the sizes of the hardware and protocol fields, respectively. In our case, these would be 6 bytes for MAC addresses, and 4 bytes for IP addresses.

The 2-octet field opcode declares the type of the ARP message. It can be ARP request (1), ARP reply (2), RARP request (3) or RARP reply (4).

The data field contains the actual payload of the ARP message, and in our case, this will contain IPv4 specific information:

struct arp_ipv4
{
    unsigned char smac[6];
    uint32_t sip;
    unsigned char dmac[6];
    uint32_t dip;
} __attribute__((packed));

The fields are pretty self explanatory. smac and dmac contain the 6-byte MAC addresses of the sender and receiver, respectively. sip and dip contain the sender’s and receiver’s IP addresses, respectively.

Address Resolution Algorithm

The original specification depicts this simple algorithm for address resolution:

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

Namely, the translation table is used to store the results of ARP, so that hosts can just look up whether they already have the entry in their cache. This avoids spamming the network for redundant ARP requests.

The algorithm is implemented in arp.c.

Finally, the ultimate test for an ARP implementation is to see whether it replies to ARP requests correctly:

[saminiir@localhost lvl-ip]$ arping -I tap0 10.0.0.4
ARPING 10.0.0.4 from 192.168.1.32 tap0
Unicast reply from 10.0.0.4 [00:0C:29:6D:50:25]  3.170ms
Unicast reply from 10.0.0.4 [00:0C:29:6D:50:25]  13.309ms

[saminiir@localhost lvl-ip]$ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.0.4                 ether   00:0c:29:6d:50:25   C                     tap0

The kernel’s networking stack recognized the ARP reply from our custom networking stack, and consequently populated its ARP cache with the entry of our virtual network device. Success!

Conclusion

The minimal implementation of Ethernet Frame handling and ARP is relatively easy and can be done in a few lines of code. On the contrary, the reward-factor is quite high, since you get to populate a Linux host’s ARP cache with your own make-belief Ethernet device!

The source code for the project can be found at GitHub.

In the next post, we’ll continue the implementation with ICMP echo & reply (ping) and IPv4 packet parsing.

If you liked this post, you can share it with your followers and follow me on Twitter!

Kudos to Xiaochen Wang, whose similar implementation proved invaluable for me in getting up to speed with C network programming and protocol handling. I find his source code⁵ easy to understand and some of my design choices were straight-out copied from his implementation.

Sources

OpenVPN puts packets inside your packets

Sat, 20 Feb 2016 07:00:00 +0000

I realized I do not know exactly how OpenVPN does its magic in Linux.

I mean, sure, it encrypts and tunnels the packets to another endpoint, but can you describe the exact steps to achieve this? If not, read on. In fact, read on anyway for good measure.

This is the general idea I had pictured in my mind how OpenVPN works:

Receive packets
Encrypt them
Tunnel them
Send to destination

Several questions arise, though:

How is tunneling achieved in OpenVPN’s case?
What is the mechanism for receiving and sending the packets?
How is encryption and decryption of the data achieved?

Let’s delve deeper into these questions.

Tunneling
Encryption
OpenVPN protocol
TUN/TAP devices
Conclusion
Sources

Tunneling

What is tunneling? According to the magnificent TCP/IP Illustrated¹:

Tunneling, generally speaking, is the idea of carrying lower-layer traffic in higher-layer (or equal-layer) packets. For example, IPv4 can be carried in an IPv4 or IPv6 packet; Ethernet can be carried in a UDP or IPv4 or IPv6 packet, and so on.

In other words, tunneling is achieved by injecting packets into the payload of other packets. Reminds me of a certain meme.

Various protocols for establishing tunnels exist, the prominent ones being Generic Routing Encapsulation (GRE), Microsoft’s Point-to-Point Tunneling Protocol (PPTP) and the Layer 2 Tunneling Protocol (L2TP).

The result is that virtual links between computers in different networks can be set up. An example of this is a company’s private network, which can be reached from the public network via tunneling.

Note, however, that tunneling itself does not guarantee secure communications. Encryption has to be applied to the payload, assuming you’ve succeeded to exchange cryptographic keys securely in an insecure environment.

Encryption

When using tunneling, there’s a high chance that the information you transmit is of delicate nature. Hence, cryptographic measures have to be taken into use to prevent anyone from snooping in on the data.

Since OpenVPN is an userspace application, Transport Layer Security (TLS) is a natural choice for the security protocol². TLS operates in the layers above the networking stack, so implementing it in an application’s scope is easier than more involved lower-level protocols that require specific³ kernel modules. If you’ve ever browsed a site with the protocol HTTPS, then you have used TLS for authentication and encryption.

The basic steps for secure communication are implemented in OpenVPN as follows⁴:

The X509 PKI (public key infrastructure) for session authentication
The TLS protocol for key exchange
The OpenSSL cipher-independent EVP interface for encrypting tunnel data
The HMAC-SHA1 algorithm for authenticating tunnel data

The X509 Public Key Infrastructure is an ITU-T standard which relies on Certificate Authorities (CA) for digital signatures of certificates. Through this, a client communicating to a server can verify that the server is really who it claims to be.

The TLS protocol is the ubiquitous privacy protocol suite used to encrypt, well, pretty much anything dealing with Internet. Namely, TLS is responsible of negotiating a secure communication channel between two parties. This mainly consists of certificate and key exchanges, which can be used to authenticate the other party and subsequently encrypt and decrypt the data.

Key exchange is a fascinating topic as it revolves around the problem of two parties attempting to establish a secure communication channel in an insecure medium. Turns out, the Diffie-Hellman method (DH)⁵ is one such clever approach, where two parties can agree upon a key without revealing that key to outsiders.

Another option is to use RSA⁶ public key cryptography for the key exchange. Whereas DH utilizes finite field arithmetic to achieve secure key exchange, RSA takes advantage of the integer factorization problem. This problem deals with the fact that it is hard to factor the numbers that a semiprime number is a product of.

To abstract upon the routine cryptographic functions, OpenVPN uses the EVP interface⁷ of the OpenSSL library. It provides encryption/decryption, signing/verifying, key derivation, hash functions and message authentication code (MAC) functions.

Lastly, Message Authentication Code (MAC) is an important part of secure communications. It is used to verify message integrity, but also to authenticate the message’s origins.

OpenVPN protocol

The general view of the TLS handshaking is as follows⁸:

        Client                                              Server

   ClientHello                      -------->
                                                               ServerHello
                                                               Certificate*
                                                         ServerKeyExchange*
                                                        CertificateRequest*
                                    <--------              ServerHelloDone
   Certificate*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished                         -------->
                                                        [ChangeCipherSpec]
                                    <--------                     Finished

   GenerateTLSBindingKey                             GenerateTLSBindingKey

   Application Data                 <------->             Application Data

The ClientHello message is pretty self-explanatory. The client is required to send it to the server as its first message. It includes data like the TLS version requested, a randomized struct consisting of the current sender’s UNIX time and a 28-byte securely generated random number, requested cipher suite and requested compression algorithm.

The server responds with a ServerHello, Certificate, CertificateRequest TLS records.

The ServerHello record is very much like the ClientHello message, except it has the responsibility of, among other things, choosing the ciphersuite that satisfies both parties’ requirements. In my OpenVPN test session, TLS_RSA_WITH_AES_256_CBC_SHA was chosen as the ciphersuite. This means that RSA is used for the key exchange.

The Certificate record is required whenever the key exchange method is anything other than Anonymous Diffie-Hellman. This is because both parties have to validate the identity of each other to prevent Man-in-the-Middle attacks. Finally, the certificate record contains the certificates of the server..

The ServerKeyExchange record is only sent when “the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret.”⁸ Thus, when using public-key cryptograpghy, you are unlikely to see this message.

The CertificateRequest record sent by the server is followed by the ServerHelloDone message, which indicates to the client that the server has finished its part of the key exchange.

Next, the client sends a Certificate TLS record to the server, containing the client’s certificate used for authentication.

The ClientKeyExchange message is always sent next by the client. It contains either the RSA-encrypted secret or Diffie-Hellman parameters for establishing a shared secret between the two parties.

The CertificateVerify message is sent by the client if explicit verification of the client’s certificates is needed.

Finally, the Finished message is sent by both parties and it is the first encrypted message. Once both parties receive and validate the message, Application Data starts to flow in the encrypted tunnel between the parties. Before the Finished messages, ChangeCipherSpec message is used to indicate any changes in the cipher specifications.

TUN/TAP devices

The tunneling of data in OpenVPN is achieved through TUN/TAP devices⁹. Simply put, TUN/TAP devices expose the operating system’s network traffic as virtual interfaces. This traffic can then be operated upon by the userspace application that is bound to the TUN/TAP virtual interface.

A TUN device operates on IP packets (layer 3), and a TAP device operates on Ethernet frames (layer 2). The distinction is important, since operating on different networking layers enable different use cases. For example, if one wants Ethernet bridging, OpenVPN has to utilize TAP devices. For simple routing of traffic, TUN devices are a cheaper choice. A handy summary of the differences between bridging and routing is presented here.

With OpenVPN and TUN/TAP devices, the Linux Kernel networking stack is involved and does the heavy-lifting of the traffic. The only purpose of the TUN/TAP device is to allow the user-space application, OpenVPN, to operate on the raw Ethernet frames or IP packets. This is where tunneling and encryption is applied. The Ethernet frame or IP packet is encrypted and wrapped inside another IP packet with appropriate headers for delivery, and vice versa.

The specific source code for how the TUN/TAP device is opened in OpenVPN is in the source file tun.c. It closely reflects the TUN/TAP documentation of the Linux Kernel.

Conclusion

Implementing secure communications is a fascinating matter but not a trivial one. The fundamental problem is that the Internet as we know it, is an unsecure medium. Anyone can snoop in on the data flowing through different networks, so establishing a secure communication channel is tricky.

As a bonus, I found out there’s a module named gremlin in OpenVPN, which can be enabled with the --gremlin flag in debug mode. It will wreak havoc on your VPN tunnels, and is probably used to test OpenVPN. :-)

Sources

Establish your online identity using GnuPG

Sun, 24 Jan 2016 19:00:00 +0000

I have a confession to make.

I do not have an online identity. I have Twitter, Facebook (yeah I know) and this homepage, but still, my online presence is undermined by the fact that I or others cannot verify my identity.

The remedy to this is public-key cryptography¹.

About PGP
Using GPG
Creating the master key
Scenarios
Notes

About PGP

Using GPG², the OpenPGP-compliant³ cryptographic software suite, you are able to prove your identity online and that of others. The principle behind this is called the web of trust⁴, where users of OpenPGP-compatible software sign each others public signatures (keys) after having verified their identity. This is in contrast to X.509⁵, where a Certificate Authority, CA, is the sole party establishing the authenticity of users.

So in a way, PGP adheres more to the open source philosophy of decentralized mode-of-operation. Plus, the story of PGP is pretty bad-ass.

In this tutorial, we’ll refer to the OpenPGP specification as “PGP” and “GPG” as the free software implementation by the GNU Project.

Using GPG

Creating and managing PGP keys is not a straightforward matter. Many approaches exist and if you are a whistleblower, this tutorial probably does not meet your security standards. In fact, if there’s a chance you’ll be captured, tortured, or killed for the information you’ll encrypt, stop reading this tutorial and pray for the best. You are doing it wrong.

For others, I think this tutorial serves as a suitable middle ground for the pragmatic daily usage of PGP.

Creating the master key

Let’s get started creating your first PGP-based identity:

$ gpg2 --version
gpg (GnuPG) 2.1.9
libgcrypt 1.6.4

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
        Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
        Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ gpg2 --full-gen-key

Pay attention to the fact that we’re using GPG v2.1 in this tutorial. The newest version prefers better hash algorithms.

Select the default RSA and RSA for making keys for both signing and encrypting:

Pleasese select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)

Next you will be asked to input the size for the RSA keys. We’ll use 4096 bits for the master key, since it is only meant for signing other keys. The subkeys we’ll use are used for encryption and decryption, so they are better off with a 2048 bit key size⁶.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits

Set an expiration time for your master key, in case you lose your revokation certificate and the master key is compromised. The downside is that you have to keep extending the lifetime of the key. The expiration time can be altered afterwards, even if a key has expired.

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Input your real name and email. Do not, however, input a comment when prompted:

GnuPG needs to construct a user ID to identify your key.

Real name: Sami Niiranen
Email address: saminiir@gmail.com
Comment:
You selected this USER-ID:
    "Sami Niiranen <saminiir@gmail.com>"

Next up, you have to come up with a passphrase for your master key. The Intercept has an insighftul article on the problems of passphrases and how to create robust ones (with Diceware).

After some dice rolling and as you have entered the passphrase, the master key will be generated. This master key IS your electronic identity, so the point is to handle it with care. Especially the private master key we’ll evacuate to a safe place later on in this tutorial.

Key management

The case is often that one has multiple computers (desktop, laptop) and wants to use the same GPG identity on all devices. One popular scheme for this is creating subkeys, which are then distributed. There are, however, some differing opinions⁷⁸ on this approach and whether it is a sane model for the web of trust.

The alternative is to create master keypairs for every device and sign them with your ultra-secure master-master keypair.

In this tutorial, the approach of creating subkeys is chosen, mostly because it seems to be the more popular⁹ choice and has the advantage of accumulating trust for your single PGP identity.

Creating a revocation certificate

GnuPG version 2.1 automatically generates a revocation certificate. It will be located under $GNUPGHOME/openpgp-revocs.d/. If you’re using an older version, be sure to generate one.

Store this revocation certificate in a safe place. The revocation certificate is short enough to be handily stored on paper.

Creating subkeys

Subkeys are your day-to-day keys for signing and encryption. Hence, we’ll generate a subkey to the very computer you are now at.

$ gpg2 --list-keys $yourid
$ gpg2 --edit-key $yourid
$ gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
Your selection? 4

Choose the RSA (sign only) option for generating a signing key only. Use the default 2048-bit keysize if you have no reason to use a larger one. Choose an expiration date. Input a passphrase.

Repeat the procedure, but this time, create a RSA (encrypt only) key.

As a final step, trust and save the keys you’ve made:

gpg> trust
gpg> save

After these operations, your keyring should look similar to this:

$ gpg2 -k
/home/saminiir/.gnupg/pubring.kbx
---------------------------------
pub   rsa4096/XXXXXXXX 2016-01-24 [expires: 2016-07-22]
uid         [ultimate] Sami Niiranen <saminiir@gmail.com>
sub   rsa4096/XXXXXXXX 2016-01-24 [expires: 2016-07-22]
sub   rsa2048/XXXXXXXX 2016-01-24 [expires: 2016-07-22]
sub   rsa2048/XXXXXXXX 2016-01-24 [expires: 2016-07-22]

Evacuating the master key to safety

Now you should have a master keypair and a signing/encryption sub-keypair for your personal computer. It is imperative, that the master keypair is now evacuated to safety.

There are endless possibilities how to store your master keypair, from paper printouts in a safe, to armed guards in your basement. Because I haven’t yet obtained any interesting information to whistleblow, I chose the mundane approach of backing up the master keypair to a USB drive:

$ gpg2 --export-secret-keys --armor $keyid > privkey
$ gpg2 --export --armor $keyid > pubkey
$ gpg2 --export-secret-subkeys $keyid > subkeys
$ gpg2 --delete-secret-key $keyid
$ gpg2 --delete-key $keyid
$ gpg2 --import subkeys
$ shred subkeys

Alternatively, with gpg2, you can delete keys without needing to twiddle with exporting and importing:

# Get the keygrip of the key to be deleted
$ gpg2 -K --with-keygrip
$ rm .gnupg/private-keys-v1.d/$keygrip.key
# Make sure the older gpg format, secring.gpg, is empty and does not contain the key
$ ls -l .gnupg/secring.gpg

You can verify that the master secret key should not be in the keyring by detecting sec# when listing the secret keys.

Now, be sure to evacuate your master keypair privkey and pubkey with your chosen method to a safe location. I’m storing it in an encrypted USB drive. The short gist of that is as follows:

$ lsblk
$ mount /dev/sdb /mnt/usb
$ dd if=/dev/zero of=/mnt/usb/disk.img bs=1M count=16
$ loopdev=$(losetup -f)
$ losetup $loopdev /mnt/usb/disk.img
$ cryptsetup -v luksFormat $loopdev
$ cryptsetup isLuks $loopdev && echo "Success"
$ cryptsetup open $loopdev usbkey
$ mkfs.ext3 /dev/mapper/usbkey
$ mount /dev/mapper/usbkey /media/encrypted
$ cp -r ~/.gnupg /media/encrypted/
$ gpg2 --homedir /media/encrypted/.gnupg -K
$ fuser -km /media/encrypted
$ umount /media/encrypted
$ cryptsetup remove usbkey
$ losetup -d $loopdev
$ umount /mnt/usb

You can automatize the mounting of the encrypted filesystem.

Sending the public key to a key server

Next, you’ll want your public key to be actually obtainable for other people. Keyservers are a good fit for this, since the gpg tool can be used to query them for other people’s public keys.

For enhanced security, obtain the CA cert for the keyserver:

$ wget https://sks-keyservers.net/sks-keyservers.netCA.pem

Set the following as your keyserver configuration in $GNUGPHOME/dirmngr.conf.

keyserver hkps://hkps.pool.sks-keyservers.net
hkp-cacert /path/to/CA/sks-keyservers.netCA.pem

Send your public key to the keyserver pool. Afterwards you and anybody else can find your PGP identity.

$ gpgconf --reload
$ gpg2 --send-key $keyid

And you’re done setting up your GPG configuration! The following section depicts use cases and how to solve them.

Scenarios

Importing the primary secret key

Since you need the primary secret key for many operations, like signing new keys, it needs to be imported from the safe storage medium back to your keychain:

$ mount /dev/sdb /mnt/usb
$ losetup --find --show /mnt/usb/disk.img
/dev/loop0
$ cryptsetup open /dev/loop0 usb
$ mount /dev/mapper/usb /media/encrypted

Replace the devices file descriptors with the correct ones.

Then, import the primary secret key:

$ gpg2 --homedir /media/encrypted/.gnupg --export-secret-keys --armor $KEYID > privkey
$ gpg2 --import privkey

After finishing with key manipulation, delete the private key from the keychain:

# Get the keygrip of the key to be deleted
$ gpg2 -K --with-keygrip
$ rm .gnupg/private-keys-v1.d/$keygrip.key
# Make sure the older gpg format, secring.gpg, is empty and does not contain the key
$ ls -l .gnupg/secring.gpg

New subkey

Create a new subkey. You’ll need your master keypair that is stashed away to certify the new subkey.

Signing keys

Again, you need the master secret key for this operation.

Obtain, sign and export somebody’s key:

$ gpg2 --search-keys $email #Choose the public key to import
$ gpg2 --fingerprint $email #Check the fingerprint
$ gpg2 --sign-key $email
$ gpg2 --armor --export $keyid > signedkey
$ gpg2 --sign --encrypt --recipient $email signedkey

And mail the resulting .gpg file to the person.

Extending the lifetime of a key

The point of setting an expiration date for all of your keys is to have them actually expire if you lose access to the master keys or the revokation key. Besides, checking your keys at least once per year can is a good practice that probably enhances your security.

Just set the expiration date through the gpg interface:

$ gpg2 --edit-key saminiir@gmail.com
gpg> expire

Again, you need your master keypair for this operation to succeed.

Revoking the master key

To revoke your key, simply import the revocation certificate and update keyservers:

# Read the cert, you need to modify it to prevent accidental revokement 
$ vim .gnupg/openpgp-revocs.d/revcert.rev
$ gpg2 --import revcert.rev
$ gpg2 --send $keyid

Do not delete revoked keys. They are still useful to decrypt data previously encrypted with the old key.

Revoking a subkey

To revoke a subkey, revoke it from gpg’s interface:

$ gpg2 --edit-key saminiir@gmail.com
gpg> list
gpg> key 2
gpg> revkey

Again, do not delete revoked keys. They are still useful to decrypt data previously encrypted with the old key.

Distributing an encryption subkey

For distributed usage, a subkey can be created for each usage purpose.

For example, to encrypt and decrypt your password manager files both in your phone and laptop, transfer the generated encryption subkey to the phone like so:

# generate a strong random password
$ gpg2 --armor --gen-random 1 20
$ gpg2 --armor --export-secret-keys $SUBKEY_ID | gpg2 --armor --symmetric --output encsubkey.sec.asc

After that, transfer the encsubkey.sec.asc via a secure mechanism, e.g. a flash storage, to the new device.

Never transfer private keys through the internet, and strive for isolated environments where the transfer is done.

Synchronizing the keyring between computers

Synchronizing a GPG keyring between computers may be desired to propagate information about imported key IDs¹⁰.

On whichever computer, export the keyring and put it on the encrypted USB drive:

$ gpg --export-secret-keys > my-secret-keyring.gpg
$ gpg --export-options export-local-sigs --export > my-public-keyring.gpg

Now, on the other computer, import (merge) the keyring:

$ gpg --import my-secret-keyring.gpg
$ gpg --import-options import-local-sigs --import my-public-keyring.gpg

Repeat this process the other way around, if needed.

If you liked this post, you can share it with your followers and follow me on Twitter!

saminiir's hacker blog

Paper storage and recovery of GPG keys

Contents

Dependencies

Exporting the key

Backing up the key

Recovering the key

Conclusion

Sources

Let's code a TCP/IP stack, 5: TCP Retransmission

Contents

Automatic Repeat Request

TCP Retransmission

Karn’s Algorithm

Managing the RTO timer

Requesting retransmission

Trying it out

Conclusion

Sources

Let's code a TCP/IP stack, 4: TCP Data Flow & Socket API

Contents

Transmission Control Block

TCP Data Communication

TCP Connection Termination

Socket API

Testing our Socket API

Conclusion

Sources

Configuring Arch Linux on Dell XPS 15

Contents

User management

Arch User Repository

X11 and Window Manager: dwm

Terminal: xterm

Input: Trackpad gestures (libinput)

Sound

Storage: NVMe SSD

Graphics: Nvidia and Bumblebee

Power Management

Powertop

Battery status

Backlight

Laptop mode

Suspend/hibernate

Debugging suspend/hibernation

Locking screen on sleep

Networking: netctl, Unbound

Security

Browser: Firefox

Backups: rsnapshot

Password Management: pass

Gaming: Steam/Wine

Gamepad

iPhone

Sources

Installing Arch Linux on Dell XPS 15

Contents

Booting up Arch Linux

Partitioning: UEFI, GPT and ESP

Disk encryption: LUKS

Volume management: LVM

Install Arch Linux

Boot manager: systemd-boot

Sources

Let's code a TCP/IP stack, 3: TCP Basics & Handshake

Contents

Reliability mechanisms

TCP Basics

TCP Header Format

TCP Handshake

TCP Options

Testing the TCP Handshake

Conclusion

Sources

Let's code a TCP/IP stack, 2: IPv4 & ICMPv4

Contents

Internet Protocol version 4

Header Format

Internet Checksum

Internet Control Message Protocol version 4