Planning Your Embedded Secure Shell (SSH) Implementation -

Planning Your Embedded Secure Shell (SSH) Implementation


One of the more ubiquitous communications protocols, Secure Shell (SSH) enablessecure logins and command execution over unsecured networks and betweenuntrusted hosts.

It is also used for tunneling and port forwarding over securechannels, as well as for Secure FTP file operations. But how do youactually integrate SSH into embedded and mobile devices? This articleexplains how to approach the task, and provides answers to your SSHconfiguration questions.

How Much Do You Really Know About(SSH) Security?
If you're reading this article, you certainly know much more than theaverage PC user, who may not be convinced that the inconvenience ofrunning security software is even “worth it”.

But integrating security into an embedded or mobile device requiresunderstanding a variety of protocols, communication mechanisms, andyour devices' operating environments. So ask yourself, which of thesesecurity types are you?

* Newbie: Do key pairs, session keys, ciphers, and hashes make your head spin?You're not alone; most developers do not know how to properly secureembedded devices. Fortunately, many security vendors and independentnonprofits provide plenty of information and can work with you toproperly integrate security into your products.

* Intermediate: Do you know something about security protocols and understand how yourdevice communicates? If so, you're in good shape to evaluate possiblesolutions and integrate SSH into your embedded or mobile device.

* Expert: Ifyou eat big integers for breakfast, you're an expert! You appreciatesecurity, and could (theoretically )code your own security features. But it is quite a task, and you shouldcarefully consider whether it's worth the time and resources toimplement a custom security approach. After all, even the largestdevice manufacturers usually rely on external vendors to ensure robust,full-featured security for their products.

Regardless of your answer, this article is for you. For experts, itserves as a requirements checklist. For newbies, it provides generalguidance as to what a potential security partner should ask whendetermining your security requirements.

And if, like the majority of device and application developers,you're in-between, this article provides a step-by-step approach todetermining the specific SSH requirements necessary for yourimplementation.

How Much Time Can You Devote ToSecurity?
The biggest decision to make when choosing an SSH implementation iswhether to use open source code or a product from a commercial securityvendor. Open source projects are popular, offer loads of optionaluser-written add-on modules, and best of all, they're free!

A closer observation, however, reveals that there is in fact “nosuch thing as a free lunch,” especially when it comes to implementingsecurity in non-PC environments. Common downsides to using open sourcesecurity code in device production environments include:

* Portingconsiderations – Open source security products were designed fordesktop systems. To adapt them to embedded devices requires costlydevelopment time for non-trivial platform ports, performanceoptimizations, and footprint reductions.

* Securityconcerns – Open source security code has a history of routineand significant security flaws, and of non-adherence to standards whichcauses interoperability issues.

* Support issues – Lack of documentation, samples, support, and maintenance for opensource means developers are on their own and must invest significanttime to integrate security code, all the while raising the risk ofintroducing security holes into their applications.

* Code quality – The quality of open source code varies considerably from project toproject, and even among modules in a given code base. Testers cannottake anything for granted, and will spend considerable effort onplatform testing and integration efforts.

* Certificationand legal issues – Open source security code has a history ofdifficulty getting and keeping FIPS validations, as well as leavingmanufacturers with considerable legal exposure due to unresolved orsimply ambiguous issues of patent protection, IP indemnification,licensing, and (unknown) country of origin.

To address these limitations, many security vendors have developedcommercial SSH implementations that offer valuable benefits forembedded and mobile devices: high performance, small footprint,assembly optimizations, and ongoing development, maintenance, andsupport.

In the interest of full disclosure, yes, the authors work forMocana, a vendor that sells SSH implementations. But the truth is, thatalthough open source libraries appear to be free, when the cost ofextra development, maintenance, legal liabilities, and so on areincluded, it's usually cheaper and faster to license a commerciallysupported SSH implementation than to build your own from OpenSSH.

Synchronous vs.Asynchronous: What Do Your RTOS and CommandLine Interface (CLI) Shells Require?There are two primary program models used in embedded systems:synchronous and asynchronous.

