Thursday, March 8, 2018

A giant leap for mankind?

Oh boy!!! Yet another year has gone by and we are celebrating International Women's Day again.
This year the theme is "Time is Now: Rural and urban activists transforming women’s lives".

I must say that working in atsec has always been free of the worries about gender inequality that I've been reading such a lot about recently, and that I know some of my industry colleagues have experienced (and probably still do). 

Here in atsec I feel nothing but respect and I am as empowered "as the next man".

According to Wikipedia, 2018 marks a whole century since women were first allowed to vote in Germany and the UK;  in Sweden the centenary is 2019; the US will celebrate  in 2020; In Italy, 2045 and in China it will be 2047

To those of my colleagues wondering about International Men's day, I am happy to report that this is celebrated every year on November 19th. This year the men's theme is "Positive male role models."

Wednesday, January 10, 2018

atsec is celebrating!!

It is 18 years since atsec was founded on January 11th, 2000. 

Since then atsec has made a very significant contribution to information security. As one of the only truly independent labs atsec is still  self-funded, owned by professionals in the security assurance business and a key player in the technologies and geographies in which we operate. We have hundreds of successful testing and evaluation projects, founded IT security conferences, contributed with a great many IT security consultancy projects, become one of the foremost PCI assessors in the China and Asia region, and had a lot of fun along the way.

Not many people know that the name "atsec" is related to the Italian word for basket, ("cesta"). This underlines that we have a great wealth of security-related expertise and diversity within atsec.

Thanks are due to all the atsec customers, schemes and programs, accreditors, atsec staff and alumni who have helped atsec reach this milestone birthday.

Tuesday, January 2, 2018

eIDAS for Remote (Centralised Server) Signing

What is eIDAS?

Evaluation and certification of trustworthy systems and signature and seal creation devices becomes increasingly important due to the new eIDAS regulation (EU Regulation No. 910/2014) that entered into force in the 28 EU Member States in July 2016. eIDAS is an EU regulation on electronic identification (eID) and trust services (AS), which was established to promote economic growth in the European digital single market, by enhancing the convenience and security of online transactions across EU borders. This is accomplished by establishing a European internal market for Trust Services, including various types of electronic signatures and seals, time stamps, electronic delivery services and website authentication, provided by Trust Service Providers (TSPs).

How it is used?

Ultimately, under the eIDAS regulation, citizens and businesses are able to use their native electronic identification schemes (eIDs) when accessing public services within other EU Member States that use eIDs, and use trust services have the same legal status as traditional paper-based processes and signatures. Digital signatures and seals with different trust levels are specified under eIDAS:

  • Electronic signatures or seals: anything which is used to sign to ensure origin and integrity of data (yet no trust in the identity is provided).
  • Advanced electronic signatures or seals: an electronic signature or seal with sole control properties. The advanced electronic signature or seal is created with a signature (seal) creation device (i.e. a software key or smart card). 
  • Qualified electronic signatures or seals: an advanced electronic signature or seal, which satisfies technical and security requirements as specified in the regulation. This type of signature or seal is created with a qualified signature creation device, which is certified against eIDAS requirements and standards.

Common Criteria?

International (technical) standards play a key role in ensuring transparency and high security for online transactions. The Common Criteria (ISO/IEC 15408) standard is one of the standards that supports eIDAS by providing assurance of, inter alia, the security of trustworthy systems, and signature (and seal) creation devices (International Organization for Standardization, 2009). Various Protection Profiles for Common Criteria evaluations and certification have been developed for local signature generation (i.e. on smart cards or USB tokens), such as the TS 419 211 part 1-6 (Protection Profiles for Secure Signature Creation Device).

Creation of signatures on Central Servers?

New Protection Profiles are being developed by the European Committee for Standardization 
(CEN). These will comprise the requirements for trustworthy systems supporting server signing, also known as central signing, server-side signing or cloud signing, which is employed to allow signatures (and seals) to be created remotely with the user’s signing keys. A Trustworthy Systems Supporting Server Signing is illustrated in the figure below. The remote protected environment, providing server signing capabilities, comprises a Server Signing Application (SSA) and a (Qualified) Signature Creation Device (QSCD). The user may use his mobile phone or any other personal device to remotely sign documents with qualified electronic signatures.


