Shahzad Bhatti Welcome to my ramblings and rants!

Articles Checkout a great articles about:
Slimp3 Streams Your MP3s for Free

Integrating Struts, Tiles, and JavaServer Faces

 Apache Beehive - http://incubator.apache.org/beehive/
 SDO - http://www-106.ibm.com/developerworks/library/j-sdo/
 DOM4J - http://www.dom4j.org/
 Spring - http://www.springframework.org/
 Cocoon - http://xml.apache.org/cocoon/index.html
 Spring - http://www.springframework.org/
 Cocoon - http://xml.apache.org/cocoon/index.html
 WebApp Framework - http://webapp.de/en/
 Arch4J - http://arch4j.sourceforge.net/
 JSF - http://java.sun.com/j2ee/javaserverfaces/index.jsp
 Struts - http://struts.apache.org/
 Tapestry - http://sourceforge.net/projects/tapestry
 WebWork - http://www.opensymphony.com/webwork
 Echo - http://www.nextapp.com/products/echo
 Expresso - http://www.jcorporate.com/html/products/expresso.html
 Jade - http://sourceforge.net/projects/salmon
 JOT Servlets Framework - http://www.jotobjects.com/
 JUnit - http://www.junit.org/index.htm
 Castor - http://www.castor.org/
 Hibernate - http://www.hibernate.org/
 OJB - http://db.apache.org/ojb/
 JDO - http://java.sun.com/products/jdo/
 O/R Broker - http://orbroker.sourceforge.net/
 Cayenne - http://objectstyle.org/cayenne/
 O/R Broker - http://orbroker.sourceforge.net/
 Cayenne - http://objectstyle.org/cayenne/
 Jena - http://jena.sourceforge.net/
 Framework for Java Database Connectivity -
 http://www.alphaworks.ibm.com/tech/framework4jdbc
 Grid Application Framework for Java -
 http://www.alphaworks.ibm.com/tech/GAF4J
 Java 2 Collections -
 http://java.sun.com/j2se/1.4.2/docs/guide/collections/
 Avalon - http://jakarta.apache.org/avalon/index.html
 Cactus - http://jakarta.apache.org/cactus/index.html
 Turbine - http://jakarta.apache.org/turbine/index.html
 JPOPS - http://jpos.org/
 A Java framework for GPS - http://www.aasted.org/gps/
 MyFaces - http://incubator.apache.org/projects/myfaces.html
 Sun Java Media Framework -
 http://java.sun.com/products/java-media/jmf/index.jsp
 A framework for Internet Distributed Computations -
 http://www.imc.pi.cnr.it/java.html
 http://www.imc.pi.cnr.it/java.html
 The Real time Java Framework -
 http://control.ee.ethz.ch/~ceg/RealTimeJavaFramework/doc/index.html
 Java Agent Framework - http://dis.cs.umass.edu/research/jaf/
 Janx - http://www.bearriver.com/janx.html
 Open Card - http://www.opencard.org/
 Piccolo - http://www.cs.umd.edu/hcil/piccolo/
 Symphony - http://zuni.cs.vt.edu/symphony/
 
 

Cool Outdoor Wireless Internet
Wireless Outdoor

Embedded Security: Top Ten Myths

by Mukesh Lulla, TeamF1

Perhaps no other area of embedded technology gets as much visibility today as security. After all, if .connectivity. of modern embedded systems was the wave of the last decade, it.s no surprise that .secure connectivity. is becoming an almost inescapable requirement as networks come of age. The prevalence of wireless, remote management, storage, and mobile technologies has reinforced the urgency of this requirement and sparked renewed interest in not just protection of data-in-transit, but also data-at-rest.

State of the Onion

As prolific as the exhortations to protect embedded devices are, the current state of security in many embedded applications still hovers somewhere between confused complacency and intimidated inaction.

.Security is a multi-dimensional problem., insist some pundits while others claim, .simplicity is the key to practical security.. .Think of security as an onion with layers and layers of defenses., more experts chime in. .Layers serve as obfuscation and give you an illusion of security., retort the critics. Confusion hath now made his masterpiece!

While the high priests of security duke it out and management, sniffing the fumes of unrealistic end-customer demands, wants nothing short of an absolute guarantee of security, we engineers are frequently left to sort out what is and what is not feasible. When it comes to security, conventional wisdom just isn.t!

Hit or Myth

Muddying the waters further are some widely held misconceptions. We cannot resolve the apparent contradictions surrounding the best practices for secure devices without first clearing this fog, so we.ll start by dispelling ten of the more egregious myths surrounding this subject:

1. Myth #10 : We aren.t the likely target of an attack

   This is the most pernicious myth of all and takes various forms: .The data on/from my device is useless to others, ergo I don.t need any security.. Or, .who would ever want to spend the effort to hack my system?.. But with the proliferation of easily accessible hacking tools, advanced crackers aren.t all you need to worry about-a whole army of kiddie-script writer wannabes is waiting for their 15 minutes of fame.