The synchronous model is essentially pipes and threads, which mayblock and disrupt other applications. Asynchronous models aresingle-threaded or threadless, event-driven, and use non-blockingsystem calls or upcalls. Which model you should use is influenced byboth your RTOS and the type of CLI shell you're using.

Your Device's RTOS
The primary determinant for choosing between synchronous andasynchronous SSH communications is what sort of RTOS (if any) isrunning on your embedded or mobile device:

* None .If your embedded or mobile device is running without any RTOS at all,there are no threads or pipes, Therefore, use asynchronous SSH.

* Simple/loop .Likewise, if you are using a simple or loop RTOS, where blockingoperations are undesirable, use asynchronous SSH.

* Full-featured. If you are using a full-featured RTOS (such as Linux or VxWorks), youcan use either synchronous or asynchronous SSH communications. Todecide which is more appropriate, you need to move on to the nextsection: “Your CLI Shell.”

Additionally, asynchronous SSH message handling is required if anyof the following conditions apply:

1) Your system isevent-driven or callback-based
2) Your existing TCP/IP stackis TCB-based, or you use a similar asynchronous stack
3) Multiple user sessions perthread are required
4) Thread shortages areexpected (or not unlikely)
5) Threadless operation isrequired

Your CLI Shell. Embedded and mobile devices that use a full-featuredRTOS can operate with synchronous or asynchronous SSH. In this case,consider what type of CLI shell you're using:

* Separatethreads for send and receive – Asynchronous SSH is required.
* Stream-based -Synchronous SSH is much simpler to integrate into devices thanasynchronous SSH.
* Packet-driven – Asynchronous SSH is required.

More About SynchronousCommunications Mechanisms
If you're using synchronous SSH, you'll need to be sure that your SSHsolution provides all the communications mechanisms you may need:

* Productfunctions.  There is no standard interface to SSHsolutions. Some provide code that you have to port directly into yourcode base before you can call the SSH functions; others provide simple,documented API functions. Determine which methods will work in yourdevelopment environment, and be sure that your chosen SSH solutionsupports your choice.

* Sockets.  SSH functions that are socket-like generally incur the lightest systemload. Depending on your operating system, such functions use far fewerthreads than a custom socket or pipe solution.

* Pipes. If your application contains many send and receive function calls, isrelatively unstructured, or is difficult to modify, SSH integration isoften easier if you treat the application as a black box and implementSSH as a proxy using pipes to communication with your application.

Although pipes increase the system load, and can only be used forintra-process communication, they are necessary if you are using any ofthe following:

1) Generic debug shell (suchas the VxWorks debug shell)
2) Directed output to stdin,stdout, and stderr
3) Binary shell (such asTelnet)
4) Receive mechanisms sincefull-featured SSH solutions will provide two ways to receive messages:streamed (enabling receipt and buffering of partial messages) orreceipt of messages in their entirety.

Handling Encryption/Authenticationon Underpowered Processors
When you choose an SSH client and/or server, you should make sure thatit supports all your required optimizations, cipher suites, andauthentication methods. But how do you choose which ones you need?

SSH configuration options offer a plethora of strength vs. speedtradeoffs, so absent external interface requirements, the mostimportant determinants are your device's processor speed and thethroughput required by your application.

AssemblyLanguage Optimization. For smaller processors,assembly language optimizations of cryptographic operations is usuallynecessary. If you're using an open source security solution, which ishighly likely to have been written for a PC platform, you'll need tooptimize the code when you port it to your device.

If you're using commercial SSH products, you can choose a solutionthat already includes the necessary optimizations for your embedded OS.Mocana hasfreesource codethat isoptimized for over 100 different OS/CPU combinations..

Cipher Algorithms
When you choose an SSH client and/or server, you should make sure thatit supports all the cipher algorithms you need. The following factorsshould be considered:

1) Maximumcompatibility – Ideally you'd want your device to be able tocommunicate with any and every network and device that implements anyflavor of SSH.

At a minimum, you should be sure to include AES (AdvancedEncryption Standard, alsoknown as Rijndael) and3DES.Next, be sure to include ciphers typically used by your targetindustry. For example, the electronic payments industry uses 2TDESextensively.

2) Speed – Ciphers vary greatly in speed. However, if you simply choose thefastest, you're unlikely to end up with as secure a system as yourequire.