The new eIDAS regulation provides increased security and convenience for electronic identification and the use of trust services within the EU. Advantages of eIDAS include the recognition of native electronic identification schemes in all EU member states that use eIDs, and that trust services have the same legal status as paper-based processes and signatures. There are different types of signatures (and seals) with different trust levels, including electronic signatures or seals, advanced electronic signatures or seals and qualified electronic signatures or seals. Both local and remote signing, using qualified electronic signatures, require compliance to international standards in the eIDAS standards framework, including Common Criteria evaluations against Protection Profiles for, inter alia, Secure Signature Creation Devices (EN 419 211) and Trustworthy Systems Supporting Server Signing (EN 419 241 - draft).

Even though eIDAS entered into force more than a year ago, many aspects of the regulation are still under development. For instance, various standards for certification of components used for signing with qualified electronic signatures are still under drafting. It therefore remains to be seen what challenges will emerge in the future. Stay tuned for more information on eIDAS!

References and Further Reading

ANSSI (2016). Protection Profile for Trusted Signature Creation Module in TW4S (PP-RSCD-TSCM/TW4S v1.2).

DIN (n.d.). Trustworthy Systems Supporting Server Signing - Part 2: Protection profile for QSCD for Server Signing; German and English version prEN 419241-2:2017. [online] Available at: [Accessed 12 December 2017]

ETSI (2013). ETSI ESI Workshop: Signing in the Cloud. CEN Server Signing TS 419 241 part 1. [online] Available at: [Accessed 12 December 2017]

International Organization for Standardization (2009). ISO/IEC 15408: Information technology -- Security techniques -- Evaluation criteria for IT security.

Leroy, F. and Hernandez-Ardieta, J.L. (2012). Update from CEN TC 224 WG 17: Progress Status, Server Signing Standard and other related Protection Profiles. In 13th International Common Criteria Conference (ICCC 2012), Paris.  

Dorien Koelemeijer  &
Rasma Araby

Friday, October 20, 2017

ISO/IEC TR 15446: Guidance for the production of Protection Profiles and Security Targets

We are happy to hear that the latest revision of TR 15446:Guidance for the production of Protection Profiles and Security Targets has been published by ISO.

ISO/IEC TR 15446 provides guidance relating to the construction of Protection Profiles (PPs) and Security Targets (STs) that are intended to be compliant with the third edition of ISO/IEC 15408 (all parts). It is also applicable to PPs and STs compliant with Common Criteria Version 3.1 Revision 4, a technically identical standard published by the Common Criteria Management Board, a consortium of governmental organizations involved in IT security evaluation and certification.
NOTE ISO/IEC TR 15446 is not intended as an introduction to evaluation using ISO/IEC 15408 (all parts). Readers who seek such an introduction can read ISO/IEC 15408‑1.
ISO/IEC TR 15446 does not deal with associated tasks beyond PP and ST specification such as PP registration and the handling of protected intellectual property.

atsec thanks Helmut Kurth who was both the editor and a key contributing expert for this document.

Thursday, September 7, 2017

Linux: /dev/random study published

Hi folks,

The updated study for the Linux /dev/random and /dev/urandom has now been 
published at BSI. Please see [1] for the general web site and [2] for the 

Please note that at [1], there are additional documents for reusing the NTG.1 
conclusion of the study for Linux-based evaluations.

For the FIPS 140-2 folks: [2] should now be our entropy assessment report. In 
particular, chapter 6 provides the assessment according to SP800-90B we need. 
This study also contains in section 6.3 measurements of entropy during early 
boot time that will be necessary in the proposed update to SP800-90B.

This study will be continued for each new kernel version that comes out. The 
first kernel the study applies to is v4.9.



~ Stephan Mueller

Friday, August 11, 2017

As You Like It!

Over the last few years we have seen some maturation in the processes of providing information security assurance. This is good.

