JISEC-C0858 was developed by Japan Agency for Local Authority Information Systems (J-LIS), evaluated by ECSEC Laboratory, an Evaluation Facility in Japan, and certified by JISEC, CC Certification Body in Japan.
From the document property of the PP, the name of document writer can be identified:
Here the same name can be identified as one of members of the Evaluation Facility:
This is evidence that impartiality has been compromised.
Following use cases of Personal Number Cards are not documented:
- Using Personal Number Cards as Driving License cards.
- Integrating Personal Number Card functionality into Smartphone.
It is regrettable that these important use cases were not addressed, despite the long evaluation period as pointed out later.
Also it is unclear whether sufficient countermeasures are being taken to address the attack scenarios associated with above use cases.
From its Certification Report, the evaluation of the PP was started from September 2024, and ended in September 2025. Two observation reports were issued on June and July 2025, which is at least 9 months after the evaluation started. From this information, we cannot see a sign of a willingness to resolve issues early on. It seems evaluators don't even recognize a problem as a problem until someone points it out.
From Table 4-1, AES-192 is seleted for encryption/decryption, and CMAC generation/verification.
On the other hand, NIAP, US Certification Body, released Commercial National Security Algorithm Suite 2.0, and AES-256 is included but AES-192 is not included.
Taking into account that J-LIS took more than a decade to revise a Personal Number Cards Protection Profile, there is concern that the selected cryptographic algorithm may be compromised before new protection profile comes out.
The functional component FIA_SOS.2 is used to generate a nonce based on A.3.1, A.3.2, or A.3.3 of FIPS 186-5.
To be more precise, FIPS 186-5 does not use the term nonce in A.3.1, A.3.2, nor A.3.3.
A.3.1, A.3.2, and A.3.3 of FIPS 186-5 generate a per-message secret, which will is equally valuable as cryptographic key.
Here FIA family is for Identification and Authentication, while nonce or per-message secret is not for Identification and Authentication, but for cryptographic security.
Therefore, it is inappropriate to use FIA_SOS.2 for per-message secret generation.
The functional component FCS_CKM.2 is used to perform ECDH key agreement. Here, in E.3.2.2 of CC:2022 Part 2, "cryptographic key agreement" is mentioned as an operation of FCS_COP.1.1. Based on this description, another functional component FCS_COP.1 should be used instead.
Note here that the description of FCS_CKM.2 before refinement does not explain how to distribute cryptographic keys. Good refinement example of FCS_CKM.2 can be found in Cryptographic Modules, Security Level "Low", Version 1.0.
Based on ISO 7816 standards, IC chips do not initiate communication with an interface device (IFD, for example: IC card reader), because IC chips normally respond to request APDU (Application Protocol Data Unit) sent from the IFD, but do not normally send a APDU spontaneously.
FTP_ITC.1 is introduced in the PP to support secure messaging, and the original description of FTP_ITC.1.3 is The TSF shall initiate communication ....
Here, the word initiate is not appropriate taking into account the above technological limitations.
Experienced ST developers have editorially refined FTP_ITC.1.3 so as to state The TSF shall enforce communication ... for supporting secure messaging in IC chip context, and the refinement is deemed more appropriate than using word initiate.
We can find two occurrences of Per-massage secret within Note to Table 6-1 and FIA_SOS.2.2.
💆 🤫
These are obvious typographical errors.
Note here that FIPS 186-5 uses the term Per-message secret.
Here, let us imagine QWERTY keyboards. Keys e and a are not next to each other.
Therefore these typographical errors are not caused by mistake, but by intention.
We can find the followin description in FCS_CKM.6.2:
For volatile memory, the disposal method for cryptography may include cutting off power to the volatile memory.
Here, in the main body of FCS_CKM.6.1, cryptographic key destruction method is mentioned.
Therefore, disposal method for cryptography should be written as cryptographic key destruction method.
The document ID of CC:2022 Part 5 should be CCMB-2022-11-005, however, it is written as CCMB-2022-11-004.
It will be technically required to distingush Version 2 Personal Number Cards from Version 1 Personal Number Cards, because the Application Protocol Data Unit (APDU) for Version 2 Personal Number Cards seems to be different from that for Version 1.
FIA_UAU.1 and FIA_UID.1 are refined from previous PP, and in the first row of Table 6-4, Select ISD, SSD, AP is included.
From the above, it is assumed that information read out from ISD, SSD, and/or AP is different between Version 2 Personal Number Cards from Version 1 Personal Number Cards.
Recently the English version of the PP was released.
We identified multiple silent changes in the English version without correcting the original Japanese version, as shown below:
Two occurrences of per-massage secret have been replaced to as per-message secret in Table 6-1 and FIA_SOS.2.2.
The document ID of CC:2022 Part 5 has been replaced to as CCMB-2022-11-005.
In the third bullet under Section 6.1, it is stated that mincho-font is used to express refinements, in the original Japanese version.
However, in the English version, it is stated that italic and bold is used to express refinements.
It is not faithful translation, and therefore will be regarded as violation to the scheme requirements in CCM-02-A.
Careful PP authors (and consultants) would have drafted Japanese expressions which can be translated smoothly into English,
as it does not make sense to explain mincho-font for readers of the English version.
FCS_CKM.5 refers session keys, plural form.
On the other hand, 6.3.1 refers the session key in singular form, without specifying the preceding singular session key.
We know that Japanese language often does not distinguish between singular and plural forms. Therefore translators should translate texts into English while taking into account the fact.
The singular form will do harm when interpreting cryptographic key destruction FCS_CKM.6. Readers of the PP may read that only a single session key has to be zeroized, in spite of the fact that multiple session keys have to be zeroized.