2. Myth #9 : My embedded system.s security has never been broken, so it.s all we need

   Sure, that.s like saying: .I intend to live forever – so far, so good.. Enough said!

3. Myth #8 : My device is password .protected.

   Well, password protection at least implies awareness of a requirement for security. However, passwords are usually sent over a network in clear-text and are easily captured by packet sniffers on intermediate network nodes. In most cases, they provide only a deceptive veneer of security. If the password scheme protects remote management or access to the device, an attacker could potentially gain complete control of the device with impunity. Even if passwords were sent over a secure channel, they may still be susceptible to dictionary attacks.

4. Myth #7 : Security protocol XYZ is the silver bullet

   Once convinced that real security is needed, many users start looking for a quick fix believing that some single well-known security protocol is all that their device needs. One common manifestation: .My device has a firewall, so I don.t need to worry about security threats.. Such delusions of adequacy may blind one to serious vulnerabilities in the system such as lack of protection for network data.

5. Myth #6 : Two security protocols are better than one

   This is only a half-myth, but is so frequently abused that it deserves attention. Belief that there is no one panacea for security convinces some to take it to the next logical step-back up the truck and load up on it. After all, more security can.t be worse than less security. But what.s forgotten in this exquisite distillation of logic is that security is weakest at the seams, so adding multiple security layers to an embedded device without thinking it through is like putting three dead-bolts on a door whose door jamb is not anchored to the wall. Security should be a strategy, not a bunch of protocols.

6. Myth # 5 : Security is the same as encryption

   This myth and its corollary-.cryptography is the same as encryption.-are byproducts of buzzword hype. Certainly, encryption is a cornerstone of information security, but consider this fallacy: what if an encrypted (and thus, confidential) connection goes not to the entity you expected to communicate with, but to an unauthorized one? In other words, you may have a completely secure channel, so no one else can listen in to your conversation with. an attacker! Security needs to include authentication (identity verification), integrity (tamper-resistance), and various other techniques to thwart attacks. These are typically based on cryptographic operations, which include but are not limited to encryption.

7. Myth #4: More .bits. mean stronger security

   Yet another fallacy related to encryption is that more .bits. of encryption mean higher security strength. However, like all data, the impact of the .bits. (usually key-size or block-size of encryption algorithms) only depends on the application that uses it-in this case, the encryption algorithm. Assuming that 256-bit RC-4 is stronger than 128-bit AES encryption is like comparing apples to oranges, not to speak of the watermelons that elbow their way in when 1024-bit public-keys (RSA, DSA) are thrown into the equation.

8. Myth # 3 : Security will get in the way of my application

   Security is a subject that turns many embedded developers off. The resource requirements (code size, memory usage, CPU .horsepower.) for cryptography are often formidable by embedded standards. Even if that were reconciled, developers often think that security detracts from their productivity by making things difficult. However, a well-designed security solution that leverages hardware / software optimally, and provides a common framework to secure different aspects of an embedded application can be less intrusive than one may imagine.

9. Myth #2 : I can do it better

   Embedded development frequently revolves around the efficiency of solutions developed in-house because .No one understands my systems as well as I do.. Security protocols, in particular, are viewed as laden with more baggage than a Samsonite factory, so some developers concoct small-footprint, lightweight implementations without the .bells and whistles.. If this is done without a full understanding of why a protocol required it, the bell or whistle that was left out might spell the difference between strong and weak security, and worse, may not be exposed until it.s too late.

10. Myth # 1 : A proprietary implementation is more secure than an open one

    It is a human tendency to equate secrecy with protection of sensitive information and this reasoning has been used to promote some really arcane security implementations. However, if secrets extend beyond the realm of replaceable secret keys to the use of secret methods and implementations, this can be a major cause of brittleness. .Security by obscurity. flies in the face of good security practices. Core security-especially the security protocol and cryptography-should be based on code available for public review. This ensures a deeper analysis of any vulnerabilities than would be possible with any single company.s proprietary code which claims compactness and is written partially in .high-performance. assembly that looks like line noise, just so that .no one can break into it..

Deconstructing Security

Achieving strong security is indeed a multi-dimensional problem, but the key is to architect the system using a cohesive approach to security, rather than stitching together a solution from various pieces-remember, the seams are always the most vulnerable. Inadvertent vulnerabilities resulting from the use of a well-designed crypto algorithm in an application it was never intended for, may be worse than choosing a weaker algorithm and knowing the consequences upfront. The .layers-of-onion. model of security can provide defense in depth, but only if the layers are standard components put together in a consistent manner so as to complement each other.

