SSEECCLLOOGG AA SSeeccuurree RReemmoottee LLooggiinn FFrroonntteenndd aanndd SShheellll1 _L_a_w_r_e_n_c_e _B_r_o_w_n Department of Computer Science University College, UNSW, Australian Defence Force Academy Canberra ACT 2600. Australia. AAbbssttrraacctt This paper discusses the development of sseecclloogg, a frontend for rrllooggiinn, and an associated shell for use on the remote system. These provide a secure remote terminal facility, using an auto- mated challenge/response login procedure, session key exchange, and encryption of all data exchanged for the subsequent ses- sion. The encryption algorithm may be chosen from DES, LOKI, or a stream cipher; depending on the security/speed tradeoff desired. Initially sseecclloogg has been implemented using BSD pseudo-ttys. The reasons for their choice, advantages, and lim- itations, are discussed. A future version, to be incorporated into tteellnneett and tteellnneettdd, rather than a shell around rrllooggiinn, is then proposed. 11.. IInnttrroodduuccttiioonn With the growth of wide area networks linking together existing local area networks, there are increasing security problems with the existing network utilities traditionally supplied for such LANs. These utilities have assumed that the LAN was a secure communications service (even though it was recognised fairly early that it was not necessarily so), and that hence there was no need to provide additional security services for these utilities. However a wide-area internet certainly cannot be assumed to be secure2. Thus there is a desire to provide utilities with additional security. Some of the issues involved in providing such security are canvassed in [WoK85 pp 189-198], [HeR89] and [DaP89]. This paper examines the remote terminal service provided by rlogin or telnet for TCP/IP systems. It considers the security implications of such services, and then describes an initial implementation of a utility to provide additional security for rlogin. ____________________ 1 Presented to AUUG Summer 90 (Victoria) Monash University, Victoria, Australia 6th February 1990 2 for a fascinating account of the 1986 Internet breakin, see [Sto88], and for details on other breakins see [Rei87], [Spa88]. AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn 22.. LLooggiinn OOvveerr aa NNeettwwoorrkk -- SSoommee IIssssuueess 22..11.. IIddeennttiittyy ooff tthhee UUsseerr When a user logs in to a host computer, they provide a username and password to identify themselves to the computer. On a hard- wired line this is assumed to be secure, as it is difficult for someone to tap such a line and intercept the username password pair. However when logging in over a network, anyone with access to a workstation and packet monitoring software could intercept the pair, and then subsequently claim to be the orig- inal user (see Fig 1). In either case it is assumed that the password is well chosen, so that it cannot be guessed [MoT79], [Spa88 Appendix A]. What is required is that the information sent over the network not be sufficient to allow an intruder to impersonate the user, without additional knowledge. There are a number of ways of doing this. _ Fig 1 - Identity of User Uncertain CChhaalllleennggee -- RReessppoonnssee This involves the host computer sending a random number, a cchhaalllleennggee vector, to the user. The user encrypts this using a pprriivvaattee key, known to both the remote host and themselves, and sends this encrypted vector, the rreessppoonnssee, back to the host. The host encrypts the cchhaalllleennggee vector using the user's pprriivvaattee key, and compares it with the rreessppoonnssee returned. The user is accepted only if they are identical. Since any intruder monitoring the network will see a different challenge and response each time, they will not be able to pro- duce a correct response, unless they have obtained the user's key by some other means (which is a separate problem). This technique assumes that the user and remote host have already arranged a private key prior to wanting to establish a remote login session. Since, in this application, a user must have negotiated with the remote site to obtain a usercode and con- ventional password, obtaining a network private key simply becomes another piece of information exchanged during this negotiation. Thus in this case, I believe it is not a problem. -- 22 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn DDiiggiittaall SSiiggnnaattuurree This method uses a public-key authentication scheme [SeP89] to identify the user. To use it, the user signs an identity mes- sage with the private half of the key and sends this to the remote host. There it is verified by using the public half of the key to confirm that the identity message is unchanged. Since only the user knows the private half of the key, only they could have signed the identity message. There is still a problem however, of obtaining the correct public half of the key. If it is obtained from some remote database, that message could be faked instead to be that of the intruder. The problem is solved by providing the public key signed by a public key centre (or possibly a hierarchy of signed keys), whose public key is well known. This can be supplied by the user as part of the identity message which removes the need for a network key server to be accessed on every remote terminal session request. Whilst this method has a number of nice properties, including no need for prior key exchange, it is computationally slow. However if a public key scheme is to be used for encryption, then this would be the obvious counterpart. ZZeerroo KKnnoowwlleeddggee PPrrooooff ooff IIddeennttiittyy This technique provides a way of authenticating a user, by using a series of challenges and responses to convince the remote site that the user is who they say they are. However it does not require the prior arrangement of a key. In this method, the user sends a certificate (Ident,j) originally obtained from a public key centre, to the remote host. The host then interacts with user to prove ownership of the cer- tificate [FFS88], [SeP89]. This method is much faster than a digital signature, though it involves a dialog between the user and the host. In the longer term, it will probably be the method of choice. 22..22.. PPrriivvaaccyy ooff SSeessssiioonn Having authenticated the user, the next issue to address is the provision of privacy for the user (see Fig 2). Fig 2 - Privacy of Session -- 33 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn This implies a need to encrypt the data transferred during the session. However, a choice has to be made as to which form of cipher is to be used to provide privacy. A Public-Key scheme has the nice property that the keys need not be exchanged prior to establishing a session, but current implementations are too slow. The alternative is to use a private-key scheme. These are considerably faster, but need the keys to have been exchanged in some secure fashion, either prior to the session, or via a public key exchange scheme. If a cchhaalllleennggee--rreessppoonnssee scheme is being used, then a suitable key may be derived, for example, by encrypting the rreessppoonnssee vveeccttoorr to form the session key. Having decided to use a private key scheme, there is still a range of ciphers to chose from, trading off speed for security. The choices include: SSiimmppllee SSuubbssttiittuuttiioonn CCiipphheerr This is very fast, very simple to implement, but is very inse- cure. Guessing as many characters as there are in the key is sufficient to crack the scheme. However, if all that is required is to defeat casual scanning (or an automatic word scanner), then it may well suffice. SSttrreeaamm CCiipphheerr This is usually based on a pseudo-random number generator. They are reasonably fast, and given a suitable choice of generator (such as a non-linear feedback shift register, or multiplexed linear feedback shift registers), these schemes have a moderate to high level of security. They can be cracked by guessing a sufficiently large number of characters, but the number needed could be very large. Another possible precaution is to change keys before this number of characters is sent (using for exam- ple the challenge-response key again, and encrypting the previ- ous session key again every period). BBlloocckk CCiipphheerr The cipher would be used in a stream mode. Any of the modern block ciphers may be used, eg DES [ASA85], LOKI [BPS90], FEAL8 [ShM88] [Miy90]. These schemes all have a very high level of security, but are probably the slowest of the alternatives. Suitable modes include either Cipher Feedback (CFB), or Output Feedback (OFB) modes (see Fig 3). If the CFB mode is chosen, it uses the message contents in forming the new key (which can slow down parallel key stream generation), but which leads to different key streams for different messages. If the OFB mode is used, the key stream generated is independent of the message content (and thus the key stream can be precomputed). However OFB should not be used to encipher a number of different mes- sages with the same keystream, as this creates a security hole. If different keys are used though, it is equivalent in security to CFB, with the advantage of being able to precompute the key if desired. -- 44 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn _ Fig 3 - Stream Modes for Block Ciphers 33.. WWhheerree ttoo AAdddd SSeeccuurriittyy?? Since there are a number of existing protocols for remote ter- minal sessions, eg rlogin or telnet, it would be preferable to adapt these to provide the security features detailed earlier, rather than write a new protocol. The issue is how to adapt these existing tools. There are two major options, as shown in Fig 4. _ Fig 4 - Adding a Security Utility ((AA)) IInntteeggrraatteedd iinnttoo tthhee UUttiilliittiieess Here, the programs are modified to include the required secu- rity features. It has the advantage of being able to properly merge the extensions with the existing protocols. However, access is required to the source to achieve this on all systems where it is required. In the longer term, it is the option of choice. ((BB)) UUssiinngg AAddddoonn PPrroocceesssseess Here, some filters are added, in traditional Unix fashion, around the existing utilities. This is much easier to do, since there are no changes to the existing tools, but there are sev- eral disadvantages. It adds more processes and thus context -- 55 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn switches, it blocks user interaction with the client program using escapes, and it requires a transparent (8-bit) path. Nonetheless, this was the option chosen for the initial imple- mentation. 44.. SSEECCLLOOGG -- AA SSeeccuurree RReemmoottee LLooggiinn IImmpplleemmeennttaattiioonn 44..11.. OOvveerrvviieeww SECLOG is an initial implementation of some utilities to pro- vide a basic secure login service. Structurally, it uses extra processes around rlogin (option B). Rlogin rather than telnet, was chosen as the basic remote terminal service because it pro- vides a transparent (8-bit) mode (using the undocumented -8 flag). This made implementation a little easier. I intend to modify it to handle telnet in the near future, though this may involve sending every encrypted character as two hex charac- ters, doubling the size of each message. SECLOG performs the following operations: automatic login to a secure userid challenge/response to verify user negotiates encryption cipher to use perform encryption of session data It does not need to run as a a privileged (setuid) program, though it does require a small privileged utility to cleanup utmp/wtmp and reset the terminal permissions. It assumes that a network key (here it is an 8-char DES key) has been arranged previously (ie when the usercode is created). The SECLOG processes are structured as shown in Fig 5. The client program sseecclloogg is run by the user to establish a secure remote terminal session. It then runs rlogin, which establishes a link to rlogind on the remote host. The sseecclloogg client then logs into the secure user on the remote system, which in turns runs the sseecclloogg server. These then negotiate the chal- lenge/response and cipher to use, and if successful, the server runs login to actually login the user and start their shell. For the remainder of the session, the client and server encrypt all information being transferred between them. -- 66 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn _ Fig 5 - SECLOG Processes In more detail, the flow of control between the client and server, detailing the sequence of messages exchanged, is shown in Fig 6: +-----------------------------+----------------------------------+ |Client | Server | +-----------------------------+----------------------------------+ | | | |initialize | | |grab pty pair | | |fork & exec "rlogin" via pty | | |lookup user key | | |do remote login to "secure" | (rlogind execs server) | | | initialize | | | grab pty pair | | | issue challenge | |get challenge | lookup user key | |calc & send response | get & check response | | | prompt for scramble alg | |accept suitable scramble alg | & init accepted alg | | & init selected alg | fork & exec "login user" via pty | | | prompt scramble start | |accept scramble start | | |copy & cipher session data | copy & cipher session data | | | | +----------------------------------------------------------------+ | Fig 6 - SECLOG Control Flow | +----------------------------------------------------------------+ 44..22.. SSEECCLLOOGG -- PPrriivvaattee KKeeyy FFiillee As mentioned previously, keys must be arranged prior to estab- lishing a secure remote login. It is assumed that these keys will be distributed at the time the account is created, along with the conventional password. The SECLOG keys are stored in a file rrkkeeyyss, which must NOT be readable by anyone other than by the sseecclloogg server and the -- 77 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn system administrator. This can be arranged by making a special group to which this file belongs, and for which the systems administrator is a member. The SECLOG server program should then be setgid to this group. The format of the rrkkeeyyss file is as shown in Fig 7 below: # format for rkeys file for seclog # login_name des_key_in_hex lpb 0123456789abcdef bvd 6789abcdef012345 gco 456789abcdef0123 Fig 7 - rrkkeeyyss file format 44..33.. TTyyppiiccaall SSeessssiioonn SSccrriipptt A script for a typical secure remote login session, showing the interaction between the client and server is shown in Fig 8 (nb: italic text is entered by the user, bold text is returned from the remote system, plain text is from the local system). -- 88 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn +-------------------------------------------------------+-----------------------+ |Script | Comments | +-------------------------------------------------------+-----------------------+ | | | |cssun2_11 %_s_e_c_l_o_g _c_s_s_u_n_0 | run program | |seclog started, remote host cssun0, user lpb | | |seclog got slave /dev/ttyp2 on file id 4 | | |PPaasssswwoorrdd::sstteellnneett | rlogin "secure" | |LLaasstt llooggiinn:: WWeedd JJaann 2244 1155::5555::2288 ffrroomm ccssssuunn22..ccss..aaddffaa..oo | | |SSeeccuurree llooggiinn::llppbb | name user | |CChhaalllleennggee:: 55885588558855882255bbdd3355aaee | does challenge | |RReessppoonnssee::1111dd44eeffdd77dd55555544ee8833 | gets response | |SSccrraammbbllee MMooddee:: DDEESS :: yy | negotiate cipher | |RReemmoottee UUsseerr VVaalliiddaatteedd | | |SSccrraammbbllee SSttaarrtt:: | start scrambling data | |PPaasssswwoorrdd:: _m_y_p_a_s_s_w_o_r_d | conventional login | |LLaasstt llooggiinn:: WWeedd JJaann 2244 1155::5555::4433 oonn ttttyypp11 | nb all info scrambled | |tteennoowwaattcchh:: MMaaxxiimmuumm ccoonnttiinnuuoouuss wwoorrkk ppeerriioodd 6600 mmiinnuutteess | | | wwoorrkk :: rreesstt rraattiioo 11::11 | | |TTeerrmmiinnaall ttyyppee iiss vvtt110000 oonn ttttyypp11 | | |ccssssuunn00__1111 %%_w_h_o | show who is on | |sseeccuurree ttttyypp00 JJaann 2244 1155::5577 ((ccssssuunn22..ccss..aaddffaa..oo)) | seclogd user | |llppbb ttttyypp11 JJaann 2244 1155::5577 | real user | |wwkkuu ttttyypp77 JJaann 2244 1144::1100 ((ccssaaddffaa..ccss..aaddffaa..oo)) | someone else | |ccssssuunn00__1122 %%_l_o_g_o_u_t | request logout | |Connection closed. | | |seclog done | seclog client exits | |cssun2_12 % | | +-------------------------------------------------------------------------------+ | Fig 8 - Typical SECLOG Session Script | +-------------------------------------------------------------------------------+ 44..44.. SSEECCLLOOGG -- PPrroobblleemmss OObbsseerrvveedd Whilst writing and debugging sseecclloogg, a number of problems were found, including: +o The handling of prompts and replies during login. It was very easy to get out of sync between the client and server during the automated login. In particular, care is needed in the ordering of patterns matched (eg "Login" matched both the wanted "Login:" prompt, but also the "Last Login at ..." banner). +o Sync of encrypted data during session. This was a major problem. Apart from ensuring that the cipher algorithms themselves stay in sync, a more serious problem was the use of stderr by programs inside the encrypted data path, especially messages from rrllooggiinn and the sseecclloogg server. This was partly handled by bypassing rlogin's stderr round the client, but error messages from sseeccllooggdd or rrllooggiinndd had to be very carefully avoided, or suitable ciphered. +o Clearing out of utmp/wtmp entries, and resetting the ter- minal permissions for logged in users. Traditionally this -- 99 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn is handled by one of rrllooggiinndd, tteellnneettdd, or iinniitt. However, in the arrangement used here we have the following: tty1: "secure" utmp created by rlogind, utmp cleared by rlogind tty2: "user" utmp created by login, utmp cleared by ??? This required writing a small setuid root program "fix- utmp". This takes as an argument a tty device, and it clears the associated utmp and wtmp entries for it, and resets it permissions. It uses the standard Berkeley rou- tines (as used in rlogind) for doing this. Obviously this program should not be available to normal users. It should also belong to the special group used to protect the rkeys file. 55.. FFuuttuurree VVeerrssiioonnss Having gained some experience with SECLOG as it is, I have some indicators for how it is to evolve in future. Most importantly, in a major rewrite, it should be integrated into the telnet and telnetd programs. This will bypass many of the problems found in the current implementation, due to the much closer merging of the features with the existing protocols. Despite requiring source access, I feel this is a needed improvement to the cur- rent scheme. If this is done, I would like to get the security extensions approved, especially for the initial challenge/response and cipher negotiation protocol exchanges. This will greatly improve the chance of getting an agreed means of implementing these extensions. Other option improvements include the use of a streams module for encryption of the session data, rather than having it buried in the telnet code; the use of a zero knowledge proof of identity rather than challenge/response; and public key exchange of session the key. These latter two are probably less important in this particular application, than in say elec- tronic mail, because of the need to have established an account on the remote host prior to establishing communications with it. It is likely that a private key cipher will continue to be used for privacy, since a massive speed improvement of the public key schemes appears unlikely. 66.. CCoonncclluussiioonnss In this paper I have detailed a trial of a secure remote login program. It provides authentication of the user and privacy of the session. It does require the use of prearranged keys, and suffers from fairly high additional resource usage due to its structure. Nonetheless it has shown that the problem can be solved, and has pointed to a future version which should over- come some of these problems. -- 1100 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn AAcckknnoowwlleeddggeemmeennttss To Mike and Cathy Newberry, Andrzej Goscinski, Chris Vance and Geoff Collins, for their help and suggestions. Thankyou. This work is supported in part by ARC grant A48830241. BBiibblliiooggrraapphhyy [ASA85] ASA, "_E_l_e_c_t_r_o_n_i_c_s _F_u_n_d_s _T_r_a_n_s_f_e_r _- _R_e_q_u_i_r_e_m_e_n_t_s _f_o_r _I_n_t_e_r_f_a_c_e_s_, _P_a_r_t _5_, _D_a_t_a _E_n_c_r_y_p_t_i_o_n _A_l_g_o_r_i_t_h_m," AS2805.5-1985, Standards Association of Australia, Sydney, Australia, 1985. [BPS90] L. Brown, J. Pieprzyk and J. Seberry, "LOKI - A Cryptographic Primitive for Authentication and Secrecy Applications," in _A_d_v_a_n_c_e_s _i_n _C_r_y_p_t_o_l_o_g_y_: _A_u_s_c_r_y_p_t _'_9_0, Lecture Notes in Computer Science, no. 453, pp. 229-236, |Springer Verlag|, Berlin, 1990. [DaP89] D. W. Davies and W. L. Price, _S_e_c_u_r_i_t_y _f_o_r _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, John Wiley and Sons, New York, 1989. (2nd edn). [FFS88] U. Feige, A. Fiat and A. Shamir, "Zero-knowledge proofs of identity," _J_o_u_r_n_a_l _o_f _C_r_y_p_t_o_l_o_g_y, vol. 1, no. 2, pp. 77-94, |Springer Verlag|, 1988. [HeR89] M. Henning and A. Rohde, _U_N_I_X _F_i_l_e _S_y_s_t_e_m _S_e_c_u_r_i_t_y, CCSR Tutorial Series in Computer Security, no. 1, Centre for Computer Security Research, Dept Computer Science, UC ADFA, Canberra, ACT, Australia, 1989. [Miy90] S. Miyaguchi, "The FEAL-8 cryptosystem and a call for attack," in _A_d_v_a_n_c_e_s _i_n _C_r_y_p_t_o_l_o_g_y _- _C_R_Y_P_T_O_'_8_9, Lecture Notes in Computer Science, no. 435, G. Brassard (editor), pp. 624-627, |Springer Verlag|, Berlin, 1990. [MoT79] R. Morris and K. Thompson, "Password Security: A Case History," _|_C_o_m_m_. _o_f _t_h_e _A_C_M_|, vol. 22, no. 11, pp. 594-597, |November.| 1979. [Rei87] B. Reid, "Reflections on Some Recent Widespread Computer Break-Ins," _|_C_o_m_m_. _o_f _t_h_e _A_C_M_|, vol. 30, no. 2, pp. 103-105, |February.| 1987. [SeP89] J. Seberry and J. Pieprzyk, _C_r_y_p_t_o_g_r_a_p_h_y_: _A_n _I_n_t_r_o_d_u_c_t_i_o_n _t_o _C_o_m_p_u_t_e_r _S_e_c_u_r_i_t_y, |Prentice Hall, Englewood Cliffs, NJ|, 1989. [ShM88] A. Shimizu and S. Miyaguchi, "Fast Data Encipherment Algorithm FEAL," _E_u_r_o_c_r_y_p_t _8_7 _A_b_s_t_r_a_c_t_s , pp. 11-14, 1988. [Spa88] E. H. Spafford, "_T_h_e _I_n_t_e_r_n_e_t _W_o_r_m _P_r_o_g_r_a_m_: _A_n _A_n_a_l_y_s_i_s," Technical Report Computer Science -- 1111 -- AAUUUUGG SSuummmmeerr 9900 ((VViiccttoorriiaa)) SSEECCLLOOGG LLaawwrreennccee BBrroowwnn Dpt.-Tech. Rep.-823, |Dpt.| Computer Sciences, Purdue University, West Lafayette, IN 47907-2004, USA, 8 |December.| 1988. [Sto88] C. Stoll, "Stalking the Wily Hacker," _|_C_o_m_m_. _o_f _t_h_e _A_C_M_|, vol. 31, no. 5, pp. 484-497, |May| 1988. [WoK85] P. H. Wood and S. G. Kochan, _U_N_I_X _S_y_s_t_e_m _S_e_c_u_r_i_t_y, Hayden Book Company, 1985. -- 1122 --