cipe.texinfo

cipe 编程

@end example

This is all of the minimum configuration. Note that no @code{me} and
@code{peer} options are necessary. These are determined by
@command{pkcipe}. It does not matter which side runs @code{pkcipe} in
server and which one in client mode.

In server mode, @code{pkcipe} has to be started via @code{inetd}. This
requires the following steps:
@cindex inetd
@enumerate
@item
Choose a port. (This is arbitrary, here I use 963.) Enter this port into
@file{/etc/services} on @emph{both} machines, giving it a name:
@example
pkcipe       963/tcp
@end example
@item
Enter the parameters into @file{/etc/inetd.conf}:
@example
pkcipe stream tcp nowait root /usr/local/sbin/pkcipe pkcipe
@end example
or if using TCP Wrapper for access control:
@example
pkcipe stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/pkcipe
@end example
Restart @code{inetd} after any change.
@end enumerate

The other end then initiates the connection simply via
@example
pkcipe -c @var{server.machine}:pkcipe
@end example
It is possible to run this connection through NAT (masquerading) or via
SOCKS using a dynamic SOCKS library (@code{socksify}/@code{runsocks}
script). In the latter case it may be necessary to repeat the peer
address in a @code{-r @var{server.machine}} argument.
@cindex PKCIPE, over SOCKS

@page
@node  Connection modes,  , Example 2, Examples
@section        Connection modes

Here is in detail how it is possible to build CIPE links between
different classes of carriers. Those classes are, based on how they are
able to reach the carrier network (usually the Internet):

@enumerate
@item @c 1
Direct connection on a static IP address.
@item @c 2
Direct connection on a dynamic IP address.
@cindex dynamic addresses
@item @c 3
Indirect connection through a SOCKS server.
@cindex SOCKS
@item @c 4
Indirect connection through a NAT (masquerading) router.
@cindex NAT
@cindex masquerading
@end enumerate

This produces ten different combinations:

@table @samp
@item 1-1
Can be configured statically like in the simple example. Or any end may
run a PKCIPE server and let the other end connect.

@item 1-2
The @samp{1} end can run a PKCIPE server and let the @samp{2} end
connect. @code{pkcipe} gets the right IP addresses at both ends, later
changes are handled automatically. @footnote{It is also possible, but
less convenient, to configure this statically: The carrier address of
the @samp{2} end should be the special dummy @code{127.0.0.1:9}, and the
@code{ip-up} script in @samp{2} should have the @code{ping} statement as
in the sample. See also @samp{1-3}.}
@cindex Dynamic DNS

@item 1-3
Like @samp{1-2}, with a @code{ping} in @code{ip-up} at the @samp{3} end.
The @samp{3} end does not know its effective (as seen by the other end)
carrier address, so the PKCIPE exchange produces a wrong @code{peer}
parameter at the @samp{1} end. The @code{ping} corrects that by sending
packets with the right address. @footnote{Static configuration like
@samp{1-2} is also possible.}

@item 1-4
Like @samp{1-3}.

@item 2-2
One end runs a PKCIPE server and publishes its current IP address using
some external service (like a web server or dynamic DNS
@footnote{Dynamic DNS is easiest to handle because it does not need any
external scripts or special software for CIPE, only the dynamic DNS
client. There are some services which provide dynamic DNS free of
charge.}). The other end fetches this address to connect to and proceeds
like in @samp{1-2}.

@item 2-3
Like @samp{1-3}, except that the @samp{2} end uses an external service
to publish its current address.

@item 2-4
Like @samp{1-4}, except that the @samp{2} end uses an external service
to publish its current address.

@item 3-3
This is not easily possible with the current code because neither end
knows its effective carrier address (i.e. the SOCKS UDP relayer address)
before the link is set up, and so neither side can send packets to the
other. This information is available in the @code{ip-up} script, but
transmitting it to the other end would need some means outside of CIPE.
It is planned that future versions will be able to handle this via
extended capabilities of PKCIPE; this will also require an external
service like dynamic DNS with a special setup.

@item 3-4
Like @samp{3-3}.

@item 4-4
Not possible. Neither side gets to know its effective carrier address at all.
@end table

@xref{Dynamic carrier}, for a more detailed explanation of some of these
configurations.

@c --------------------------------------------------------------------------

@node  Protocol descriptions, Misc, Examples, Top
@chapter        Protocol descriptions

@menu
* The CIPE Protocol::   Encrypted IP encapsulation used by CIPE.
* The PKCIPE Protocol::  Public-key based setup and key exchange.
@end menu

@node The CIPE Protocol, The PKCIPE Protocol, Protocol descriptions, Protocol descriptions
@section        The CIPE protocol

@cartouche
@display
This chapter is copied verbatim from the earlier documentation texts.
@end display
@end cartouche

The primary goal of this software is to provide a facility for secure
(against eavesdropping, including traffic analsyis, and faked message
injection) subnetwork interconnection across an insecure packet
network such as the Internet.

1. Overview

This protocol was designed to be simple and efficient, and to work
over existing communication facilities, especially by encapsulation in
UDP packets. Compatibility with existing protocols such as the IPSEC
RFCs were not a concern. The first test implementation was done
entirely on the user level, while the now published one consists of a
kernel module and a user level program.
@cindex IPSEC

The CIPE model assumes a fixed link between two peers which exchange
datagrams (packetwise, not necessarily reliable). The most common way
of implementing such a thing is sending UDP messages between them.
(Another would be encapsulation in PPP, etc.)