First let’s roll back into history, to the days in the ‘70’s and ‘80’s, when it could not be safely assumed that the operating systems in use implemented access control correctly. “The Birth and Death of the Orange Book” by Steve Lipner, provides a wealth of detail on the situation in the U.S., in those pre-Common Criteria days. The Orange Book described several assurance cases, with C1 and C2 being deemed appropriate for commercial products. The rallying call back then was “C2 by 92!”

Realizing that a bunch of different national criteria was not a good way forward in the battle for cyber-security, and that reliance on commercially available products was increasingly important, the Common Criteria (CC) were developed and implemented, governed by an international Arrangement known as the Common Criteria Recognition Arrangement (CCRA).

By my reckoning, the CCRA has been amended at least four times since it was established in 1998, with revisions in 2000, 2006, and 2014. Amendments were made that describe the agreed upon policies for use of the CC standards in the current situation.
At first, the infant,
Mewling and puking in the nurse's arms.
Then the whining schoolboy, with his satchel
And shining morning face, creeping like snail
Unwillingly to school. And then the lover,
Sighing like furnace, with a woeful ballad
Made to his mistress' eyebrow. Then a soldier,
Full of strange oaths and bearded like the pard,
Jealous in honor, sudden and quick in quarrel,
Seeking the bubble reputation
Even in the cannon's mouth. And then the justice,
In fair round belly with good capon lined,
With eyes severe and beard of formal cut,
Full of wise saws and modern instances;
And so he plays his part. The sixth age shifts
Into the lean and slippered pantaloon,
With spectacles on nose and pouch on side;
His youthful hose, well saved, a world too wide
For his shrunk shank, and his big manly voice,
Turning again toward childish treble, pipes
And whistles in his sound. Last scene of all,
That ends this strange eventful history,
Is second childishness and mere oblivion,
Sans teeth, sans eyes, sans taste, sans everything.

This first chart shows the number of evaluations completed in each year of the CCRA.

For the first version of CC, published in 1998, and in version 2, there was no concept of strict or demonstrable conformance.

This situation remained until CC version 3 was published in 2005. At that time three types of conformance were allowed: Exact, strict and demonstrable. As in earlier versions of the CC, partial conformance to a Protection Profile (PP) was not allowed.

Exact conformance is expected to be used by those PP authors with the most stringent requirements that are to be expressed in a single manner. This approach to PP specification will limit the ST able to claim conformance to the PP purely on the basis of the wording used in the PP, rather than a technical ability to meet the security requirements. This may be used in a Request For Quotation in a product acquisition process.

Strict conformance is expected to be used by those PP authors with vast experience of developing PPs, who again have requirements that must be adhered to in the manner specified. However, this completion permits the ST author claiming compliance to the PP to add to those requirements, provided it is in a restrictive manner. i.e. the additional requirements cannot weaken the existing requirements.

Demonstrable conformance allows a PP author to describe a common security problem to be solved and generic guidelines to the requirements necessary for its resolution, in the knowledge that there is likely to be more than some way of specifying a resolution.

By the time that CC version 3.1 was published in 2006, the notion of exact conformance had disappeared from the standard. So, this initial appearance of “Exact conformance” was with us for less than a year.

In 2012, a vision statement was published by the CC management committee. This introduced the idea of promoting the use of PPs, and evolved the PP development notion to include all stakeholders. (Previously most PPs were written by groups dominated by developers.)

Recently, in May 2017, proposed addenda to CC 3.1 R5 for exact conformance were published. This reflects the de-facto situation that exact conformance is specified in several PPs and in the cPPs defined in accordance with the CCRA of 2014.

This next chart shows the percentage of CC evaluations claiming conformance to a PP.

So, over the years the following types of PP conformance claims have existed.

  1. OPEN: An assurance claim (usually) on the Evaluation Assurance Level (EAL) scale is made, but the security functionality claimed by the TOE is open, no PP claims are made. Assurance consumers must be CC experts to navigate the claims. The specification of the ST is typically performed directly by the developer.
  2. NO CONF CLAIM: A PP is claimed but no statement in regard to the type of conformance to the PP is made. This is typically applicable to evaluations before CC version 3 was applicable.
  3. DEMONSTRABLE: A PP is claimed, as well as an assurance claim, but the security functionality claimed is variable. Assurance consumers must be expert to navigate any additional augmentation claims, understanding boundary restrictions, and also in understanding the rationale in regard to why something is equivalent to what was specified. The specification of the PP is typically developer led.
  4. STRICT: A PP is claimed; the security functionality includes a minimum set defined in the PP. Assurance consumers must be expert to navigate any additional augmentation claims, understanding boundary restrictions. The specification of the PP is typically developer led.
  5. EXACT: A PP is claimed that specifies the security functionality, as well as an appropriate assurance claim. The boundary of the evaluation is set. Assurance consumers can rely on a certification without much CC Expertise. The specification of the PP is typically led by the assurance consumer.

