Algorithm Exchange of a Security Control System for Web Services Applications
Benny B. Nasution, Elizabeth A. Kendall, Asad I. Khan
School of Network Computing, Faculty of Information Technology, Monash University McMahons Road, Frankston 3199, Australia; Ph: +61 3 9904 4287; Fax: +61 3 9904 4124
{benny.nasution, elizabeth.kendall, asad.khan}@infotech.monash.edu.au
Abstract
It has been determined that the complexity of Internet infrastructures, such as in a distributed system (Web services), can conceal the potential risks of attacks, and subsequently become disadvantageous to Internet users, applications and institutions. We have considered that a better way to cope with such problems can be achieved through utilisation of a systems approach, rather than an analytical approach. In this article the development architecture will be described, and the implementation results of algorithm exchange as part of the TTSN architecture (the project that is currently being undertaken) will be presented. Since Web services applications perform XML-based transactions, which are very vulnerable against an interception, algorithm exchange is a superior alternative than key exchange, the currently common strategy to protect confidentiality, integrity and authentication of data. The reason why key exchange is no longer appropriate for the current Internet technologies will also be discussed.
1. Introduction
Web services have become a very attractive and evolving Internet technology. The framework is not complete yet, but their usages, even multimedia applications [15], have been widely reported [1, 2, 9, 10].
The main reason why Web services are gaining so much attention lies on its capability of combining and interoperating heterogeneous Internet communities.
Web services technology has also been used in legacy and even critical applications. Sensitive transactions are now filling up Web services data communications, such as those of Internet banking, remote controlling, online shopping, and many more. For application oriented purposes its capabilities can be very attractive, however, the current standards behind the technology need to be justified very carefully, before deploying Web services for very sensitive or private applications. In fact, default Web services transactions are unencrypted and unsecured, and they can create the potential for disaster [6].
Despite all the attractiveness and capabilities of Web services, many industry observers are still concerned about the security aspect of Web services [6], which does not seem to be able to properly accommodate and protect
important and sensitive data. Since Internet security is a very complex issue, and attackers (e.g. interceptors) still can gain the XML-based traffic without major effort, solutions for Web services security are still under intensive development.
In this article, the architecture of Trusted Transient Simple Network (TTSN), an Internet security control system, as a justifiable means to deal with Web services security issues is proposed. Specifically, the implementation results of algorithm exchange, as one of the core parts of the TTSN’s architecture, will be described, presented and discussed. The intention of algorithm exchange is not based on replacing the current Internet security standards; rather it is a better option for Web Services applications to reach the optimal goal of Internet security requirements.
In the next two sections, the technology of Web services including its security aspect is described and discussed, followed by the specification of the architecture and the functionalities of the TTSN. The following section discusses thoroughly the concept and the implementation results of algorithm exchange. In the last section, the work and the main parts of TTSN, which still need to be developed in order to find the most efficient and feasible results of their study, are summarised and discussed.
2. Web services
Due to its rapid improvement, the Web is now no longer just an information provider, but has evolved to be a service provider [22]. There are several possible reasons why the popularity of providing services through the Web is increasing. It has been suggested [7] that this underutilisation of the Internet was a consequence of its traditional usage as a information provider. Demurjian Sr., et al. [4] argue that web-based computing normally deals only with providing interoperation and information services. Another aspect is that Web services offer loosely-coupled program-to-program communication, which is better than a traditional tightly coupled communication application which takes considerable time to specify the connection and the relationship between applications [2].
According to Clabby, et al.[2]: “Web services are an evolving distributed computing architecture that uses its
own program-to-program interfaces, communications protocols and a registry service to enable similar and disparate applications to communicate and perform
‘services’ for one-and-other.”
Curbera, et al. [3] state that Web services are evolving and will provide a systematic and extensible framework for application to application interaction. Nevertheless, some researchers [2, 10] have concluded that the biggest problem in implementing Web services broadly is probably a deficiency of the security section. To contribute a good security environment for Web Services, the TTSN project specifically uses a Web services-based test bed during the test phase of the project.
3. Web services security
The issue of Web services security has attracted much attention. Many companies and organisations have proposed a number of methods, mechanisms, tools and standards, among which Web services security (WS- Security) standards seem to be the most matured and popular one. The standards have been implemented and exposed with positive results over the last couple of years.
The most complete standards for XML and WS-Security have been summarised by Naedele, M. [13].
According to Atkinson, B., et al. [1], WS-Security has described the improvement of the XML-based SOAP messaging, the communication protocol of Web services, to protect message integrity, message confidentiality and single message authentication. WS-Security has also described explicitly that the current mechanisms do not provide complete security solutions and therefore allows external security models to be collaborated with [1].
Consequently, it is unlikely to be able to construct a monolithic security mechanism since there are many existing and running security standards that Web services security must comply with.
This certainly shows that even the most deployed and leading technology to protect Web services security cannot fulfil the ultimate requirements of security (authorisation, authentication, confidentiality, integrity, non-repudiation, and availability). Even though WS- Security standards fully support message integrity and message confidentiality, they are still dependent of the PKI infrastructures for managing keys. In other words, applications must have their own additional security protections, especially those applications for sensitive data.
The problem with Web services security exists not only because security on the Internet is a very complex issue, but also because the risks (vulnerabilities and threats) including attacks are also evolving and thus increasing the complexity of Web services security.
Despite its good aspects, Web services also present network administrators with a thorny problem as Web
services open up networks by allowing outsiders access databases, applications and internal users [6].
4. Trusted Transient Simple Network (TTSN)
Although some strategies to handle Web services security have been produced, implemented, and improved, researchers and users cannot yet trust Web services for their mission critical transactions. Nakamur, Hada and Neyama [14] have seen that a part of the problem’s source is in its de facto SOAP standard. Web services use SOAP security, which by definition can include intermediaries where any of them is neither the requester nor the responder, but a third party [14]. Some researchers are also of the opinion that successful Web services security can be achieved if it contains a set of flexible and interoperable security primitives that can be implemented in a variety of secure solutions [9], not relying on a third party.
Another view on the security of this technology is that traditional security systems have common deficiencies, such as not having a dynamic design, not being applicable for mobile environment, or being too complicated [20].
Since applications of Web services cannot rely on a third party for their transactions, end-to-end security is necessary [21]. This means that each party should provide itself with a sophisticated security control system and be very independent of any other middle parties.
Dealing with the above concerns, the TTSN Security Control System has been researched to uncover not only improved strategies but also an innovative alternative to dealing with end-to-end network transaction security, e.g.
Web services security. The most frequent strategies which have been used to solve security problems have normally focused on already known risks (vulnerabilities and threats), and then on building the problem solvers for particular results and requirements [8, 11, 18]. Such strategies will possibly fail whenever previously unknown risks occur [19]. In order to overcome this difficulty a new paradigm for dealing with network transaction security is needed. Some researchers have attempted to improve common strategies. However, they continue to apply an analytical approach. The TTSN project alternatively attempts to use a systems approach.
Figure 1 shows the general architecture of the implementation of the systems approach (built in A and B). It also shows the interconnection between TTSN members (A, B and two middle parties X and Y).
User A B Provider X
Y
= Possible attacks
TTSN
Figure 1. The TTSN’s traffic interconnection
According to Figure 1, if A is the requestor of a transaction to B, the traffic package leaving from A through one path will be sent back to A along another path. Moreover, B will also need to append the reversed traffic package to A with a response to the request (piggy- backing) and several other protocol components. In this way, A will have adequate information about the state of the transaction including some behaviour of its counterpart. The information can subsequently be used to control the security. Both A and B nodes have equal functionalities and architectures as specified by the systems approach.
In Web services environment, User is the service requester and Provider is the service responder, and both need to deploy TTSN functionalities. It means that each party has either an A or B role. In the TTSN specifications, X and Y can be any node affiliated to either A or B. It is important to mention that the TTSN is transient. It can be activated or deactivated dynamically by the owner. But, when a party utilises TTSN for a transaction, the counterpart should activate TTSN as well, to respond to the transaction.
Figure 2 describes how the security control system is implemented in the TTSN from the node A’s perspective.
Controller Plant
(X, Y, and B) Provider
User
+
A
= Possible attacks
Figure 2. TTSN security control system
The security controller in A treats all X, Y, and B as the plant of the control system. If the plant is “not stable”
(e.g. the host being under attack), or the traffic contains distortions (as the condition of a channel attack), the controller in A must maintain the process in a continuously “stable” state. Stable here means that all the
security properties within both A and B are still guaranteed.
Any application connecting to the TTSN should use XML format to communicate with either A or B.
However, since FTP, SMTP, and SNMP protocols also have character-oriented structures, it is likely to extend the TTSN for these protocols without major effort. Such architecture also allows the TTSN to cooperate with current security infrastructures such as SSL/TLS, Kerberos and PKI, and can be used for several Internet distributed systems, e.g. peer-to-peer and Web services.
The TTSN integrates intelligent agents in its systems approach to overcome complexities in agent cooperation and communication. In most previous implementations, agents are used to accomplish particular tasks (well- specified problems and results) as the result of an analytical approach. However, with the current improvements in agent technology, intelligent agents can cooperate, communicate and be autonomous. For example, agents analyse and decide by themselves which agent should get contact with, when/why to update the algorithm, and so forth. All the decisions are performed using reasoning mechanisms. Most reasoning mechanisms in TTSN architecture (see Figure 6, 7 and 8) are implemented using Fuzzy logic. Figure 3 shows the interdependency of all security properties which build a systems approach. Each property will be occupied by an intelligent agent.
Confidentiality
Authorisation Authentication
Integrity Availability
Consistency Non-
Repudiation
Figure 3. Interdependency of security properties
Intelligent
Non Intelligent Director
Module
Non Intelligent Non
Intelligent
Intelligent Feedback Module
Forward Module
Outer Interface Module
Application
User Setting
Inner Interface Module
Controller
Middle Party (X)
Middle Party (Y)
Plant TTSN
Party-B
Party-A
= Data
= Command
Figure 4. Interconnectivity of the TTSN’s modules
Transaction Record
Extract
Session Validity Considerations
Transaction ActivityProtocol
Select Session
DataProtocol
Session DataBase
Evaluate Session
Condition
Session ActivityProtocol Transaction
DataBase Transaction ActivityProtocol
Security Decide Security Diagnoses
Security Diagnose Security Symptoms
Security Monitor Security
Traffic
Security DataBase
Director Agent Security Agent
Compile
Figure 5. Agents connectivity in a session
Figure 4 shows that the TTSN architecture consists of four main modules. Each module has its own characteristics and tasks following the architecture of a control system. Such architecture has been adopted from the common structure of control system engineering, in which the controller must maintain the process in a continuously stable state.
Additionally, TTSN uses blackboard technology [5] as the loosely coupled communication medium amongst agents. Through deploying cooperative multi intelligent agents, loosely coupled interrelationships, and strong definitions of policy and rules, the aim is that TTSN will be capable of solving and handling any current and potentially new vulnerability and threats.
As the agents need to observe and analyse the behaviour of each transaction, they also need to be able to recognise unusual or uncommon activities/conditions of both user and provider applications by analysing the previous and common transaction activities. Weinberg and Weinberg [23] stated that the aggregation of components in a system can protect against unknown errors while separated functionalities of the components can only detect known errors. This concept is implemented in TTSN through the aggregation of several intelligent agents to tackle future threats, and through specialisations of intelligent agent capabilities to deal with known threats or risks. Such a mechanism is unlike a rule-based detection mechanism which can not detect unforeseen attacks [19].
Figure 5 shows the solving template of TTSN in reasoning the current condition of a session. Figure 5 also presents that every security agent outputs its transaction record to the director agent (inside the Director module).
All processes (ovals) can contain several sub-processes and object dependencies. Figures 6, 7, and 8 show the entire Monitor, Diagnose, and Decide processes inside the Authorisation agent. Other agents have also similar structures with the one of Authorisation agent.
Recognise Activator
Authorisation Traffic
Authorisation DataBase
Recognise Activities
Host System
Activator Used/Open
Resources
Select
Resource Evaluate
Authorisation Symptoms other security
traffic
Figure 6. Monitor reasoning template
Transaction Protocol
Generate Symptoms
Observable Hypotheses
Select
Hypothesis
Verify
Specify
Authorisation Database
Finding Obtain
Authorisation Diagnoses
Figure 7. Diagnose reasoning template
Transaction Database
Specify
Authorisation Diagnoses
Specifications
Evaluate Authorisation
Records
Select
Selection
Figure 8. Decide reasoning template
5. Algorithm Exchange
Most Internet transactions perform secret key sharing/exchange for their encryption/decryption in protecting the confidentiality of the message. Since Web services applications perform XML-based transactions, the message is therefore very likely to be intercepted. An interceptor generally has a chance to crack the content of message sooner or later, owing to the condition that the algorithms used to encrypt/decrypt the message of most Internet transactions (including those of Web services), are very common: DES, TripleDES, RC2, RC4, Blowfish, or IDEA.
The interceptor, in the worst case, can still perform a brute-force analysis to the secret key, deploying hardware key-crackers e.g. Field Programmable Gate Arrays (FPGA) or Application Specific Integrated Circuits (ASIC). Besides, the dependency of keys on PKI has prohibited the key owner from updating/modifying the secret key dynamically. The main reason is that PKI itself is a very complicated infrastructure and not suitable for dealing with dynamic systems.
In contrast to the above, the TTSN performs an algorithm exchange instead of a secret key sharing. The algorithm exchange is managed in the OuterInterface module of the TTSN, which directly connects to the middle parties (X and Y). Both parties exchange their algorithms dynamically throughout the session of a connection. Since both parties use their unique algorithms, an interceptor will take much longer time, if it is not unlikely, to crack the message performing a brute- force analysis to the algorithm, not to the key. Up until now no techniques are available to crack software algorithms.
The following are some functionalities of the implementation for the algorithm exchange of the TTSN:
• In JavaTM environment, the serialised class of an algorithm can be sent over to the counterpart. It can be loaded dynamically on the counterpart’s side during run-time. Then, the methods of the class can be invoked through utilising the java.lang.reflect package. As a consequence, both parties can update their partner’s algorithms as often as they need.
• Although most of ordinary JavaTM classes can be decompiled, for instance by using Mocha [12], to prevent a malicious partner from gaining the source code from the algorithm’s class, the class should first be obfuscated e.g. by using Crema [12], or JBuilder.
• Cryptographic algorithm exchange is not only for guaranteeing the confidentiality of transactions, but it is also useful and feasible to be used for examining authentication and message integrity. Like public and private keys, each party must have two (a pair) different algorithms for encrypting and decrypting respectively. Using this mechanism, a malicious recipient (partner) cannot use algorithm’s class from the sender to impersonate the sender. Additionally, there is a method inside the algorithm class that can conceal the sender’s credential, which can only be disclosed using sender’s previous algorithm’s class, not the current one. As for data integrity, the recipient must deploy the previous algorithm to check the integrity of the data through validating the signature, which is embedded in the algorithm’s class as well.
The digest of the data can be generated using SHA1 or MD5.
• To increase the traffic speed and to save the bandwidth, parties do not need to update the algorithm (encrypt() method in the algorithm class) during every transaction. In this case, the requestor/responder must use the previous encrypt() method.
• Both cryptographic algorithms use bytes as their input and output types. In JavaTM every object can be converted into bytes, and XML generator converts an array of bytes into an array of integer values. To reduce the message size, the bytes can be sent as a String. However, sending bytes as a String in an XML-based message over the Internet is not always the best option for the recipient. There are currently many standards of byte encoding, especially for exotic script like Chinese, Japanese, Arabic, etc., which normally has problems in converting from the alphabetical characters. It has been investigated, however, that decimal numbers are still the most common symbols used in most countries. So, the bytes are converted into very long decimals, then into string format (decimal symbols) before being inserted into XML messages. JavaTM language provides
BigInteger type which can be constructed as the representation of any long bytes.
• A better situation can be achieved if both parties can exchange their first algorithms through an out-of- band channel before starting their first transaction.
This can be fulfilled, for example, by sending the algorithms through the post, since the class can be converted into decimal symbols.
5.1. Implementation results of cryptographic algorithm exchange of TTSN
We have successfully implemented and tested a cryptographic algorithm exchange in a Web services environment using IBM WebSphere Studio Device Developer (WSDD5.6). We have used JavaTM JDK1.4.1 to develop the implementation, which is run on a Windows XP platform.
For example, the responder provides the following addition services for requesters:
Integer addInteger(Integer num1, Integer num2);
String addInteger(String num1, String num2,
String algorithm);
The first method, Integer addInteger(Integer num1, Integer num2), is only required as the reference for the requestor to figure out the original parameter and output types.
For algorithm exchange, the requestor prepares two algorithm classes:
public class AlgorithmFromRequestorForResponder {
public String encrypt(String input);
public String getCredential();
public String getSignature();
}
public class AlgorithmFromRequestorForRequestor {
public String encrypt(String input);
}
Similarly, the responder prepares two algorithm classes:
public class AlgorithmFromResponderForRequestor {
public String encrypt(String input);
public String getCredential();
public String getSignature();
}
public class AlgorithmFromResponderForResponder {
public String encrypt(String input);
}
All the String of the methods’ parameters and outputs are actually representing bytes in decimal symbols.
The following is the method to convert an Object to bytes, to BigInteger, and subsequently, to its String representation.
public String objectToBigString(Object obj) {
String result= null;
ByteArrayOutputStream theBAOS= null;
ObjectOutputStream theOOS= null;
try {
theBAOS= new ByteArrayOutputStream();
theOOS= new ObjectOutputStream(theBAOS);
theOOS.writeObject(obj);
result= (new BigInteger(
theBAOS.
toByteArray())).
toString();
theOOS.close();
theBAOS.close();
}
catch (Exception e) {
e.printStackTrace();
}
return result;
}
The next are examples of decimal representations after generating an object of a String (“pong”) and an Integer (40) objects. Before the transmission, the decimals as an algorithm representation can be compressed. Using java.util.zip the decimals are compressed up to 50%.
String answer= new String("pong");
-100430567598249658205376921 Integer result= new Integer("40");
-
379021188419883304612275037624762637167570689059 075516358842782058318539784957832575000280235272 894199675483796453983753950693591072431919703458 861869340597671260774642958878992431145937008590 808
To load the algorithm class dynamically and to gain the method, the ClassLoader has been used.
public class MyClassLoader extends ClassLoader {
public MyClassLoader() {
super();
}
public MyClassLoader(ClassLoader parentLoader) {
super(parentLoader);
}
public Class generateClass(
String className, byte[] classData) {
return defineClass(
className, classData,
0, classData.length);
} }
public Method getMethod(String methodName, Class cls)
{
Method theMethod= null;
Method methlist[]= cls.getDeclaredMethods();
for (int i= 0; i<methlist.length; i++) {
theMethod= methlist[i];
if (theMethod.getName().equals(methodName)) {
break;
} }
return theMethod;
}
public MyClassLoader theClassLoader= new MyClassLoader();
public Method thePartnerEncryptorMethod= null;
public Object thePartnerAlgorithmObject= null;
private void getThePartnerEncryptor(String algorithm)
{
Class thePartnerAlgorithmClass=
theClassLoader.generateClass(
"AlgorithmFromRequestorForResponder ", (new BigInteger(algorithm)).toByteArray());
thePartnerEncryptorMethod= getMethod(
"encrypt",
thePartnerAlgorithmClass);
try {
thePartnerAlgorithmObject=
thePartnerAlgorithmClass.
newInstance();
}
catch (IllegalAccessException e) {
e.printStackTrace();
}
catch (InstantiationException e) {
e.printStackTrace();
} }
After the algorithm class has been loaded, instantiated to an object, and the method has been extracted, the partner can invoke the method using the following code.
Object[] params= new Object[1];
params[0]= theInputBigString;
String theOutputBigString=
(String) thePartnerEncryptorMethod.invoke(
thePartnerAlgorithmObject, params);
5.2. Implementation for supporting Authorisation, Non-Repudiation, and Availability
As the implementation for supporting authorisation and non-repudiation directory structure tools for TTSN utilising Java’s BasicAttribute and BasicAttributes classes have been developed. The tools follow the Light Weight Directory Access Protocol (LDAP) standards, which are based on the X.500 of CCITT standards. The decision of implementing such standards has been taken due to the fact that LDAP and X.500 have been already implemented successfully in many network architectures, and proven useful for several purposes. Besides, the project would like to be completed in a way so that TTSN could also be incorporated with several current network architectures.
The functionalities that have been implemented for managing the directory structure are:
insertDirectory (modify the directory structure), insertObject (add an object in a directory), insertAttribute (add an attribute for particular objects), getObjectDirectory (retrieve the directory location of an object), getObjectDomain (retrieve the domain of an object), etc. The directory structure is used to assist TTSN in authorising the partner and to support non-repudiation of a transaction. After performing a number of successful tests for this structure, it has been observed that both Java’s BasicAttribute and BasicAttributes classes are adequate for the purpose of authorisation and non-repudiation.
The advantage of using BasicAttribute is that the same attribute name, which is used as the unique identification of the partner, can accommodate different attribute values (objects). This is important for TTSN, since the attributes will be improved constantly, such as for storing algorithms dynamically. By storing all the algorithms from the same partner within the same attribute name, the partner will not be able to deny a transaction (non-repudiation) since all the stored algorithms will produce the same partner’s credential and partner’s identity as currently known. Besides, the structure of the directory can also be used to construct the history of the transactions.
The BasicAttributes are basically used to construct and recall grants, policies, and rules that are essential for managing authorisation for the partner. In a dynamic environment the values may change at any time, and so may grants, policies, and rules. Using the BasicAttribute and BasicAttributes classes allow us to handle authorisation and non-repudiation efficiently.
Additionally, because the algorithms are stored in this structure, authentication can also be managed.
For supporting availability, agents as the entities to run the whole TTSN structure have been deployed. If the
partner is no longer available or is under attack, the TTSN agents will disconnect the transaction independently. The
“transient” characteristic of TTSN means that the path will change dynamically according to the current situation. If one or both parties of X and Y (see figure 1) are no longer trusted, the agents will change the path to another trusted nodes. This mechanism is important for keeping the functionalities of TTSN available for as long as needed.
5.3. Comparison with other/similar technologies
On the first glance, algorithm exchange looks like the mechanism of IPSec or Opportunistic Encryption. In fact it is not. There are some crucial points which make algorithm exchange cannot be compared with IPSec or Opportunistic Encryption. Besides, until now no publication has shown that algorithm exchange has been developed or implemented.
The following are the key points, which have been summarised from RFC2401 and Opportunistic Encryption draft.
• In IPSec all algorithms must comply with IETF's
standards, which are very common (DES, TripleDES, RC4, etc) for attackers. A node cannot be embedded with user’s own generated algorithms.
• In IPSec all the algorithms are predefined (most likely inside the operating system) and its specifications must be stored in a database (SAD). All involved nodes must have exactly the same algorithms. Nodes can specify and negotiate during runtime about which one is going to be used.
• In Opportunistic Encryption the public key information must be added to the DNS records. Then, any two nodes can communicate securely. In this case, nodes do not exchange algorithms, but they still exchange keys.
• IPSec handles network-layer security to protect transactions from hardware- or operating-system-level attackers. Whereas most security issues of Web services are dealing with threats and vulnerabilities on higher levels than the IP layer. Many attackers are focusing on TCP or even application layers (Telnet, HTTP, FTP), which can be categorised as software-level attackers.
• Application partners or network administrators must not always be trusted, since they can also become malicious. Therefore, there is still a concern about IPSec in which every node is imposed to trust its partner and its network administrator in terms of confidentiality.
Hence, algorithm exchange becomes important for applications to avoid administrator’s intervention and control the partner.
• No other programming languages can dynamically load
a computer program during runtime but JavaTM. Besides, object serialisation and class reflection
technologies have given an opportunity to make such an algorithm exchange possible.
6. Conclusion and further research
This paper recommends the use of TTSN for Web services applications as an entity to provide security management features within a systems approach. A framework for utilizing such an approach in a distributed computing environment is still being developed in our research.
TTSN differs from the currently secure e-Business message service products specified by OASIS [16, 17].
All the products discussed in those articles, even the OASIS’ product ebMS [17], still utilise the current security technologies: IPSec (RFC2401), SSL/TLS (RFC2246). Both technologies are generally utilised to build a secure transaction (such as VPN) through new tunnelling and cryptographic mechanisms. In fact, all algorithms (DES, 3DES, RC2, RC4, RSA, MD5, SHA, etc.) of those technologies are still well known; therefore the key exchange is the only way to keep every well known cryptosystem unique.
We finally can conclude that, evolving risks and technology have made key exchange no longer adequate to be used for protecting Internet security. Although PKI has provided some mechanisms for security protection, brute-force analysis is still one of the big threats. Besides, many companies and organisations have produced various methods, strategies, tools, and standards to improve Web services security. Unfortunately they still rely on PKI and key exchange, which subsequently can be compromised by brute-force analysis.
Due to JavaTM and XML technologies, the TTSN project has been able to implement algorithm exchange.
Not only is it very hard for an attacker to brute-force an algorithm, but also it allows both requester and responder to update/modify their algorithms dynamically during run-time. Such possibility will reduce to a great deal the successfulness of attacking the algorithm. Not only can confidentiality and integrity be protected by the algorithm exchange, but also authentication, authorisation and non- repudiation can take advantage of it.
Since security requirements will differ from application to application, our model is not to be treated as a complete architecture for securing Web services transactions. Additionally, the intention of deploying algorithm exchange is not for replacing current security standards, but rather for application owners to have choices for their Web Services applications to reach an optimal goal of Internet security requirements. The issue related to the potentially malicious part encapsulated in the algorithm class can be solved through a protection from utilising sensitive Java’s libraries, such as file access, system access, etc.
We still have to elaborate the means for generating cryptographic algorithms uniquely and dynamically to support the algorithm exchange mechanism. Such algorithm generator must also be handy and comply with the portability of Web services technology.
7. References
[1] B. Atkinson, G. Della-Libera, S. Hada, M. Hondo, and P.
Hallam-Baker, "Specification: Web Services Security (WS- Security)," vol. http://www- 106.ibm.com/developerworks/library/ws-secure/, May 24, 2004.
[2] J. Clabby, "Web Services Gotchas," Bloor Research N.A., Yarmouth, ME, Report July 2002.
[3] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana, "Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI," Internet Computing, IEEE, vol. 6, pp. 86-93, 2002.
[4] S. A. Demurjian Sr., Y. He, T. C. Ting, and M. Saba,
"Agent Approaches to Enforce Role-Based Security in Distributed and Web-Based Computing," presented at 13th Annual IFIP WG 11.3 Working Conference on Database Security, Seattle, Washington, 1999.
[5] R. S. Engelmore and T. Morgan, Blackboard systems.
Wokingham, England ; Reading, Mass.: Addison-Wesley, 1988.
[6] D. Geer, "Taking steps to secure Web services,"
Computer, vol. 36, pp. 14-16, 2003.
[7] L. Gong, "Project JXTA: A Technology Overview," Sun Microsystems, Inc., Palo Alto, Report 25 April 2001 2001.
[8] R. Hale, I. Poynter, and C. Sample, "Holistic Security,"
presented at Usenix Security, Denver, USA, 2000.
[9] M. Hondo, B. Dixon, G. Della-Libera, and J. Farell,
"Security in a Web Services World: A Proposed Architecture and Roadmap," 2002, pp. 1-20.
[10] IONA-Technology, "Enterprise Security in Web services,"
2002, pp. 1-32.
[11] A. Jøsang, M. A. Patton, and A. Ho, "Authentication for Humans," presented at The proceedings of the 9th International Conference on Telecommunication Systems (ICTS2001), Dallas, USA 2001, 2001.
[12] Q. H. Mahmoud, "Java Tip 22: Protect your bytecodes from reverse engineering/decompilation," in http://www.javaworld.com/javatips/jw-javatip22_p.html, vol.
May 14, 2004.
[13] M. Naedele, "Standards for XML and Web services security," Computer, vol. 36, pp. 96-98, 2003.
[14] Y. Nakamur, S. Hada, and R. Neyama, "Towards the integration of Web services security on enterprise
environments," presented at Applications and the Internet (SAINT) Workshops, 2002. Proceedings. 2002 Symposium on, Tokyo Res. Lab., IBM Res., Kanagawa, Japan, 2002.
[15] B. B. Nasution, E. A. Kendall, A. I. Khan, and J. Dospisil,
"Contributions of Web Services-Technology for Improving Resource Management of Real-Time Multimedia on the Internet," presented at Proceedings of the 14th Information Resources Management Association (IRMA) International Conference, Philadelphia, Pennsylvania, USA, 2003.
[16] OASIS, "e-Business Messaging Interchange
Assessments," in www.ebxml.org/ebxml_jmt/documents/wp_messaging_req_0523
03.doc, vol. August 31, 2004.
[17] OASIS, "Message Service Specification:
ebXML Transport, Routing & Packaging 2 Version 1.0 3," in http://www.ebxml.org/specs/ebMS.pdf, vol. August 31, 2004.
[18] T. D. Peddireddy and J. M. Vidal, "Multiagent network security system using FIPA-OS," presented at SoutheastCon, 2002. Proceedings IEEE, 2002.
[19] J. Pikoulas, W. Buchanan, M. Mannion, and K.
Triantafyllopoulos, "An intelligent agent security intrusion system," presented at Engineering of Computer-Based Systems, 2002. Proceedings. Ninth Annual IEEE International Conference and Workshop on the, 2002.
[20] L. Qi and L. Yu, "Mobile agent-based security model for distributed system," presented at Systems, Man, and Cybernetics, 2001 IEEE International Conference on, 2001.
[21] M. Soriano and D. Ponce, "A security and usability proposal for mobile electronic commerce," IEEE Communications Magazine, vol. 40, pp. 62-67, 2002.
[22] V. Vasudevan, "A Web Services Primer," vol. 2002:
XML.com, 2001.
[23] G. M. Weinberg and D. Weinberg, General principles of systems design. New York, NY: Dorset House, 1988.