One may now proceed through the architectural options of a real-life example, designing an embedded security communications solution for a wireless device. We reveal the thought process in the architect s mind and play the traditional devil s advocate to show how he or she continually questions choices until the appropriate trade-offs have been settled and compromises are resolved. As this is not an engineering project management book, organizational detail is intentionally omitted. This is, as the chapter s title states, how one optimizes the solution.

Let s assume we want to secure wireless handsets and further assume that we want our design to be

• End-to-end secure for voice and data

• Operable at real-time speeds

• Tamper-proof and not easily susceptible to hacking

• Based on acceptable and robust cryptographic methods

Among several modules needed, the heart of this solution is a cryptographic engine. Encryption using DES or 3DES level of security, for example, is attractive for our example s architect.

The first decision to be made is whether to implement in software or hardware. If in software, DES requires a certain level of instructions to be executed per second. More specifically, a typical implementation of DES in Java will yield 1,656 32-bit instruction words when compiled onto a Pentium. Depending on the throughput and clock speed of the processor and assuming one instruction per clock cycle (not always the case), one can deduce what percentage of the processor s capacity is devoted to real-time encryption. Doubling roughly for decryption, one...