The following chart shows the percentage of each of these types of evaluation.

The chart shows that the evaluations performed in conformance with a PP have grown from less than 5% to over 70% over the last ten years. In 2012 when the vision statement was published the number of evaluations with a PP claim was around 50%, today we are approaching 75%.

Even though the notion of exact conformance has only just been formally published, some schemes have been promulgating exact conformance since 2011, and supported the development of PPs that specified this adaptation of strict conformance. These exact conformance evaluations now represent around 30% of the total evaluations performed.

The next life-stage for security criteria

There is much evidence that the CCRA has been a success, and continues to evolve to meet the needs of its stakeholders. Since the CCRA and the Common Criteria were established by nations who had already evolved security criteria (ITSEC, CTCPEC and TCSEC, aka the Orange Book), there has been a lot of change. With post cold war co-operation in the ‘90s, and greater reliance on commercial off the shelf products, the establishment of a device such as the CCRA was a great step forward. We should note that since then the reliance on COTS technology has increased and that the development of information technology has occurred over the last twenty years with exponential growth. This has brought new and more sophisticated threats to the table. The response to this proliferation of threats at national and regional levels is not completely uniform and is at varying levels of maturity.

For example, most nations have traditionally focused on the threats to government systems, with the original criteria and the Common Criteria standards developed by government agencies. Most nations now agree that the threats presented to their national infrastructures are critical in nature and must also be addressed, while the number of participants who have cybersecurity responsibilities are vast. A huge amount of effort has been focused on that in the last decade. Of course, this must go far beyond product evaluations, but these product evaluations are still a piece of the puzzle.

These “differences” have so far been accommodated using the deliberately flexible Common Criteria standards. A prime example being the emergence of the Senior Official Group-Information Security (SOG-IS) agreement, which addresses the European region’s directives and common goals.

The signatories to the CCRA have grown over the years, and today some twenty-eight nations subscribe to the Arrangement, with the latest participant being added in June (welcome to Ethiopia!) Truly, a recognition of the success of the Common Criteria in providing assurance in the security functionality of many ubiquitous IT products, is that it can be recognized by nations that do not have the resources of some others. However, the CCRA and its signatories are only part of the story. As nations develop cybersecurity strategies appropriate to their needs we observe some divergence in the application of the Common Criteria. To date, this divergence is reflected in the specification of the conformance-type to a PP, and the development of PPs applicable not just to technology type, but also addressing the needs of the various cybersecurity strategies.

The need for public-private collaboration has come to the fore, and the Common Criteria standards must develop appropriately. With this in minds, ISO will take a much greater role in the future development of the standards. The close liaison with the Common Criteria Development Board (CCDB) will continue, but ISO affords much greater opportunity for non CCRA nations and sectors outside the government-sector to be involved. The standards should allow all stakeholders, including those with differing use-cases for Common Criteria, to take an active role in their development.

For example, it may be appropriate that some sectors develop protection profiles that meet their own needs, perhaps set up their own “private” validation schemes, and even negotiate recognition arrangements appropriate to their sector.

In conclusion, the evaluation and testing of IT security products has evolved within the government sector over the last two decades, from the days of the Orange book, the number of evaluations performed each year has grown from a handful to over four hundred. We see differing use-cases for the standards, developing, not just within the government sector, but by other sectors, and we see different assurance needs for differing technologies. The next few years should be very interesting in terms of the development and use of the standards for product security evaluations and testing especially in keeping the standards flexible, finding the common denominators, enabling the needed use-cases and allowing for the development of meaningful mutual recognition.