Copyrights, patents and warrantiesSECT contains copyrighted software!
The design of SECT - the Secure Terminal - is Copyright ©
Ralf Senderek 2000. All rights reserved. These rights include but are not limited to any foreign language translation of this documentation or the copyrighted software, and all derivative works of both. All other parts of SECT which are not signed by the author - LINUX and SSH - are subject to their authors copyrights, patents and regulations respectively and it is entirely to the user's duty to comply with any legal implication of this software. The author explicitly grants licence to anyone for non-commercial use of SECT. But to ensure the reliablity of the author's copyrighted software, changing the code and redistributing changed code is not permitted under any circumstances. The author assumes no liability for damages resulting from the use of this software, even if the damage results from defects in this software, and makes no representations concerning the merchantability of this software or its suitability for any specific purpose. It is provided "as is" without expressed or implied warranty of any kind. Because of the fact that certain actions may delete files or render them unrecoverable, the author assumes no responsibility for the loss or modification of any data. |
The main purpose of SECT which has determined its design is to provide a platform for establishing a secure contact to a remote computer system, using strong cryptography and therefore allows you to work on the remote and reliable system using a totally insecure network to establish the connection. The remote computer system must be a reliable system which offers you the environment you need. SECT's job entirely is to secure your access to your reliable system, so that you can be safe from the threatening riscs of the compromitation of your secret information you are entering at your keyboard or which you create while you are processing your email and documents.
After having checked the signature of the file SECT.dd.pgp you can build your initial SECT-disk from the file SECT.dd using UNIX or DOS.
UNIXPut a formatted 3½'' floppy into the first drive and use the following command:
dd if=SECT.dd of=/dev/fd0 bs=1k |
DOSYou can use dd.exe, a shareware programm made by Helmut Schellong. See the documentation.Put a formatted 3½'' floppy into the first drive and use the following command:
dd if=SECT.dd of=fd0:c80h2s18 bs=1k |
Your LINUX-kernel will then load the filesystem into the RAMDISK which starts at block 470 currently ending at block 1431 stored in compressed format. This is followed by reading the default configuration from the disk which provides the basic information of your network access and some information for running the Secure Shell.
For obvious reasons I cannot know which IP-number you would like your SECT to have. I have set up the following defaults:
RELIABLEHOST=192.168.1.1
LOCALIP=192.168.1.111
NET=192.168.1.0
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
GATEWAYIP=192.168.1.1
OWNHOSTKEY=no
RSE=no
STRICT=yes
CIPHER=idea
Your SECT is currently set up to work in a local class C network
192.168.1.0 ready to connect to a reliable system with IP 192.168.1.1
on the local network.
It is essential to collect some information about your local network which you are planning to use your Secure Terminal on, because SECT is designed to permit connections to a single system only, which is reachable over the local network even if this reliable host is located on a different local network. In this case the connection has to be routed through a gateway which basically is a system that exchanges packets of information between different physical networks, and its IP number must be known to SECT as well. So this information is only necessary if your reliable host is not connected to the same local network you are using. Please ask the administrator of your reliable host about the IP of your destination and the administrator of your local network about your local network address you can use and how to get through to your reliable system. While talking to your system's administrator you should ask for the public ssh_host_key of your reliable system which is a piece of information you will need to make sure you are in fact connected to the correct system when using the encrypted connection.
Your filesystem is stored on the disk. If you had a password for "root", it would be stored on the disk as well, usually in a file called "/etc/shadow". But that would never prevent someone from extracting the filesystem and removing the root-password if you accidentially leave the disk in the drive. Your secret-key you have to use to establish the secure connection to your reliable host will be stored on the disk, too, and cannot be protected by using a root-password. So protecting your SSH-secret-key with a very good passphrase and strong cryptography, is the reliable way to prevent somebody else to log into the remote system masquerading you. A root-password can add nothing to this security.
You are looking for reliable security, and therefore SECT contains a program ckeckSECT that computes MD5-fingerprints of security relevant data. The program checkSECT is to be used at any time to make sure you are currently running a system nobody could have tampered with. checkSECT will prompt you for an individual challenge, a few (or more) characters that will be used to form a piece of information together with the kernel being read from the disk and most of the filesystem except the directories /dev, /proc and /var which will be changing constantly. It will now compute the md5-fingerprint of your challenge to show you that it works correctly and will then compute the md5-fingerprint of the collected piece of information including your challenge using the current md5sum binary in your filesystem through standard input.
All you have to do is to write down both fingerprints and keep them save after you have initially built your SECT-disk from checked sources and after having configured your SECT-disk and having saved your individual RSA-keys for the use of the Secure Shell.
If you have these fingerprints at hand you can check at any time if your current system is in exactly the same condition (including kernel, filesystem and your keys) as you initially had prepared it for use. But be aware that the fingerprint of the challenged kernel and filesystem will change if you change anything related to the filesystem, i.e. your keys or your file "known_hosts" while using SSH. checkSECT will detect this reliably.
If you have got your secure fingerprints at hand you can check SECT's integrity even if you have left your running system for lunch or any other urgent need without logging out and leaving your disk in the drive. checkSECT will produce the fingerprints you have only if nothing has been changed in the meantime.
The output of checkSECT will totally depend on your challenge and will look like this:
The dash following the fingerprints indicates, that both your challenge and the collected piece of information has entered into the md5 binary the same way through standard input. You should also cross-check the fingerprint of your challenge on other independent reliable systems.Checking SECT's integrity ... Are you sure the SECT-disk is in the drive ? [yes/] : yes Please enter your individual challenge: Your individual challenge : 83e71d83b2dcea23dcab3b64182494cc - Challenged kernel and filesystem : 3a5f7731f7c077b5e1b22e07601d56b4 -
That leads to another important question: Is it insecure to have a system on a net which boots from disk?
This question will take us to the core of the problem. Some network administrators might think that you should not be allowed to boot your own operating system for security reasons. But this is only proof of the fact that there is no reliable security in this network far and wide. If there were other systems on the net which are reliably secure, - and I hope there will be, thanks to their professional administration - they would take measures to prevent possible attacks launched from other systems and they surely would take the fact into account that there are some systems on the net misbehaving. If there is a policy that no system on the local network should be booting from disk and you are forced to use the running systems, with nobody knowing the condition they are in, I would like to advise you to do two things. Firstly to respect this policy and secondly to regard this network as deliberately insecure and to look for a different way to get access to your trusted system.
Booting your own reliable system is the way you can be sure that your secret information will not be compromised. Preventing you from booting your trusted system basically means to turn you over to risks you cannot calculate which sometimes may be justified but far too often is not.
When booting next time, SECT will read the new configuration, store it in a file "/root/config.running", and will execute a program config.run to make this configuration work. If you like to change the configuration of a running system without booting, you can create a new configuration with mkconfig which automatically will update routing and firewall information on the running system.
The configuration "/root/config.running" can contain the following entries:
But if you start from scratch, you can login as user "sect" and use the program ssh-keygen to generate a new pair of keys. It will generate a pair of keys with 1024 bits of size and store it in the proper place "/SECT/.ssh" if you execute it after logging in as "sect".
The output should look like this:
The directory "/SECT/.ssh" should then contain three files "identity", "identity.pub", and "random_seed" all owned by "sect". After having created your pair of keys, you should execute the program savekeys as "root". This will save the new keys on the disk and you can check the integrity of SECT with checkSECT to see which fingerprint your new keys will produce. You should write this information down, and save all your files in "/SECT/.ssh" on a different backup-disk using the following commands as "root":Initializing random number generator... Generating p: .................................++ (distance 444) Generating q: ..............................................++ (distance 572) Computing the keys... Testing the keys... Key generation complete. Enter file in which to save the key (/SECT/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /SECT/.ssh/identity. Your public key is: 1024 37 140667731747005229581165059711649539908241723220367233087847558595 13393308162176910748814648564781543116425218479140416904023840655952133774 46484406980441946749024446900800515871692245434101936614122208973802236635 14295489653209846939812791534310007473426021383349187880388547850399982092 227076473215732003903 sect@sect Your public key has been saved in /SECT/.ssh/identity.pub
tar -uvpf /dev/fd0 /SECT/.sshor
mount /dev/fd0 /mnt
cp /SECT/.ssh/* /mnt
umount /mnt
Note, that the reliable system is mentioned with its IP number at the beginning of the line.192.168.1.1 1024 33 1114799213307491690209197309313801762897893365266968 453296394831883949174338774704114856079633616421820374505165883643145705 100934668310546551159248036548501494083403857097242318267182291568732098 801725154432123132269206945597249164285244998290732102904351981072957915 68121798830193571146970061196277326714453
If your reliable system's administrator has given the host-key to you, you can edit the file and copy it to filesystem as "/SECT/.ssh/known_hosts". You can then execute savekeys again which saves all files in "/SECT/.ssh" to your SECT-disk, to make this information permanently available. The fingerprint of your keys will then change.
If you don't have first-hand information about your reliable system's host-key, you can create a file "/SECT/.ssh/known_hosts" using the following work-around. But be careful, you are reducing reliable security, until you have checked the host-key with first-hand information. If you have any access to your reliable host, you can check the host-key without asking your administrator, because normally it is stored in a file "/etc/ssh_host_key.pub" which is readable for everyone.
Work-around :
|
CIPHER=3des will change the cipher to TRIPLE-DES, a cipher using keys of 112-bit lenght. Although DES is not secure, TRIPLE-DES may be the only cipher your reliable system will offer you. In this case you can reduce reliable security using 3des as cipher.
Any other entry will lead to the use of IDEA.
sect LOGINNAME
Your input, which will then be transferred to the reliable system will be
encrypted using IDEA or TRIPLE-DES respectively.
All those algorithms use long encryption-keys (RSA: 1024 bit asymmetric,
IDEA: 128 bit symmetric and 3DES: 112 bit symmetric) to ensure reliable
security.
The security of your system
The integrity of your running system can be checked at any time with
checkSECT which will produce md5-fingerprints of the
kernel, the filesystem (except the variable parts), and your keys
which are part of the filesystem using an individual challenge to
prevent a modification of the system to remain undetected.
If someone was able to modify the filesystem (md5sum or ssh) the forged
md5sum binary would not produce the correct fingerprints, because it
would have to behave correctly regardless of the input, as your challenge
is not known to the forger.
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ram2 3963 2432 1531 61% /
After having loaded your keys, you can safely remove the SECT-disk, so that
no storage medium will be present in the system.
There is also no device used for swapping, so that no part of the
memory can be found elsewhere. So your passphrase, which unlocks your
secret-key, will not be stored anywhere except the main memory of the system.
As a matter of fact there are no daemons running in the background
which provide services to the net and there is not even a sshd running
on SECT. That will ensure that your system has minimal connectivity,
just sufficient to open a secure connection to one single system out there.
Credits
The Secure Terminal (SECT) uses :
All rights are reserved to the authors of this famous software and everyone
who has contributed. I am glad that I could find such a professional
basis for the design of SECT. I thank you all very much.
Files
Copyright ©
Ralf Senderek 2000