It is important to recognize the different facets of the embedded security problem first and make sure all relevant ones are considered in the solution. One way to divide the security requirements of an embedded system is to analyze three areas:

Data Security-security of raw data residing on the device e.g. configuration files, statistics, or even databases.

System Security-security of the embedded device as a networked node, or security of the perimeter of a network of devices.

Network Security-security of the data moving between a device and other systems.

Of course, a heavy-gauge steel box welded shut is a very secure container indeed, but not a very useful one. So it is important to remember that a secure system does need to allow access to AUTHORIZED users. This ties in to the concept of identity or more specifically, proving that an entity is who it purports to be-Authentication, which is another important dimension of security that needs to be analyzed.

An embedded device that integrates these elements of security in a seamless manner and complements them with consistent system-wide security policies would be a truly secure device, not just one believed to be secure. After all, while optimism has its place in the world, it has no business being a part of your device.s security strategy.

Enterprise Service Bus using JSR 208: JavaTM Business Integration (JBI)
ESB will supercede traditional integration solutions offered by companies such as WebMethods and SeeBeyond. Bea plans to offer QuickSilver, Sonic Software, Cape Clear, SpiritSoft, and Celtix (based on IONA’s Artix).

Booch Presentation on Complexity

Complexity of the problem domain
Difficulty of managing the development process
Fluidity of software
Fundamental challenges of discrete systems
Volume of requirements
Presence of competing/contradictory requirements
Non-functional requirements that push the limits of software
Requirements churn
Difficulty of communicating requirements
Impedance mismatch among stakeholders
Unrestrained external complexity
Software drag

Size up
Increasing database size by a factor of x increases query response time by at most a factor of x.

Speed up
Increasing the capacity of your hardware configuration by a factor of x decreases your query response time by no less than a factor of x.

Scale up
Increasing the workload on your system by a factor of x while maintaining response time and/or throughput requires increasing your capacity by a factor of no more than x.

Scale out
Increasing workers by a factor of x requires replicating your capacity by a factor of at most x.
http://www.intelligententerprise.com/db_area/archives/1999/991602/scalable.jhtml

Fluidity of software
Software springs from pure thought and is intrinsically malleable, yet it can be made manifest in our hardware systems, limited only by our vision (and certain immutable laws of physics and software)

Fundamental challenges of discrete systems
Non-continuous behavior of discrete systems
Combinatorial explosion of states
Corruption from unexpected external events
Lack of mathematical tools and intellectual capacity to model the behavior of large discrete systems

Essential complexity
.Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity that he must master is arbitrary complexity.. [Brooks]
We may master essential complexity, but we can never make it go away.

Attributes of a complex system
.Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached.. [Courtois]
Hierarchic systems are decomposable if they can be divided into identifiable parts; they are nearly decomposable if their parts are not completely independent. [Simon]
The choice of what components in a system are primitive is relative arbitrary and is largely up to the discretion of the observer of the system.
As systems evolve, objects that we once considered complex become the primitive objects upon which more complex systems are built.
Intracomponent linkages are generally stronger than intercomponent linkages. This fact has the effect of separating the high-frequency dynamics of the components . involving the internal structure of the components . from the low-frequency dynamics – involving interaction among components. [Simon]
Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements. [Simon]

Decomposible and nearly-decomposible systems

A few articles and useful links:
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software

AOSD 2005

AOP with Metadata: principles and practices (Ramnivas Laddad)

Guideline: don’t use annotations when you can do without them. Eg. you want to capture all RMI operations. You can write a simple, stable pointcut: execution(* Remote+.*(..) throws RemoteException) – no need for an annotation here. Likewise you can write a stable pointcut for all thread-safe calls to the Swing library – you don’t need annotations for this either.

Not sure if Ramnivas is going to mention this, but there are also expressibility limitations with annotations – you can’t say for example “all calls to x within y” since you can’t annotate calls (you can say “all calls to a method with an annotation X made within y” – but that’s a slightly different thing). There are other examples too…

A second guideline from Ramnivas: employ aspect inheritance to defer pointcut specification to a sub-aspect. Now write one pointcut per “subsystem” this will be much easier than trying to write a single global pointcut that works across the whole system.

A third guideline – make use of existing annotation types – eg. EJB

A fourth guideline – if you create annotation types, use names that describe a property of the annotated element, not an instruction to some processor. Eg. @ReadOnly, not @ReadLock, use @Idempotent, not @RetryOnFailure, and so on.

A final guideline – wisdom comes with experience: start with something and refactor as you go along.

Ramnivas is now discussing whether metadata-fortified AOP harms “obliviousness”. His argument is that it does not if the guidelines are followed.

The final flourish in Ramnivas’ talk. You could have an aspect that matches on annotated methods… if you don’t want to annotate them individually, you can use an inner aspect (participant pattern) to declare them…