Advertisement

Planning Your Embedded Secure Shell (SSH) Implementation

James Blaisdell and Monique Semp

August 19, 2008

James Blaisdell and Monique SempAugust 19, 2008

One of the more ubiquitous communications protocols, Secure Shell (SSH) enables secure logins and command execution over unsecured networks and between untrusted hosts.

It is also used for tunneling and port forwarding over secure channels, as well as for Secure FTP file operations. But how do you actually integrate SSH into embedded and mobile devices? This article explains how to approach the task, and provides answers to your SSH configuration questions.

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

But integrating security into an embedded or mobile device requires understanding a variety of protocols, communication mechanisms, and your devices' operating environments. So ask yourself, which of these security 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 secure embedded devices. Fortunately, many security vendors and independent nonprofits provide plenty of information and can work with you to properly integrate security into your products.

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

* Expert: If you eat big integers for breakfast, you're an expert! You appreciate security, and could (theoretically) code your own security features. But it is quite a task, and you should carefully consider whether it's worth the time and resources to implement a custom security approach. After all, even the largest device 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, it serves as a requirements checklist. For newbies, it provides general guidance as to what a potential security partner should ask when determining 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 to determining the specific SSH requirements necessary for your implementation.

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

A closer observation, however, reveals that there is in fact "no such thing as a free lunch," especially when it comes to implementing security in non-PC environments. Common downsides to using open source security code in device production environments include:

* Porting considerations - Open source security products were designed for desktop systems. To adapt them to embedded devices requires costly development time for non-trivial platform ports, performance optimizations, and footprint reductions.

* Security concerns - Open source security code has a history of routine and significant security flaws, and of non-adherence to standards which causes interoperability issues.

* Support issues - Lack of documentation, samples, support, and maintenance for open source means developers are on their own and must invest significant time to integrate security code, all the while raising the risk of introducing security holes into their applications.

* Code quality - The quality of open source code varies considerably from project to project, and even among modules in a given code base. Testers cannot take anything for granted, and will spend considerable effort on platform testing and integration efforts.

* Certification and legal issues - Open source security code has a history of difficulty getting and keeping FIPS validations, as well as leaving manufacturers with considerable legal exposure due to unresolved or simply ambiguous issues of patent protection, IP indemnification, licensing, and (unknown) country of origin.

To address these limitations, many security vendors have developed commercial SSH implementations that offer valuable benefits for embedded and mobile devices: high performance, small footprint, assembly optimizations, and ongoing development, maintenance, and support.

In the interest of full disclosure, yes, the authors work for Mocana, a vendor that sells SSH implementations. But the truth is, that although open source libraries appear to be free, when the cost of extra development, maintenance, legal liabilities, and so on are included, it's usually cheaper and faster to license a commercially supported SSH implementation than to build your own from OpenSSH.

Synchronous vs. Asynchronous: What Do Your RTOS and Command Line 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 may block and disrupt other applications. Asynchronous models are single-threaded or threadless, event-driven, and use non-blocking system calls or upcalls. Which model you should use is influenced by both your RTOS and the type of CLI shell you're using.

< Previous
Page 1 of 3
Next >

Loading comments...