For example, ARCFOUR is one of thefastest ciphers, but due to its weak key scheduling algorithm andnon-random initial bytes of keystream output, is considered weak andvulnerable to attack. For some key sizes, AES is faster than 3DES, but3DES is generally considered stronger. Blowfish is also a popularchoice for its speed and strength.

3) Cipherstrength – If encryption strength is your greatest concern, besure your SSH implementation supports Triple-DES (3DES). However, beaware that you'll incur the usual tradeoff for strength: 3DES is slowerthan many other ciphers.

4) Key size – If you're integrating SSH into an application environment that haspredetermined or predefined key sizes, you need to choose a cipher thatoffers the appropriate key size support.

Rijndael offers the greatest number of key sizes (128 to 256 bits,in 32-bit increments), closely followed by AES (128, 192, and 256bits). ARCFOUR use 128-bit keys. 3DES uses 192-bit keys. Blowfish has avariable key length from 0 to 448 bits, with 128 an often used choice.

In short, you should choose an SSH product that supports a varietyof cipher algorithms so that your devices have maximum communicationability. Table 1 below liststhe recommended ciphers that you should ensure you support, along withtheir pros and cons.

Table1 DSA vs. RSA Authentication

SSH supports both DSA and RSA signatures for host authentication, sowhich one should you use? RSA is significantly faster than DSA,typically by a factor of three.

However, RSA support is optional per the SSH protocol definition, sonot every target device and network supports RSA. Therefore, determineif the target of your communication supports RSA, and if so, use RSAand be sure that your SSH solution supports it.

SSHAuthentication Considerations. When you choose your SSHimplementation, it's important to determine how you will authenticateusers and to ensure maximum flexibility with respect to futureauthentication requirements.

Public Key vs. PasswordAuthentication
SSH supports both public-key and password client authentication, sowhich should you use? Although public keys and passwords are bothtransmitted over a secure channel, it's better to use public keys toeliminate the problems inherent in password-based systems (that is,systems that rely on user names and passwords for accessauthorization). Why? Three reasons:

1) Authorized user namesand password are frequently obtained from the users themselves becauseusers often record their passwords (so they are not forgotten) or evendeliberately share them with someone else. Because private keys arestored electronically and handled by client applications (not users),users are very unlikely to share those private keys.

2) User names and passwords(often sent in clear text over the wire) are all that is needed toaccess password-based systems. Public keys function along with privatekeys, which are not sent over the wire.

3) Many passwords arechosen to be easy to remember, or limited to only eight (or even fewer)characters, leaving them vulnerable to dictionary attacks. Acertificate's cryptographic keys are random in nature and are hundredsor even thousands of bits long, making them invulnerable to dictionaryattacks.

Certificate Authentication Support
Growing numbers of systems are forsaking transmission of public keysand passwords for authentication, and are using certificates instead.Although the certificates themselves contain the same public keys thatcould be sent directly, using certificates is more secure because:

1) The system verifies thatthe user certificate was issued by a trusted CA (certificate authority ).
2) No local database of userpublic keys is required on the server.
3) User access can be deniedsimply by revoking the user's certificate (via OnlineCertificate Status Protocol or Certificate Revocation Lists ).

So for maximum flexibility, and to “future-proof” your devices, youshould choose an SSH solution that incorporates certificate support.

Putting It All Together
As we've shown, whether you're building it from the ground up or usinga “shake 'n bake” solution,you can integrate SSH into your embedded and mobile devices.

By following the process outlined in this article, you can decide ona general approach, as well as make informed technical decisions aboutcommunications modes, encryption ciphers, and authentication methods.

James Blaisdell is chief technicalofficer at Mocana Corporation. Hehas more than 15 years experience working in embedded systems. He wascofounder and CTO of RapidLogic, acquired by WindRiver Systems.Previously he worked as Principal Engineer at Kenamea, leading theirhandheld software development efforts. He may be reached

Monique Semp is a Principal atWrite Quick, Inc. She has a BS in EE from VA Tech. Before focusing hercareer on technical writing, she was a software engineer in thetransportation and automation industries. She may be reached

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.