Maulahikmah Galinium

CR
3papers
15citations
Novelty23%
AI Score15

3 Papers

CYDec 26, 2014
Case Studies: Business and Technical Perspectives in Migration of Legacy Systems to Service Oriented Architecture

Maulahikmah Galinium, Negar Shahbaz

In adoption process of Service Oriented Architecture (SOA), the legacy systems of a company can not be neglected. The reason is the legacy systems have been deployed in the past and have been running critical business processes within an enterprise in its current IT architecture. However not all migration process of legacy systems to SOA has been successfull. Highlighting the right factors to reach legacy systems migration success in a specific company is the key value. The main adopted research method in this study has been interviewed for different companies with different enterprises including bank, furniture, engineering and airline companies in Europe. Through separate interviews, critical success factors of migrating legacy systems into SOA have been collected and identified in each case company. Finally collected results are analyzed and presented as the recognized factors affecting successful migration of legacy assets into SOA from business and technical perspectives.

CRSep 11, 2012
Interleaving Command Sequences: a Threat to Secure Smartcard Interoperability

Maurizio Talamo, Maulahikmah Galinium, Christian H. Schunck et al.

The increasingly widespread use of smartcards for a variety of sensitive applications, including digital signatures, creates the need to ensure and possibly certify the secure interoperability of these devices. Standard certification criteria, in particular the Common Criteria, define security requirements but do not sufficiently address the problem of interoperability. Here we consider the interoperability problem which arises when various applications interact with different smartcards through a middleware. In such a situation it is possible that a smartcard of type S receives commands that were supposed to be executed on a different smartcard of type S'. Such "external commands" can interleave with the commands that were supposed to be executed on S. We experimentally demonstrate this problem with a Common Criteria certified digital signature process on a commercially available smartcard. Importantly, in some of these cases the digital signature processes terminate without generating an error message or warning to the user.

CRMay 4, 2012
Interleaving Commands: a Threat to the Interoperability of Smartcard Based Security Applications

Maurizio Talamo, Maulahikmah Galinium, Christian H. Schunck et al.

Although smartcards are widely used, secure smartcard interoperability has remained a significant challenge. Usually each manufacturer provides a closed environment for their smartcard based applications including the microchip, associated firmware and application software. While the security of this "package" can be tested and certified for example based on the Common Criteria, the secure and convenient interoperability with other smartcards and smartcard applications is not guaranteed. Ideally one would have a middleware that can support various smartcards and smartcard applications. In our ongoing research we study this scenario with the goal to develop a way to certify secure smartcard interoperability in such an environment. Here we discuss and experimentally demonstrate one critical security problem: if several smartcards are connected via a middleware it is possible that a smartcard of type S receives commands that were supposed to be executed on a different smartcard of type S'. Such "external commands" can interleave with the commands that were supposed to be executed on S. Here we demonstrate this problem experimentally with a Common Criteria certified digital signature process on two commercially available smartcards. Importantly, in some of these cases the digital signature processes terminate without generating an error message or warning to the user.