Nothing that can be parameterized is inside the scope of this protocol
and implementation. This is delegated to either prior arrangement or a
yet-to-be-defined application level protocol. Most notably, this
involves exchanging a shared secret key by now, and it involves choice
of encryption algorithm.

The CIPE protocol consists of two parts: Encryption and checksumming
of the data packets and dynamic key exchange.

2. Packet encryption
@cindex Packet encryption

Each IP datagram is taken as a whole, including headers. It is padded
at the end with zero to seven random octets so that the total length
in octets is congruent three modulo eight. The padded packet is
appended with one octet of the value P described below and the CRC-32
over the packet built up so far, up to and including P. (This makes
the complete packet length a multiple of eight octets.)

This packet is then encrypted through a 64-bit block cipher in CBC
mode with an IV as described below using either the static or the
sending dynamic key of the outbound interface (for definition of keys
see below). The default cipher algorithm is IDEA. The current
implementation also supports Blowfish with 128 bit key.
@cindex IDEA
@cindex Blowfish

The encrypted packet is prepended with the IV block. The highest order
bit of the first octet of the IV is zero if the static key is used,
one if the dynamic key is used. The remaining 63 bits are random, but
the first 31 of them should not be all zeros (i.e. an IV/packet that
starts with hex 0000 0000 or 8000 0000 is not allowed). Such packets
are reserved for later protocol extensions.

The CRC is over the polynomial
@example
@noindent
X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0
@end example
and represented in network byte order.
@cindex CRC

The value P is given as follows: bits 6,5,4 indicate the length of the
padding between the original packet end and P. Bits 2,1 are a type
code, indicating which kind of packet this is. The remaining bits
7,3,0 are reserved and must be zero.

The type codes are:
00 - data
01 - key exchange
10 - reserved
11 - reserved

For decryption, first check the highest bit of the first octet and use
it to select the key. Decrypt the packet, calculate the CRC over the
packet minus the last four octets, compare that with the last four
octets. If valid, strip off the last octet as value P, strip off the
padding as given by bits 6,5,4 of P and process the packet as
indicated by bits 2,1 of P.

3. Key exchange
@cindex Key exchange

Every interface is associated with a static key, a sending dynamic key
and a receiving dynamic key. (An interface is an endpoint of a
connection, which may use protocols like UDP for transport but for the
purpose of CIPE are always point-to-point links.) On startup, only the
static key is valid. Encryption uses the static key if and only if the
sending dynamic key is invalid. The value 0 (all bits zero) for the
static key is reserved for future extensions and should not be used.

The dynamic key is set by a dialogue procedure involving messages with
type code bits 01. These are encrypted just like above. The packets
consist of a type octet followed by protocol data followed by a random
amount of padding random data, so that the packet is at least 64 octets
long. A key consists of 16 octets, a key CRC is the CRC-32 over the
key, transferred in network order.

The following messages exist:

NK_REQ: Type code 1, no data: Requests the peer to immediately start a
key negotiation (send NK_IND). This should be sent when a packet is
received encrypted with a dynamic key but no dynamic receive key is
valid. (Which can happen when the receiving side of a connection is
rebooted while the sending side remains running.)

NK_IND: Type code 2, data is new key followed by key CRC. Specifies a
new sending dynamic key for this sender. Requests the peer to
immediately answer with NK_ACK.

NK_ACK: Type code 3, data is CRC of the previously accepted key.
Confirms receipt of NK_IND.

The key negotiation procedure normally runs as follows: The sender
sends a NK_IND with the new key, then invalidates its own sending key.
Upon receipt of NK_IND, the receiver starts using this key as its
receiving key and sends a NK_ACK. When the sender receives NK_ACK, it
starts using the new key as its sending key. If either of NK_IND or
NK_ACK is lost in transmission, no new key will be used. The sender
should send a new NK_IND (with new key) if no matching NK_ACK is
received within a reasonable amount of time (current specification: 10
seconds).

If any of the checksums contained in the key negotiation data
mismatches the contained or stored key, this packet is ignored and no
further action taken.

A sending dynamic key should be invalidated after being used for a
certain period of time or amount of data and a new NK_IND sent. The
process is symmetric and both sides act independently for their own
sending key. The dynamic key lifetime should not exceed 15 minutes and
the amount of data sent using one dynamic key should not exceed 2^32
packets.

Optionally, the key exchange packets can be timestamped. The timestamp
is a 32bit unsigned integer in network order representing the UNIX time
of the sending host, placed in octets 56-59 (starting at zero) of the
key exchange packets. The receiver may be configured to ignore the
timestamp, or it may be configured to reject all key exchange packets
whose timestamp differs from the current UNIX time of the receiving host
by more than a defined amount. It is recommended that this timeout not
exceeds 30 seconds.

4. Security considerations

The packets that actually get transmitted don't carry any usable
information related to the original IP datagram other than its length,
padded to a multiple of 8. This should effectively guard against most
aspects of traffic analysis. The only information visible prior
(attempt) to decrypting the packet is the bit that tells whether the
static or dynamic key was used. Because the static key has a
potentially long lifetime it is expected to be used as rarely as
possible. It is normally used only in the short period of time during
a key exchange. The dynamic key is changed often. These precautions
are there because the application is prone to known and chosen
plaintext attacks and the intention is to inhibit feeding of large
amounts of data through one key.

Because the type code and padding length are encrypted with the
packet, they can not be deduced from the ciphertext. Especially, it is
not possible to determine whether the packet is a data or key exchange
packet. (Usually, the last packet