Purpose
The purpose of this statement is to criticize the following statements in relation to the fact that a team led by the author (hereinafter, the “Vulnerability Finders”) discovered and disclosed a vulnerability (hereinafter, the “Vulnerability”) in the FeliCa RC-S915 manufactured by Sony Corporation (hereinafter, the “Product Developer”) (hereinafter, the “Product”; and the family of FeliCa Standard products is hereinafter, the “Product Family”), whereby the key of an arbitrary node can be identified.
- A statement by the Product Developer titled “Regarding Reports of a Vulnerability in Certain FeliCa IC Chips Shipped Before 2017” (https://www.sony.co.jp/Products/felica/business/information/2025001.html; hereinafter, “Statement A”).
- A joint statement by the Ministry of Economy, Trade and Industry, the Information-technology Promotion Agency, Japan (hereinafter, “IPA”), the Japan Computer Emergency Response Team Coordination Center (hereinafter, “JPCERT/CC”), and the National Cybersecurity Office titled “Request Regarding Actions in Accordance with the Information Security Early Warning Partnership Guidelines” (https://www.ipa.go.jp/security/renkei/rk20250909.html; hereinafter, “Statement B”).
Background
On June 13, 2025, the Vulnerability Finders discovered the Vulnerability in the Product.
On July 24, 2025, the Vulnerability Finders submitted information related to the Vulnerability to IPA.
On August 22, 2025, IPA informed the Vulnerability Finders that it had accepted the Vulnerability-related information on July 24, 2025 and had set that date as the starting date, and that the Product Developer wished to contact the Vulnerability Finders directly. Thereafter, coordination regarding the Vulnerability was conducted between the Vulnerability Finders and the Product Developer with the involvement of IPA and JPCERT/CC.
On August 28, 2025, Kyodo News (hereinafter, “Kyodo News”) distributed the first report. The Product Developer issued Statement A.
On September 9, 2025, the Ministry of Economy, Trade and Industry, IPA, JPCERT/CC, and the National Cybersecurity Office jointly issued Statement B.
The Product
The Product is a contactless IC card that uses the Data Encryption Standard (hereinafter, “DES”; a 56-bit key) to encrypt communications. There is also information suggesting that Triple DES is used in some cases, but this pertains to the mutual authentication algorithm between the card and the card reader. Note that DES can be broken by brute-force attack even with computing resources that an individual can procure today.
Reasons for Disclosing the Vulnerability
Systems affected by the Vulnerability are those that meet the following condition:
- The Product has been operated within the system at least once.
Mitigation of the Vulnerability is extremely difficult for the following reasons:
- The node key identified through the Vulnerability is shared, within the same system, with other products in the Product Family besides the Product.
- Even if the node key stored in the Product Family is updated, the specifications allow its value to be determined externally.
To mitigate the Vulnerability in affected systems, there is no choice but to stop using the DES scheme; in other words, the only countermeasure is to discontinue use of products within the Product Family that use DES. For this reason, the Vulnerability Finders considered it necessary to disclose the existence of the Vulnerability at an early stage so that many users could decide to discontinue use of the Product Family.
Additionally, we understand that the Product Developer and Kyodo News coordinated the timing of disclosure behind the scenes, and ultimately reached an agreement to disclose the information after 17:00 on August 28, 2025.
Reflection by the Vulnerability Finders
At the time of disclosure of the Vulnerability, we should also have clearly stated the reasons for early disclosure.
Criticism of Statement A
On August 28, 2025, the Product Developer issued Statement A and asserted the following:
- The security of services that use FeliCa is built at the level of the overall system for each service, in addition to the security of the FeliCa IC chip.
- Based on information from relevant business operators, services can continue to be used with confidence.
What the Finders take issue with is not the former point itself, but rather that the latter conclusion—“can continue to be used with confidence”—is not explained in terms of what assumptions or what threat model it is based on.
If the intent is, for example, “the system can detect it” or “it can be compensated for by human guards and operational measures,” that is a claim along the lines of “even if damage occurs, it can be discovered afterward,” or “it can be covered by other means.” This is not sufficient as an explanation of the “high security” that end users expect (https://www.sony.co.jp/Products/felica/about/). Even if ex post verification is possible, businesses can still incur losses in contexts such as electronic money. And if the authenticity of entry/exit is dependent on human checks, the very purpose of introducing an IC card system is undermined. The Product Developer should not merely tout reassurance and safety in words, but should inform end users of realistic threats.
Criticism of Statement B
On September 9, 2025, the Ministry of Economy, Trade and Industry, IPA, JPCERT/CC, and the National Cybersecurity Office jointly issued Statement B and asserted the following:
- Unless there is a legitimate reason, do not disclose vulnerability-related information to third parties.
- Media organizations and other industry actors should not recklessly disclose vulnerability-related information prior to public announcement to third parties through reporting, social media posts, or other means.
Request That Finders Refrain From Disclosure
Although Statement B does not explicitly mention the Vulnerability-related information at issue here, given the timing of its issuance, it is difficult to avoid the public associating it with this matter. First, the Vulnerability Finders assert that they have a “legitimate reason,” as described in “Reasons for Disclosing the Vulnerability.”
Next, we criticize the issuance of such a statement. On the internet, some people appear to treat the “request that finders refrain from disclosure” in the Information Security Early Warning Partnership Guidelines as absolute and akin to a law, but this is clearly incorrect. As the term indicates, it is a request and does not bind vulnerability finders. Nevertheless, issuing such a statement simply because vulnerability finders acted contrary to the request is unjust.
Moreover, at the time of submitting the Vulnerability information, IPA had already been notified that information about the existence of the Vulnerability had been provided to the media. If there was any objection, IPA should have raised it directly with the reporter of the Vulnerability. Alternatively, it could have refused to accept the submission.
IPA’s Negligence
IPA accepted the Vulnerability-related information on July 24, 2025 and set that date as the starting date. In addition, the Product Developer notified JPCERT/CC in early August 2025 that it had technically confirmed the Vulnerability. Despite this, IPA did not contact the Vulnerability Finders at all until August 22, 2025. This is unacceptable for the Finders.
The issuance of Statement B, as a result, led to online backlash against the Vulnerability Finders. With such a precedent, who would want to report vulnerabilities to IPA? The issuance of Statement B did not serve anyone’s interests.
Measures the Product Developer Should Take
As stated in “Reasons for Disclosing the Vulnerability,” the only countermeasure is to discontinue use of products in the Product Family that use DES. Within the Product Family, in addition to those using DES encryption, there are products using the Advanced Encryption Standard. Replacing existing systems with these is the measure the Product Developer should take. Meanwhile, according to some information, the Product Developer will not bear the costs for this. In other words, end users are being told to implement countermeasures at their own responsibility and expense. If a policy of fully passing migration costs on to users is indeed true, the barrier to mitigation for end users will rise, and as a result, overall security improvements will not progress. The Product Developer is requested to present at least the following, at a level of detail that enables end users to make decisions:
- Clarification of the scope of impact (which products and which configurations are affected)
- Migration guidance (deadlines, recommended procedures, compatibility, etc.)
- An explanation of the approach to cost burden and support measures
コメントを残す