Sie sind auf Seite 1von 480

DeutscherMAT A BSI-1-6c_3.

pdf, Blatt 1
Bundestag
Eundasministarium 1. Untersuchungsausschuss
# der 18. Wahlperiode
I MArA &t- l/6c-Z
zu A-Drs.: +
POSTANSCHRIFT Bundesministeriumdeslnnem,'l1014Berlin

HAUSANSCHRIFI Alt-Moabit 101 D, 10559 Berlin


POSTANSCHRIFT 110'14 Berlin
1. Untersuchungsausschuss 18. WP
TEL +49(0)30 18 681-1096
Herrn MinR Harald Georgii
FAX +49(0)30 18 681-51096
Leiter Sekretariat BEARBEIIET VON Thomas Matthes
Deutscher Bundestag
Thomas.Matthes@bmi,bund.de
Platz der Republik 1 E-MAIL

INIERNET www.bmi.bund.de
11011 Berlin DIENSTSITZ Berlin
DATUM 15.09.2014
AZ PG UA-2OOO1
Bundestag
1. Untersuchungsausschuss

I t Sep.
BETREFF 1. Untersuchungsausschuss der 18. Legislaturperiode
HIER Beweisbeschluss BSI-1 vom 10. April 2014
ANLAGEN 24 Aktenordner VS-NfD. 5 Aktenordner offen. 7 Aktenordner VS-VERTRAULICH,

Sehr geehrter Herr Georgii,


in Erfüllung Beweisbeschluss BSI-1 übersende ich lhnen die oben aufgeführten Un-
terlagen.
ln den übersandten Aktenordnern wurden Schwärzungen oder Entnahmen mit fo!-
genden Begründungen durchgeführt:
o Schutz Mitarbeiterinnen und Mitarbeiter deutscher Nachrichtendienste,
o Schutz Grundrechter Dritter und
. Fehlender Sachzusammenhang zum Untersuchungsauftrag.
Die einzelnen Begründungen bitte ich den in den Aktenordnern befindlichen lnhalts-
verzeichnissen und Begründungsblättern zu entnehmen.
Soweit der übersandte Aktenbestand vereinzelt lnformationen enthält, die nicht den
Untersuchungsgegenstand betreffen, erfolgt die Übersendung ohne Anerkennung
einer Rechtspflicht.
Auf Basis der mir vom Bundesamt für Sicherheit in der lnformationstechnik vorlie-
genden Erklärung versichere ich die Vollstängjgbe!! d"r .r, B"*"irb"r.h!ffi
vorgelegten Unterlagen nach bestem Wissen und Gewissen.

Mit freundlichen Grüßen


lm A1ftrag

ZUSTELL- UND LIEFERANSCHRIFI Alt-Moabit 101 D, 10559 Berlin

VERKEHRSANBINDUNG S-Bahnhof Bellevue; U-Bahnhof Turmstraße

Bushalteslello Kleiner Tiergaden


MAT A BSI-1-6c_3.pdf, Blatt 2

Titelblatt

Ressort Bonn, den

BMI / BSI 08.08.2014

Ordner

16

Aktenvorlage
an den
1. Untersuchungsaussch uss

des Deutschen Bundestages in der 18.SrP

gemäß Beweisbeschluss:

BSr-1 I 10.04.2014

Aktenzeichen bei aktenführender Stelle:

VS-Einstufung:

lnhalt:

[schlagwoftaftig Kurzbezeichnung d. Akteninhalts]

ierunq SmartCards

Bemerkungen:

Dieser Ordner enthält Schwärzunoen.


MAT A BSI-1-6c_3.pdf, Blatt 3

lnhaltsvezeichnis

Ressort Bonn, den

BMI / BSI 08.08.2014

Ordner

16

lnhaltsübersicht
zu den vom 1. Untersuchungsausschuss der
{ 8. Wahlperiode beigezogenen Akten

des/der: ReferaUOrgan isationseinhe it:

BSt-1 I S2

Aktenzeichen bei aktenführender Stelle:

VS-Einstufung:

Blatt Zeitraum I n ha lVGegenstand [stichwo rta rtig] Bemerkungen

0001 23.08.2013 - RSA-Schlüssel in Bürgerkarte Taiwan - DR[-N, DRI-U


t7.09.2013 Analyse der in der Presse berichten Schwärzungen enthalten auf
0475 Sicherheitsprobleme bei der den Seiten:
Taiwanischen Bürgerkarte 13 4- 13 5,137 -13 8,1 40,1 42-
I 57,1 59 -l 60,1 69 -17 2,77 4 -
1 78, 1 8 1, 1 99 -202,220,228-

230,248,273,239,305-
308,310,312-313
DRI-N:
Schwärzungen enthalten auf
den Seiten: 139
DRI-U:
Schwtirzungen enthalten auf
den Seiten: 150
MAT A BSI-1-6c_3.pdf, Blatt 4

Anlage zum lnhaltsverzeichnis

Ressort Berlin, den

BMI / BSI 08.08.2014

16

Abkürzung Beqründunq
DRI.N Namen von externen Dritten:

Namen von externen Dritten wurden unter dem Gesichtspunkt des


Persönlichkeitsschutzes unkenntlich gemacht. lm Rahmen einer
Einzelfallprüfung wurde das nformationsinteresse des Ausschusses mit
!

den Persönlichkeitsrechten des Betroffenen abgewogen. Das


Bundesministerium des !nnern ist dabei zur Einschätzung gelangt, dass
die Kenntnis des Namens für eine Aufklärung nicht erforderlich
erscheint und den Persönlichkeitsrechten des Betroffenen im
vorliegenden Fall daher der Vorzug einzuräumen ist.
Sollte sich im weiteren Verlauf herausstellen, dass nach Auffassung des
Ausschusses die Kenntnis des Namens einer Person doch erforderlich
erscheint, so wird das Bundesministerium des lnnern in jedem Einzelfall
prüfen, ob eine weitergehende Offenlegung möglich erscheint.

DR!.U Namen von Unternehmen:

Die Namen von Unternehmen sowie Markennamen und Firmenlogos


wurden unkenntlich gemacht. lm Rahmen einer Einzelfallprüfung
wurden das Informationsinteresse des Ausschusses einerseits und das
Recht des Unternehmens unter dem Schutz des eingerichteten und
ausgeü bten Gewerbebetriebs andererseits gegeneinander abgewogen.
Hierbeiwurde zum einen berücksichtigt, inwieweit der Name des
Unternehmens ggf. als relevant für die Aufklärungsinteressen des
U ntersuch u ngsausschusses erscheint. Zum anderen wu rde

berücksichtiqt. dass die Namensnennunq oeoenüber einer nicht


MAT A BSI-1-6c_3.pdf, Blatt 5

kontrol ierbaren Öffentlich keit den Bestandssch utz des


I U nternehmens,
deren Wettbewerbs- und wirtschaftliche Überlebensfähigkeit gefährden
könnte.
Sollten sich im weiteren Verlauf herausstellen, dass aufgrund eines
konkreten zum gegenwärtigen Zeitpunkt für das Bundesamt für
Sicherheit in der lnformationstechnik noch nicht absehbaren
lnformationsinteresses des Ausschusses an dem Namen eines
Unternehmens dessen Offenlegung gewünscht wird, so wird das
Bundesamt für Sicherheit in der lnformationstechnik in jedem Einzelfall
prüfen, ob eine weitergehende Offenlegung möglich erscheint.

o
MAT A BSI-1-6c_3.pdf, Blatt 6

tssf,- Certification Repoof,o'


u-6\
t

Federal Office for lnformation Security

BSI-DSZ-CC -0212-2004

for

Renesas AE 45C1 (HD651 45C1 )


Smartcard Integrated Circuit
Version 01

o from

Renesas Tech nology Corp.


MAT A BSI-1-6c_3.pdf, Blatt 7

0002

B9'J - Bundesamt für Sicherheit in der lnformationstechnik, Postfach 20 03 63, D-53133 Bonn

Telefon +49228 9582-0, Infoline +49228 9582-111, Telefax +49228 9582-455


MAT A BSI-1-6c_3.pdf, Blatt 8

0003

Bundesamt für Sbherheit


ln der lniormatlongbchnlk

BSt-DSZ-CC-0212-2004
II
Renesas AE45C1 (HD65l45Cl )
Smartcard lntegrated Gircuit
Version 01
from
Renesas Technology Gorp. SOGIS-MRA

The lT product identified in this certificate has been evaluated at an accredited and licensed/
approved evaluation facility using the Common Methodology for lT Security Evaluation, Part 1
Version 0.6, Part 2 Version 7.0 extended by advice of the Certification Body for components
beyond EAL4 and smart card specific guidance, for conformance to the Common Criteia for lT
Security Evaluation, Version 2.1 (lSO/lEC 15408: 1999).

Evaluation Results:
PPConformance: ProtectionProfileBS|-PP-0002-2001
Functionality: BSI -P P-000 2-2001 conformant plus prod uct specif ic extensions
Common Criteria Part2 extended
Assurance Package: Gommon Criteria Part 3 conformant
EAL4 augmented by:
ADV_IMP.2 (Development - lmplementation of the TSF)
ALC_DVS.2 (Life cycle support - Sufficiency of security measures),
AVA_MSU.3 (Vulnerability assessment - Analysis and testing for insecure
states),
AVA_VLA.4 (Vulnerability assessment - Highly resistant)
This certificate applies only to the specific version and release of the product in its evaluated
configuration and in conjunction with the complete Certification Report.
The evaluation has been conducted in accordance with the provisions of the certification scheme
of the Federal Office for lnformation Security and the conclusions of the evaluation facility in the
evaluation technical report are consistent with the evidence adduced.
The notes mentioned on the reverse side are part of this certificate.

Bonn, I January 2004


The President of the Federal Office
for lnformation Security

Dr. Helmbrecht L.S.


Bundesamt fär Sicherheit in der lnformationstechnik
Godesberger Allee '185-189 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn
Telefon (0228) 9582-0 - Telefax (0228) 9582455 - lnfoline (0228) 9582-1 1 1
MAT A BSI-1-6c_3.pdf, Blatt 9

0004

The rating of the strength of functions does not include the cryptoalgorithms suitable for encryption
and decryption (see BSIG Section 4,.Para. 3, Clause 2)

This certificate is not an endorsement of the lT product by the Federal Offie for lnformation
Security or any other organisation that recognises or gives effect to this certifioate, and no warranty
of the lT product by Federal Office for lnformation Security or any other organisation that
recognises or gives effect to this certificate, is either expres§ed or implied.
MAT A BSI-1-6c_3.pdf, Blatt 10

BSt-DSZ-CC-0212-2004 CertificationReport
0 00 5

Preliminary Remarks

Under the BSIG1 Act, the Federal Office for lnformation Security (BSI) has the
task of issuing certificates for information technology products.
Certification of a product is carried out on the instigation of the vendor or a
distributor, hereinafter called the sponsor.

A part of the procedure is the technical examinatiorl (evaluation) of the product


according to the security criteria published by the BSI or generally recognised
security criteria.

The evaluation is normally carried out by an evaluation facility recognised by the


BSI or by BSI itself.

The result of the certification procedure is the present Certification Report. This
report contains among others the certificate (summarised assessment) and the
detailed Certification Results.

The Certification Results contain the technical description of the security


functionality of the certified product, the details of the evaluation (strength and
weaknesses) and instructions for the user.

Act setting up the Federal Office for lnformation Security (BSl-Errichtungsgesetz, BSIG) of
17 December 1990, Bundesgesetzblatt I p. 2834

V
MAT A BSI-1-6c_3.pdf, Blatt 11

Certification Report BSt-DSZ-CC-0212-2004


0006

Contents
Part A: Certification
Part B: Certification Results
Part C: Excerpts from the Criteria

VI
MAT A BSI-1-6c_3.pdf, Blatt 12

BSI-DSZ-CC.0212-2004 certificationReport
0 00 7

A Gertification

1 Specifications of the Certification Procedure

The certification body conducts the procedure according to the criteria laid down
in the following:

. BSIG2

. BSI Certification Ordinance3


. BSI Schedule of Costsa
. Special decrees issued by the Bundesministerium des lnnern (Federal
Ministry of the lnterior)
. DIN EN 45011 standard

. BSI certification: Procedural Description (BSl 7125)


. Common Criteria for lT Security Evaluation (CC), Version 2.15
. Common Methodology for IT Security Evaluation (CEM)
- Part 1, Version 0.6
Part2, Version 1.0
. BSI certification: Application Notes and lnterpretation of the Scheme
(Ars)
. Advice from the Certification Body on methodology for assurance
components above EAL4

' Act setting up the Federal Office for lnformation Security (BSl-Errichtungsgesetz, BSIG) of
17 December 1990, Bundesgesetzblatt I p.2834
t Ordinance on the Procedure for lssuance of a Certificate by the Federal Office for
lnformation Security (BSl-Zertifizierungsverordnung, BSlZertV) of 7 July 1992,
Bundesgesetzblatt I p. 1230
t Schedule of Cost for Official Procedures of the Federal Office for lnformation Security (BSl-
Kostenverordnung, BSI-KostV) of 29th October 1992, Bundesgesetzblatt I p. 1838
5 Proclamation of the Bundesministerium des lnnern of 22nd September 2000 in the
Bundesanzeiger p. 19445

A-1
MAT A BSI-1-6c_3.pdf, Blatt 13

Certification Report BSr-DSZ-CC-0212-2004


0008

Recognition Ag reements

ln order to avoid multiple certification of the same product in different countries


a mutual recognition of lT security certificates - as far as such certificates are
based on ITSEC or CC - under certain conditions was agreed.

2.1 ITSEC/CC - Certificates

The SOGIS-Agreement on the mutual recognition of certificates based on


ITSEC. became effective on 3 March 1998. This agreement was signed by the
national bodies of Finland, France, Germany, Greece, ltaly, The Netherlands,
Nonrvay, Portugal, Spain, Sweden, Switzerland and the United Kingdom. This
agreement on the mutual recognition of lT security certificates was extended to
include certificates based on the CC for all evaluation levels (EAL 1 - EAL 7).

2.2 CC - Certificates

An arrangement (Common Criteria Arrangement) on the mutual recognition of


certificates based on the CC evaluation assurance levels up to and including
EAL 4 was signed in May 2000. lt includes also the recognition of Protection
Profiles based on the CC. The arrangement was signed by the national bodies
of Australia, Canada, Finland France, Germany, Greece, ltaly, The Netherlands,
New Zealand, Nonnray, Spain, United Kingdom and the United States. lsrael
joined the arrangement in November 2000, Sweden in February 2002, Austria
in November 2OO2, Hungary and Turkey in September 2003, Japan in
November 2003.

A-2
MAT A BSI-1-6c_3.pdf, Blatt 14

BSt-DSZ-CC-0212-2004 Certification Report

0009

Performance of Evaluation and Certification

The certification body monitors.each individual evaluation to ensure a uniform


procedure, a uniform interpretation of the criteria and uniform ratings.
The product Renesas AE45C1 (HD65145C1) Smartcard lntegrated Circuit
Version 01 with lC manufacturer's lD number 2110 for Kofu (Japan) has
undergone the certification procedure at B$1.
The evaluation of the product Renesas AE45C1 (HD65145C1) Smartcard
lntegrated Circuit Vers.ion 01 was conducted by T-Systems GEI GmbH. The
eval-uation facility of T-Systems GEI GmbH is an evaluation facility (ITSEF)6
recognised by BSl.
The sponsor, vendor and distributor is Renesas Technology Corp.. Point of
contact for this certification procedure was Renesas Technology Europe Ltd.,
Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire SL8 5FH, U.K.
Potential users of this product should note that Hitachi's Smart Card lC
business was transferred to Renesas Technology Corp. during this evaluation
and certification process. lt was verified that there were no new security issues
as a result of this change.
The certification is concluded with
o the comparability check and
. the production of this Certification Report.
This work was completed by the BSI on 8 January 2004.

The confirmed assurance package is only valid on the condition that


o all stipulations regarding generation, configuration and operation, as
given in the following report, are observed,
. the product is operated in the environment described, where specified in
the following report.
This Certification Report only applies to the version of the product indicated
here. The validity can be extended to new versions and releases of the product,
provided the sponsor applies for re-certification of the modified product, in
accordance with the procedural requirements, and the evaluation does not
reveal any security deficiencies.
For the meaning of the assurance levels and the confirmed strength of
functions, please refer to the excerpts from the criteria at the end of the
Certification Report.

u lnformation Technology Security Evaluation Facility

A-3
MAT A BSI-1-6c_3.pdf, Blatt 15

Certification Report BSl-DSZ-CC-0212-2004

0010

Publication

The following Certification Results contain pages B-1 to B-20.

The product Renesas AE45C1 (HD65145C1) Smartcard lntegrated Circuit


Version 01 has been included in the BSI list of the certified products, which is
published regularly (see also lnternet: http://www.bsi.bund.de). Further
information can be obtained from BS!-lnfoline +49 22ß19582-111.

Further copies of this Certification Report can be requested from the vendo/ of
the product. The Certification Report can also be downloaded from the above-
mentioned website,

' Renesas Technology Corp. 5-20-1, Jousuihon-cho, Kodaira-shi, Tokyo, 187-8588, Japan

A-4
MAT A BSI-1-6c_3.pdf, Blatt 16

BSt-DSZ-CC-0212-2004 Certification Report


0011

B Certification Results

The following results represent a summary of


. the security target of the sponsor for the target of evaluation,
. the relevant evaluation results from the evaluation facility, and
. complementary notes and stipulations of the certification body.

B-1
MAT A BSI-1-6c_3.pdf, Blatt 17

Certification Report BSt-DSZ-cC-0212-2004


0012

Gontents of the certification results

1 Executive Summary 3

2 ldentification of the TOE I


3 Security Policy 10

4 Assumptions and Clarification of Scope 10

5 Architectural lnformation 11

6 Documentation 12

7 lT Product Testing 12

I Evaluated Configuration 13

9 Results of the Evaluation 13

10 Evaluator Comments/Recommendations 15

11 Annexes 16
12 Security Target 16
13 Definitions 16

14 Bibliography 18

B-2
MAT A BSI-1-6c_3.pdf, Blatt 18

BSt-DSZ-CC-0212-2004 Certification Report


0013

{ Executive Summary
The Target of Evaluation (TOE) is the "Renesas AE45C1 (HD65145C1)
Smartcard lntegrated Circuit Version 01. with lC manufacturer's lD number
2110 for Kofu (Japan). lt provides a hardware platform for a smart card to run
smart card applications executed by a smart card operating system.
The TOE is composed of a processing unit, system control logic, security logic,
watchdog timer, firewall management unit, UART, two l/O lines, volatile or non-
volatile memories (6 KBytes RAM, 196 KBytes User ROM, 32 KBytes +
4 KBytes EEPROM), a DES co-processor, a random number generator (RNG),
modular multiplication coprocessor and two interval timer. The TOE also
includes Renesas proprietary lC Dedicated Software stored on the chip and
used for testing purposes during production only. lt does not provide additional
services in the operational phase of the TOE. Additionally, the listing of a RNG
On-line Test Software is delivered as part of the TOE and should be included in
the users embedded software as outlined in the guidance [11]. The smart card
operating system and the application stored in the User ROM and in the
EEPROM are not part of the TOE.
The TOE is embedded in a micro-module or another sealed package. The
micro-modules are embedded into a credit card sized plastic card.
The EEPROM part of the TOE provides an ideal platform for applications
requiring non-volatile data storage. The TOE is intended for use in a range of
high security applications, including high speed security authentication, data
encryption or electronic signature. Several security features independently
implemented in hardware or controlled by software will be provided to ensure
proper operations and integrity and confidentiality of stored data. This includes
for example measures for memory protection, leakage protection and sensors
to allow operations only under specified conditions.
The Security Target is written using the Smartcard lC Platform Protection
Profile, Version 1.0 (BS|-PP-0002-2001) tgl. With reference to this Protection
Profile, the smart card product life cycle is described in 7 phases. The
development, production and operational user environment are described and
referenced to these phases. TOE delivery is defined at the end of phase 3 or
phase 4.
The assumptions, threats and objectives defined in this Protection Profile [9] are
used. To address additional security features of the TOE (e.g cryptographic
services), the security environment as outlined in the PP [9] is augmented by an
additional policy, threats, a'ssumptions and security objectives accordingly.
The TOE Security Functional Requirements (SFR) selected in the Security
Target are Common Criteria Parl2 extended as shown in the following tables.

B-3
MAT A BSI-1-6c_3.pdf, Blatt 19

Certification Report BSt-DSZ-CC-0212-2004


0014

The following SFRs are taken from CC part2:


Security Source
Functional ldentifier from PP or
Requirement added in ST
FCS Cryptographic support
FCS_COP.1 Cryptog raphic operation ST
FDP User data protection
FDP IFC.1 Subset information overflow control PP
FDP 1TT.1 Basic internal transfer protection PP
FDP-ACC.1 Subset access control [Controlled-Register ST
ICRP] Policyl
FDP_ACC.1 Subset access control [Write-Protect Policy] ST
twPPI
FPT Protection of the TOE Security Functions
FPT FLS.1 Failure with preservation of secure state PP
FPT_ITT.1 Basic internalTSF data transfer protection PP
FPT PHP.3 Resistance to physical attack PP
FPT SEP.1 TSF domain separation PP
FRU Resource utilisation
FRU FLT.2 Limited fault tolerance PP

Table '1: SFRs taken from CC Part 2


The following CC parl2 extended SFRs are defined:
Security Source
Functional !dentifier from PP or
Requirement added in ST
FAU Security Audit
FAU-SAS.1 Audit storage PP
FCS Cryptographic support
FCS RND.1 Quality metric for random numbers PP
FMT Security management
FMT LIM.1 Limited capabilities PP
FMT_LIM.2 Limited availability PP

Table 2: SFRs CC part 2 extended

B-4
MAT A BSI-1-6c_3.pdf, Blatt 20

BSI-DSZ-CC-0212-2004 Certification Report


0015

As the final transition from test mode to user mode is performed before TOE
delivery, all security functions (SF) of the TOE are applicable from TOE delivery
at the end of phase 3 or 4 (depending on when TOE delivery takes place in a
specific case) to phase 7.

SF.HWProtect: HW protection
The TSF provides detection of out-of-range supply voltages, frequencies
or temperatures, and detection of illegal address and instruction. The
confidentiality and integrity of information is supported by providing
physical shielding of the die and scrambling of memory arrays.
Detection of an error causes the TSF to enter a reset state.

SF.LeakProtect: Leakage protection


The TSF protects against leakage of information from the lC. The
protection features include functions designed to alter the power
consumption, and DES protection including additional measures to alter
the power consumption of the device.

SF.RNG: Random Number Generator


The random number generator is designed to produce random numbers
of 16 bit for the generation of cryptographic keys and for other critical
uses. The random number generator meets the requirements of
application class P2 as specified in [4, AIS 31] and the test requirements
in 1141. Additionally, the TOE softrniare for random number
postprocessing should be included in the users embedded software.

SF.DES:
The TOE provides a DES coprocessor that carries out DES encryption
and decryption in ECB mode, according to the FIBS PUB 46-3 standard
t151.

SF.FMU: Firewall management unit (FMU)


The FMU enables software to control addresses that can be accessed to
check that a target address used in any instruction is within specified
limits and, if not, to enter the reset state. ln addition, the FMU may
enforce a policy controlled only by software executing in ROM, that the
TOE may not execute code in either EEPROM or RAM, or both.

SF.ESFunction:
The Smartcard Embedded Software developer can rely on the following
TOE functionality that has been specifically evaluated as part of the TOE:
. Generation of a non-maskable interrupt (the EWE interrupt) when
writing to EEPROM.

B-5
MAT A BSI-1-6c_3.pdf, Blatt 21

Certification Report BSt.DSZ-CC-0212-2004


0016

. Generation of a non-maskable interrupt at software-defined intervals


(watchdog timer)
. CPU Halt initiated by user software to stop execution until an external
reset is received.

SF.TestModeControl: Test mode control


lf the TOE has been set to user mode, test mode functions are no longer
accessible.

SF.EEPAccess: EEPROM access


The TOE allows any page of EEPROM to have writes (or erase)
disallowed by setting the page to have a protected state. lf a write is
attempted to a protected page then it will leave the page content
unaltered. This protection is permanent once set.

SF.lnject lnjection
Each TOE is injected with data that uniquely identifies the individual lC
during manufacture. lf specified for the Smartcard Embedded Software
included, then additionaldata may also be injected during manufacture.

The TOE was evaluated against the claims of the Security Target [6] by
T-Systems GEI GmbH. The evaluation was completed on 19 December 2003.
The evaluation facility of T-Systems GEI GmbH is an evaluation facility (ITSEF)8
recognised by BSl.
The sponsor, vendor and distributor is Renesas Technology Corp..

1.1 Assurance package


The TOE security assurance requirements are based entirely on the assurance
components defined in part 3 of the Common Criteria (see Annex C or [1],
part 3 for details). The TOE meets the assurance requirements of assurance
level EAL4+ (Evaluation Assurance Level4 augmented). The following table
shows the augmented assurance components.
Reouirement !dentifier
EAL4 TOE evaluation: Methodically designed, tested and
reviewed
+: ADV IMP.2 Develooment - lmplementation of the TSF
+: ALC DVS.2 Life cvcle support - Sufficiency of security measures
+: AVA MSU.3 Vulnerability assessment - Analysis and testing for
insecure states
+: AVA VLA.4 Vulnerabilitv assessment - Hiqhlv resistant
Table 3: Assurance components and EAL-augmentation

lnformation Technology Security Evaluation Facility

B-6
MAT A BSI-1-6c_3.pdf, Blatt 22

BSl-DSZ-CC-0212-2004 CertificationReport
0017

1.2 Strength of Function


The TOE's strength of functions is claimed 'high' (SOF-high) for those functions,
identified in the Security Target, chapter 5.1.4. The rating of the strength of
functions does not include the cryptoalgorithms suitable for encryption and
decryption (see BSIG Section 4, Para.3, Clause 2).

1.3 Summary of threats and Organisational Security Policies (OSPs)


addressed by the evaluated lT product
The threats which were assumed for the evaluation and averted by the TOE
and the organisational security policies defined for the TOE are specified in the
Security Target [7]and can be summarized as follows.
It is assumed that the attacker is a human being or a process acting on behalf
of him.
With reference to the Protection Profile [9], the Security Target [7] defines so
called standard high-level security concerns derived from considering the end-
usage phase (Phase 7 of the life cycle as described in the Security Target) as
follows:
o ffiäflipulation of User Data and of the Smartcard Embedded Software
(while being executed/processed and while being stored in the TOE's
memories),
. disclosure of User Data and of the Smartcard Embedded Software (while
being processed and while being stored in the TOE's memories) and
. deficiency of random numbers.
These high-level security concerns are refined by defining threats on a more
technical levelfor
. lnherent lnformation Leakage,
. Physical Probing,
. Physical Manipulation,
. Malfunction due to Environmental Stress,
. Forced lnformation Leakage,
. Abuse of Functionality and
. Deficiency of Random Numbers.
Phase 1 and the Phases from TOE Delivery up to the end of Phase 6 are
covered by assumptions (see below).
The development and production environment starting with Phase 2 up to TOE
Delivery are covered by an organisational security policy outlining that the lC
Developer / Manufacturer must apply the policy "Protection during TOE
Development and Production (P.Process-TOE)" so that no information is
unintentionally made available for the operational phase of the TOE. The Policy

B-7
MAT A BSI-1-6c_3.pdf, Blatt 23

Certification Report BS l-DSZ-CC-02'.1 2-2004


0018

ensures confidentiality and integrity of the TOE and its related design
information and data. Access to samples, tools and material must be restricted.
Additionally, the Security Target defines a security concern about specific
attacks on the Smartcard Embedded Software the TOE is not being able to
detect or to respond to. This concern is detailled in terms of the threats
. lnability of the TOE to detect an attack
. lnability of the Smartcard Embedded Software to respond to an attack
A specific additional security functionality for DES encryption and decryption
must be provided by the TOE according to an additional security policy defined
in the Security Target.
Objectives are taken from the Protection Profile plus additional ones related to
the additional threats and policy.

1.4 Speciat configuration requirements


The TOE has two different operating modes, user mode and fesf mode. The
application software being executed on the TOE can not use the fesf mode.The
TOE is delivered as a hardware unit at the end of the lC manufacturing process
(Phase 3) or at the end of lC Packaging (Phase 4). At this point in time the
operating system software is already stored in the non-volatile memories of the
chip and the fesf mode is disabled. Thus, there are no special procedures for
generation or installation that are important for a secure use of the TOE. The
further production and delivery processes, like the Smart Card Finishing
Process, Personalisation and the delivery of the smart card to an end user,
have to be organized in a way that excludes all possibilities of physical
manipulation of the TOE. There are no special security measures for the startup
of the TOE besides the requirement that the controller has to be used under the
well-defined operating conditions and that the requirements on the software
have to be applied as described in the user documentation.

1.5 Assumptions about the operating environment


Since the Security Target claims conformance to the Protection Profile [9], the
assumptions defined in section 3.2 of the Protection Profile are valid for the
Security Target of this TOE. With respect to the life cycle defined in the Security
Target, Phase 1 and the Phases from TOE Delivery up to the end of Phase 6
are covered by these assumptions from the PP:
The developer of the Smartcard Embedded Software (Phase 1) must ensure:
. the appropriate "Usage of Hardware Platform (A.Plat-Appl)" while
developing this software in Phase 1. Therefore, it has to be ensured, that
the software fulfils the assumptions for a secure use of the TOE. ln
particular the assumptions imply that developers are trusted to develop
software that fulfils the assumptions.
. the appropriate "Treatment of User Data (A.Resp-Appl)" while developing
this software in Phase 1. The smart card operating system and the smart

B-8
MAT A BSI-1-6c_3.pdf, Blatt 24

BSt-DSZ-CC-0212-2004 Certification Report


0019

. card application software have to use security relevant user data


(especially keys and plain text data) in a secure way. lt is assumed that
the Security Policy as defined for the specific application context of the
environment does not contradict the Security Objectives of the TOE. Only
appropriate secret keys as input for the cryptographic function of the TOE
have to be used to ensure the strength of cryptographic operation.
Protection during Packaging, Finishing and Personalisation (A.Process-Card) is
assumed after TOE Delivery up to the end of Phase 6, as well as during the
delivery to Phase 7.
Following additional assumptions are assumed in the Security Target:
. Key-dependent functions (if any) shall be implemented in the Smartcard
Embedded Software in a way that they are not susceptible to leakage
attacks (A. Key-Function).
Data for injection/pre-personalisation will be supplied from the various
bodies controlling the operations of the system in which the TOE is
functioning. lt is assumed that the generation, distribution, maintenan@,
and destruction of these data is adequately secure (A.lnjDatSupp).

1.6 Disclaimers
The Certification Results only apply to the version of the product indicated in the
Certificate and on the condition that all the stipulations are kept as detailed in
this Certification Report. This certificate is not an endorsement of the lT product
by the Federal Office for lnformation Security (BSl) or any other organisation
that recognises or gives effect to this certificate, and no warranty of the lT
product by BSI or any other organisation that recognises or gives effect to this
certificate, is either expressed or implied.

2 ldentification of the TOE


The following TOE deliverables are provided for a customer who purchases the
TOE:
No Type ldentifier Release Date Form of Deliverv
1 HW AE45C1 01 with lC Wafer or
(HD65145C1) single- manufacturer's packaged module
chip microcomputer lD number
2110 for Kofu
2 SW Self-Test ROM AE45C1_A01_ 16 April2002 Stored in AE45C1
Software (the lC revO.01.as83 Test ROM on the
dedicated software) Rev0.01 chio
3 SW RNG online test Defined by the Hardcopy
software version of t11l
4 DOC Hardware Manual Rev. 1.0 10 March Hardcopy
2003

B-9
MAT A BSI-1-6c_3.pdf, Blatt 25

Certification Report BSI-DSZ-CC-O212-2004

0020

No Type ldentifier Release Date Form of Deliverv


5 DOC Current Control Rev. 1.0 17 June20O2 Hardcopy
Functions
6 DOC Guidelines for using Rev.4.0 30 October Hardcopy
the AE45C1 2003
including SW-Listings
for RNG
oostorocessino
7 DOC Option List for Smart v. 1.2R 10 March Hardcopy
Card Microcomputer 2003
(for HD65145C1
IAE45C1I)
Table 4: Deliverables of the TOE

The TOE is identified by HD65145C1 (short form AE45C1), Version 01 (stored


as version number in the EEPROM), produced in Kofu (indicated by lC
manufacturer's lD number 2110 for Kofu). The pre-personalisation data are
injected into the EEPROM as specified by the customer using the option list
[13].
To ensure that the customer receives this evaluated version, the delivery pro-
cedures described in [11] have to be followed.

3 Security Policy
The security policy of the TOE is to provide basic security functions to be used
by the smart card operating system and the smart card application thus provi-
ding an overall smart card system security. Therefore, the TOE will implement a
symmetric cryptographic block cipher algorithm to ensure the confidentiality of
plain text data by encryption and to support secure authentication protocols and
it will provide a random number generation of appropriate quality.
As the TOE is a hardware security platform, the security policy of the TOE is
also to provide protection against leakage of information (e.9. to ensure the
confidentiality of cryptographic keys during cryptographic functions performed
by the TOE), against physical probing, against malfunctions, against physical
manipulations and against abuse of functionality. Hence the TOE shall:
. maintain the integrity and the confidentiality of data stored in the memory
of the TOE and
o maintain the integrity, the correct operation and the confidentiality of
security functions (security mechanisms and associated functions)
provided by the TOE.

4 Assumptions and Glarification of Scope


The smart card operating system and the application software stored in the
User ROM and in the EEPROM are not part of the TOE. The code in the Test

B-10
MAT A BSI-1-6c_3.pdf, Blatt 26

BSr-DSZ-CC-0212-2004 Certification Report


0021

ROM of the TOE (lC dedicated software) is used by the TOE manufacturer to
check the chip function before TOE delivery. This was considered as part of the
evaluation under the CC assurance aspects ALC for relevant procedures and
under ATE for testing.
The TOE is delivered as a hardware unit at the end of the chip manufacturing
process (phase 3 of the life cycle defined) or at the end of the lC packaging into
modules (phase 4 of the life cycle defined). At these specific points in time the
operating system software is already stored in the non-volatile memories of the
chip and the test mode is completely disabled.
The smart card applications need the security functions of the smart card
operating system based on the security features of the TOE. With respect to
security the composition of this TOE, the operating system, and the smart card
application is important. Within this composition the security functionality is only
partly provided by the TOE and causes dependencies between the TOE
security functions and the functions provided by the operating system or the
smart card application on top. These dependencies are expressed by enViron-
mental and secure usage assumptions as outlined in the user documentation.
Within this evaluation of the TOE several aspects were specifically considered
to support ä composite evaluation of the TOE together with an embedded smart
card application software (i.e. smart card operating system and application).
This was necessary as Renesas Technology Corp. is.the TOE developer and
manufacturer and responsible for specific aspects of handling the embedded
smart card application software in its development and production environment.
For those aspects refer to chapter 9 of this report.

5 Architectural lnformation
The Renesas AE45C1 (HD65145C1), Version 01 smart card controller is an
integrated circuit (lC) providing a hardware platform to a smart card operating
system and smart card application software. A top level block diagram and a list
of subsystems can be found within the TOE description of the Security Target.
The complete hardware description and the complete instruction set of the
Renesas AE45C1 (HD65145C1), Version 01 smart card controller is to be found
in the Hardware Manual [10] and in the document Current Control Functions
1121.
For the implementation of the TOE Security Functions basically the components
16-bit AE-4 CPU, EEPROM, Watchdog Timer, System Control Registers, DES
coprocessor, Firewall Management Unit, a Random Number Generator, the
analog block with security sensors and the random logic module for security
logic are used. Security measures for physical protection are realized within the
layout of the whole circuitry.
The Special Function Registers provide the interface to the software using the
security functions of the TOE. The TOE software for random number
postprocessing uses the defined TOE interfaces.

B-1 1
MAT A BSI-1-6c_3.pdf, Blatt 27

Certification Report BSt-DSZ,CC-O212-2004

0022
The TOE lC Dedicated Software, stored on the chip, is used for testing
purposes during production only and is completely separated from the use of
the embedded software by disabling before TOE delivery.

6 Documentation
The following documentation is provided with the product by the developer to
the customer for secure usage of the TOE in accordance with the Security
Target:
. The Hardware Manual [10],
. Guidelines for using the TOE [11],
. Guidance on Current Control Functions [12],
. The Option List [13],
Note that the customer who buys the TOE is normally the developer of the
operating system and/or application software which will use the TOE as hard-
ware computing platform. The documents [10] - [13] will be used by the
customer to implement the software (operating system / application software)
which will use the TOE.

7 lT Product Testing
The tests performed by the developer were divided into four categories:
. (i) tests which are performgd in a simulation environment;
. (ii) functional production tests, which are done as a last step of the
production process (phase 3) and, in case TOE delivery is at the end of
phase 4, additionally done as a last step of lC Packaging. These tests are
done for every chip to check its correct functionality;
. (iii) characterization tests, which were used to determine the behaviour of
the chip with respect to different operating conditions and
. (iv) special verification tests for security functions which were done with
samples of the TOE.
The developer tests cover all security functions and all security mechanisms as
identified in the functional specification and the high level design. Chips from
the production site in Kofu (see annex A of this report) were used for tests.
The evaluators could repeat the tests of the developer either using the library of
programs and tools delivered to the evaluator or at the developers site. They
performed independent tests to supplement, augment and to verify the tests
performed by the developer by sampling. Besides repeating exactly the
developers tests, test parameters were varied and additional analysis was

B-12
MAT A BSI-1-6c_3.pdf, Blatt 28

BSt-DSZ-GC-0212-2004 Certification Report


0023

done. Security features of the TOE realised by specific design and layout
measures were checked by the evaluators during layout inspections.
The evaluators gave evidence that the actual version of the TOE (Version 01
with lC manufacturer's lD number 2110 for Kofu provides the security functions
as specified. The test results confirm the correct implementation of the TOE
security functions.
For penetration testing the evaluators took all security functions into considera-
tion. lntensive penetration testing was Berformed to consider the physical
tampering of the TOE using highly sophisticated equipment and expert know
how.

8 Evaluated Configuration
The TOE is identified by AE45C1 (HD65145C1) Version 01 lC manufacturer's
lD number 2110 for Kofu. There is only one evaluated configuration of the TOE.
This configuration (all TSF are active and usable) has to be selected by the
customer in the option list at order. All information of how to use the TOE and its
security functions by the software is provided within the user documentation.
The TOE has two different operating modes, user mode and fesf mode. The
application software being executed on the TOE can not use the fesf mode.
Thus, the evaluation was mainly performed in the user mode. For all evaluation
activities performed in fesf mode, there was a rationale why the results are valid
for the user mode, too.

Results of the Evaluation

9.1 Evaluation of the TOE


The Evaluation Technical Report (ETR) t8] was provided by the ITSEF
according to the Common Criteria [1], the Methodology [2], the requirements of
the Scheme [3] and all interpretations and guidelines of the Scheme (AlS) as
relevant for the TOE.
The evaluation methodology CEM [2] was used for those components identical
with EAL4. For components beyond EAL4 the methodology was defined in
coordination with the Certification Body. For smart card lC specific methodology
the guidance documents (i) Joint lnterpretation Library - The application of CC
to lntegrated Circuits, (ii) Joint lnterpretation Library - lntegrated Circuit
Hardware Evaluation Methodology and (äi) Functionality c/asses and evaluation
methodology for physical random number generators (see [4]: AIS 25, AIS 26
and AIS 31) were used. The assurance refinements outlined in the Security
Target were followed in the course of the evaluation of the TOE.

B-13
MAT A BSI-1-6c_3.pdf, Blatt 29

Certification Report BSt-DSZ-CC-0212-2004

0024

The verdicts for the CC, Part 3 assurance components (according to EAL4
augmented and the class ASE for the Security Target evaluation) are
summarised in the following table.
Assurance classes and comoonents Verdict
Securitv Tarqet evaluation CC Class ASE PASS
TOE description ASE DES.1 PASS
Securitv environment ASE ENV.1 PASS
ST introduction ASE INT.1 PASS
Securitv obiectives ASE OBJ.1 PASS
PP claims ASE PPC.,I PASS
lT securitv reouirements ASE REQ.1 PASS
Exolicitlv stated lT securitv reouirements ASE SRE.1 PASS
TOE summarv soecification ASE TSS.1 PASS
Confiouration manaoemenl CC Class ACM PASS
PartialCM automation ACM AUT.1 PASS
Generation suooort and acceotance orocedures ACM CAP.4 PASS
Problem trackinq CM coveraqe ACM SCP.2 PASS
Deliverv and ooeration CC Class ADO PASS
Detection of modification ADO DEL.2 PASS
lnstallation, qeneration. and start-up procedures ADO IGS.1 PASS
Development CC Class ADV PASS
Fullv defined external interfaces ADV FSP.2 PASS
Securitv enforcino hioh-level desion ADV HLD.2 PASS
lmplementation of the TSF ADV IMP,2 PASS
Descriptive low-level desiqn ADV LLD.1 PASS
lnformal correspondence demonstration ADV RCR.1 PASS
lnformal TOE securitv oolicv model ADV SPM.1 PASS
Guidance documents CC Class AGD PASS
Adm inistrator quidance AGD ADM.1 PASS
User ouidance AGD USR.1 PASS
Life cvcle suoport CC Class ALC PASS
Sufficiencv of securitv measures ALC DVS.2 PASS
Developer defined life-cycle model ALC LCD.1 PASS
Well defined develooment tools ALC TAT.1 PASS
Tests CC Class ATE PASS
Analvsis of coveraoe ATE COV.2 PASS
Testinq: hioh-level desion ATE DPT.1 PASS
Functional testino ATE FUN.1 PASS
lndeoendent testino - samole ATE IND.2 PASS
Vulnerability assessment CC Class AVA PASS
Analvsis and testino for insecure states AVA MSU.3 PASS
Strenoth of TOE securitv function evaluation AVA SOF.1 PASS
Hiohlv resistant AVA VLA.4 PASS

Table 5: Verdicts for the assurance components


The evaluation has shown that the TOE fulfills the claimed strength of function
for the (i) Random Number Generation (SF.RNG) and (ii) resistance of the DES
co-processor against D ifferential Power Analysis ( D PA) (S F. LeakP rotect).
For the TOE security function SF.DES, which is DES encryption and decryption
by the hardware co-processor, and for other usage of encryption and decryption

B-14
MAT A BSI-1-6c_3.pdf, Blatt 30

BSt-DSZ-CC-0212-2004 Certification Report

0025
within the TOE, the strength was not evaluated as these are cryptoalgorithms
suitable for encryption and decryption (see BSIG Section 4,Para.3, Clause 2).
For specific evaluation results regarding the development and production
environment see annex A in part D of this report.
The code in the Test ROM of the TOE (lC dedicated software) is used by the
TOE manufacturer to check the chip function before TOE delivery. This was
considered as part of the evaluation under the CC assurance aspects ALC for
relevant procedures and under ATE for testing.
The results of the evaluation are only applicable to the Renesas AE45C1
(HD65145C1) Version 01 Smartcard lntegrated Circuit produced in (indicated
by lC manufacturer's lD number 2110 for Kofu).
The validity can be extended to new versions and releases of the product or to
chips from other production and manufacturing sites, provided the sponsor
applies for re-certification, in accordance with the procedural requirements, and
the evaluation of the modified product does not reveal any security deficiencies.

9.2 Additional Evaluation Results


To support a composite evaluation of the TOE together with a specific smart
card embedded software, additional evaluator actions were performed during
the TOE evaluation. Therefore, refering to the life-cycle model for the TOE the
interaction between phase 1 and phase 2 is of importance and the interface
between a smart card embedded software developer and the developer of the
TOE was examined.

10 Gomments and Recommendations


1. The operationat documentation [10] - 113l contains necessary information
about the usage of the TOE. For secure usage of the TOE the fulfilment
of the assumptions about the environment in the Security Target has to
be taken into account. These requirements are stated in the guidance
document [11].
2. For evaluations of products or systems including the TOE as a part or
using the TOE as a platform (for example smart card operating systems
or complete smart cards), specific information resulting from this
evaluation is of importance and shall be given to the succeeding
evaluation.
3. The TOE software for random number postprocessing shall be
implemented by the embedded software developer as outlined in the
guidance [1 1].

B-1 5
MAT A BSI-1-6c_3.pdf, Blatt 31

Certification Report BSI-DSZ-CC-0212-2004

0025

11 Annexes
Annex A: Evaluation results regarding the development and production
environment (see part D of this report).

12 Security Target
For the purpose of publishing, the Security Target [7] of the Target of Evaluation
(TOE) is provided within a separate document. lt is a sanitized version of the
complete Security Target [6] used for the evaluation performed.

13 Definitions

13.', Acronyms
BSI Bundesamt für Sicherheit in der lnformationstechnik (Federal
Office for lnformation Security)
CBC Cipher Block Chaining
CC Common Criteria for lT Security Evaluation (see [1])
COT Chip-on-Tape
DES Data Encryption Standard; symmetric block cipher algorithm
DPA Differential Power Analysis
EAL Evaluation Assurance Level
ECB ElectricalCode Block
EEPROM Electrically Erasable Programmable Read Only Memory

O ETR Evaluation Technical Report


EWE An lnterrupt generated by the AE45C1 whenever an ättempt is
made to write to EEPROM
FMU Firewall Management Unit
lC lntegrated Circuit
lT lnformation Technology
ITSEF lnformation Technology Security Evaluation Facility
OTP One Time Programmable (a certain part of the EEPROM)
PP Protection Profile
RAM Random Access Memory
RNG Random Number Generator
ROM Read Only Memory

B-16
MAT A BSI-1-6c_3.pdf, Blatt 32

BSt-DSZ-CC-0212-2004 certificationReport
0027

RSA Rivest, Shamir, Adelmann - a public key encryption algorithm


SF Security Function
SFP Security Function Policy
SFR Security Functional Requirement
SOF Strength of Function
ST Security Target
TOE Target of Evaluation
Triple-DES Symmetric block cipher algorithm based on DES
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
TSS TOE Summary Specification

13.2 Glossary
Augmentation - The addition of one or more assurance component(s) from CC
Part 3 to an EAL or assurance package.
Extension -The addition to an ST or PP of functional requirements not
contained in part 2 andlor assurance requirernents not contained in part 3 of the
CC.
Formal - Expressed in a restricted syntax language with defined semantics
based on well-established mathematical concepts.
lnformal - Expressed in natural language
Object - An entity within the TSC that contains or receives information and
upon which subjects perform operations.
Protection Profile - An implementation-independent set of security require-
ments for a category of TOEs that meet specific consumer needs.
Security Function - A part or parts of the TOE that have to be relied upon for
enforcing a closely related subset of the rules from the TSP.
Security Target - A set of security requirements and specifications to be used
as the basis for evaluation of an identified TOE.
Semiformal - Expressed in a restricted syntax language with defined
semantics.
Strength of Function - A qualification of a TOE security function expressing
the minimum efforts assumed necessary to defeat its expected security
behaviour by directly attacking itö underlying security mechanisms.
SOF-basic - A level of the TOE strength of function where analysis shows that
the function provides adequate protection against casual breach of TOE
security by attackers possessing a low attack potential.

B-17
MAT A BSI-1-6c_3.pdf, Blatt 33

Certification Report BSI-DSZ-CC-0212-2004


0028

SOF-medium - A level of the TOE strength of function where analysis shows


that the function provides adequate protection against straightforward or
intentional breach of TOE security by attackers possessing a moderate attack
potential.
SOF-high - A level of the TOE strength of function where analysis shows that
the function provides adequate protection against deliberately planned or
organised breach of TOE security by attackers possessing a high attack
potential.
Subject - An entity within the TSC that causes operations to be performed.
Target Evaluation - An lT product or system and its associated
of
administrator and user guidance documentation that is the subject of an
evaluation
TOE Security Functions - A set consisting of all
hardware, software, and
firmware of the TOE that must be relied upon for the correct enforcement of the
TSP.
TOE Security Policy - A set of rules that regulate how assets are managed,
protected and distributed within a TOE.
TSF Scope of Control - The set of interactions that can occur with or within a
TOE and are subject to the rules of the TSP.

14 Bibliography
t1I Common Criteria for lnformation Technology Security Evaluation,
Version 2.1 , August 1999
t21 Common Methodology for lnformation Technology Security Evaluation
(CEM), Part 1, Version 0.6; Part 2: Evaluation Methodology, Version 1.0,
August 1999
t3I BSI certification: Procedural Description (BSl 7125, Version 5.1, January
1 ee8)

14I Applicaton Notes and lnterpretations of the Scheme (AlS), Bundesamt


für Sicherheit in der lnformationstechnik, Bonn, as relevant for the TOE,
specifically
AIS 25, Version 1 ,29.02.2000 for Joint lnterpretation Library - The
application of CC to lntegrated Circuits, Version 1.0, January 2000;
AIS 26, Version 1 ,26.06.2000 for: Joint lnterpretation Library - lntegrated
Circuit Hardware Evaluation Methodology, Version 1.3, April 2000;
AIS 31, Version 1,25.09.2001 for: Functionality classes and evaluation
methodology of physical random number generators;
AIS 32, Version 1,02.07.2001, Übernahme international abgestimmter
CC- nte rp retatio nen ns d e utsche Zerlifizie ru n gsschema.
I i

tsl German lT Security Certificates (BSl 7148, BSI 7149), periodically


updated list published also on the BSlWeb-site

B-18
MAT A BSI-1-6c_3.pdf, Blatt 34

BSt-DSZ-CC-0212-2004 CertificationReport
002g

t6I AE45C1 (HD65145C1) Version 01, Smartcard Security Target, Renesas


Technology Corp., Version 2.0, 29 April 2003, (confidential document)

17l AE45C1 (HD65145C1) Version 01, Smartcard Security Target, (Public


version), Renesas Technology Corp., Version 2.0,17 December 2003
t8I Evaluation Technical Report, BSI-DSZ-CC-0212, Version 1.20, 18
December 2003, for the Product Renesas Single-Chip Microcontroller
AE45C1 (HD65145C1) Version 01, (confidential document)
Iel Smartcard IC Platform Protection Profile, Version 1.0, July 2001, BSI
registration lD: BSI-PP-0002-2001, developed by Atmel Smart Card lCs,
Hitachi Europe Ltd., lnfineon Technologies AG, Philips Semiconductors
[10] Hitachi Single-Chip Microcomputer, AE-4 Series, AE45C1 (HD65145C1)
Hardware Manual, Rev. 1.0, 10 March 2003, Hitachi, Ltd., (confi
dential document)
l11l Renesas Single-Chip Microcomputer, AE-4 Series, Guidelines for using
the AE45C1 Rev. 4.0, 30 October 2003, Renesas Technology Corp.,
(confidentia I document)

l12l Hitachi Single-Chip Microcomputer, AE-4 Series, AE45C1 (HD65145C1),


Current Control Functions, Rev. 1.0, 17 June 2002, Hitachi, Ltd.,
(confidentia I document)

t13l Option List for Smart Card Microcomputer (for HD65145C1[AE45C1]),


V1.2R, Semiconductor & lntegrated Circuits Hitachi, Ltd., 15 October
2002, (confidential document)
l14l Federal lnformation Processing Standards Publication, Security
tn M"y
Requirements for Cryptographic Modules, FIPS PUB 140-2,25
2001
t15] U.S. Department of Commerce/ National Bureau of Standards Data
Encryption Standard, FIPS PUB 46-3,25th October 1999

B-19
MAT A BSI-1-6c_3.pdf, Blatt 35

Certification Report
' BSI.DSZ-CC-0212-2004

0030

This page is intentionally left blank.

B-20
MAT A BSI-1-6c_3.pdf, Blatt 36

BSt-DSZ-CC-0212-2004 Certification Report


0ü31

C Excerpts from the Criteria

CC Part 1:

Caveats on evaluation results (chapter 5.4) / Final lnterpretation 008

The conformance result indicates the source of the collection of requirements that is
met by a TOE or PP that passes its evaluation. This conformance result is presented
with respect to Part 2 (functional requirements), Part 3 (assurance requirements) and, if
applicable, to a pre-defined set of requirements (e.9., EAL, Protection Profile).

The conformance result consists of one of the following:

Part 2 conformant - A PP or TOE is Part 2 conformant if the functional requirements


are based only upon functional components in Part 2

Part 2 extended - A PP or TOE is Part 2 extended if the functional requirements


include functional components not in Part2

plus one of the following:

Part 3 conformant - A PP or TOE is Part 3 conformant if the assurance requirements


are based only upon assurance components in Part 3

Part 3 extended - A PP or TOE is Part 3 extended if the assurance requirements


include assurance requirements not in Part 3.

Additionally, the conformance result may include a statement made with respect to sets
of defined requirements, in which case it consists of one of the following:

Package name Conformant - A PP or TOE is conformant to a pre-defined named


functional and/or assurance package (e.9. EAL) if the requirements (functions or
assurance) include all components in the packages listed as part of the conformance
result.

Package name Augmented - A PP or TOE is an augmentation of a pre-defined


named functional and/or assurance package (e.9. EAL) if the requirements (functions
or assurance) are a proper superset of all components in the packages listed as part of
the conformance result.

Finally, the conformance result may also include a statement made with respect to
Protection Profiles, in which case it includes the following:

PP Conformant - A TOE meets specific PP(s), which are listed as part of the
conformance result.

c-1
MAT A BSI-1-6c_3.pdf, Blatt 37

Certification Report BSt-DSZ-CC-0212-2004

0032

CC Part 3:

Ass urance categorisation (chapter 2.5)

The assurance classes, families, and the abbreviation for each family are shown in
Table 2.1.

Assurance Class Assurance Familv Abbreviated Name


Class ACM: CM automation ACM AUT
Configuration
manaoement
CM caoabilities ACM CAP
CM scooe ACM SCP
Class ADO: Delivery Delivery ADO-DEL
and ooeration
lnstallation. oeneration and start-uo ADO IGS
Class ADV: Functional specification ADV_FSP
Develonmenl
Hioh-level desion ADV HLD
lmolementation reoresentation ADV IMP
TSF internals ADV INT
Low-leveldesiqn ADV LLD
Representation corresoondence ADV RCR
Securitv oolicv modelino ADV SPM
Class AGD: Guidance Administrator guidance AGD ADM
documents
User ouidance AGD USR
Class ALC: Life cycle Development security ALC DVS
strooort
Flaw remediation ALC FLR
Life cvcle definition ALC LCD
Tools and technioues ALC TAT
Class ATE:Tests Coverage ATE COV
Depth ATE DPT
Functionaltests ATE FUN
lndependent testino ATE IND
Class AVA: Covert channel analysis AVA CCA
Vulnerability
assessment
Misuse AVA MSU
Strength of TOE securitv functions AVA SOF
Vulnerabilitv analvsis AVA VLA

Table 2.1 - Assurance family breakdown and mapping

c-2
MAT A BSI-1-6c_3.pdf, Blatt 38

BSt-DSZ-CC-0212-2004 GertificationReport
003g

Evaluation assurance levels (chapter 6)

The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the
level of assurance obtained with the cost and feasibility of acquiring that degree of
assurance. The CC approach identifies the separate concepts of assurance in a TOE
at the end of the evaluation, and of maintenance of that assurance during the
operational use of the TOE.

It is important to note that not all families and components from Part 3 are included in
the EALs. This is not to say that these do not provide meaningful and desirable
assurances. lnstead, it is expected that these families and components will be
considered for augmentation of an EAL in those PPs and STs for which they provide
utility.

Evaluation assurance level (EAL) overview (chapter 6.1)

Table 6.'1 represents a summary of the EALs. The columns represent a hierarchically
ordered set of EALs, while the rows represent assurance families. Each number in the
resulting matrix identifies a specific assurance component where applicable.

As outlined in the next section, seven hierarchically ordered evaluation assurance


levels are defined in the CC for the rating of a TOE's assurance. They are hierarchically
ordered in as much as each EAL represents more assurance than all lower EALs. The
increase in assurance from EAL to EAL is accomplished by subsfffution of a
hierarchically higher assurance component from the same assurance family (i.e.
increasing rigour, scope, and/or depth) and from the addition of assurance components
from other assurance families (i.e. adding new requirements).

These EALs consist of an appropriate combination of assurance components as


described in chapter 2 of this Part 3. More precisely, each EAL includes no more than
one component of each assurance family and all assurance dependencies of every
component are addressed.

While the EALs are defined in the CC, it is possible to represent other combinations of
assurance. Specifically, the notion of "augmentation" allows the addition of assurance
components (from assurance families not already included in the EAL) or the
substitution of assurance components (with another hierarchically higher assurance
component in the same assurance family) to an EAL. Of the assurance constructs
defined in the CC, only EALs may be augmented. The notion of an "EAL minus a
constituent assurance component" is not recognised by the CC as a valid claim.
Augmentation carries with it the obligation on the part of the claimant to justify the utility
and added value of the added assurance component to the EAL. An EAL may also be
extended with explicitly stated assurance requirements.

c-3
MAT A BSI-1-6c_3.pdf, Blatt 39

Certification Report BSr-DSz-Gc-o212-20o4


0034

Assurance Assurance Assurance Components by


Class Familv Evaluation Assurance Level
EALl EAL2 EAL3 EAL4 EALS EAL6 EALT
Configuration ACM-AUT 1 1 2 2
manaoement
ACM CAP 1 2 3 4 4 5 5
ACM SCP 1 2 3 3 3
Delivery and ADO-DEL 1 1 2 2 2 3
ooeration
ADO IGS 1 1 1 1 1 1 1

Development ADV FSP 1 1 1 2 3 3 4


ADV HLD 1 2 2 3 4 5
ADV IMP 1 2 3 3
ADV INT 1 2 3
ADV LLD 1 1 2 2
ADV RCR 1 1 1 1 2 2 3
ADV SPM 1 3 3 3
Guidance AGD_ADM 1 1 1 1 1 1 1
documents
AGD USR 1 1 1 1 1 1 1

Life cycle ALC-DVS 1 1 1 2 2


suooort
ALC FLR
ALC LCD 1 2 2 3
ALC TAT 1 2 3 3
Tests ATE COV 1 2 2 2 3 3
ATE DPT 1 1 2 2 3
ATE FUN 1 1 1 1 2 2
ATE IND 1 2 2 2 2 2 3
Vulnerability AVA_CCA 1 2 2
assessment
AVA MSU 1 2 2 3 3
AVA SOF 1 1 1 1 1 1
AVA VLA 1 1 2 3 4 4

Table 6.1 - Evaluation assurance level summary

c-4
MAT A BSI-1-6c_3.pdf, Blatt 40

BSI-DSZ-CC-0212-2004 Certification Report


0035

Evaluation assurance level 1 (EALI) - functionally tested (chapter 6.2.1)

Objectives
EAL1 is applicable where some confidence in correct operation is required, but the
threats to security are not viewed as serious. lt will be of value where independent
assurance is required to support the contention that due care has been exercised with
respect to the protection of personal or similar information
EALI provides an evaluation of the TOE as made available to the customer, including
independent testing against a specification, and an examination of the guidance
documentation provided. lt is intended that an EAL1 evaluation could be successfully
conducted without assistance from the developer of the TOE, and for minimal outlay.
An evaluation at this level should provide evidence that the TOE functions in a manner
consistent with its documentation, and that it provides useful protection against
identified threats.

Evaluation assurance level 2 (EAL?| - structurally tested (chapter 6.2.2)


Objectives
EAL2 requires the co-operation of the developer in terms of the delivery of design
information and test results, but should not demand more effort on the part of the
developer than is consistent with good commercial practice. As such it should not
require a substantially increased investment of cost or time.
EAL2 is therefore applicable in those circumstances where developers or users require
a low to moderate level of independently assured security in the absence of ready
availability of the complete development record. Such a situation may arise when
securing legacy systems, or where access to the developer may be limited.

Evaluation assurance levet 3 (EAL3) - methodically tested and checked


(chapter 6.2.3)

Objectives
EAL3 permits a conscientious developer to gain maximum assurance from positive
security engineering at the design stage without substantial alteration of existing sound
development practices.
EAL3 is applicable in those circumstances where developers or users require a
moderate level of independently assured security, and require a thorough investigation
of the TOE and its development without substantial re-engineering.

Evaluation assurance level 4 (EAL4) - methodically designed, tested, and


reviewed (chapter 6.2.4)

Objectives
EAL4 permits a developer to gain maximum assurance from positive security
engineering based on good commercial development practices which, though rigorous,
do not require substantial specialist knowledge, skills, and other resources. EAL4 is the

c-5
MAT A BSI-1-6c_3.pdf, Blatt 41

Certification Report BSI-DSZ-CC-0212-2004

0036
highest level at which it is likely to be economically feasible to retrofit to an existing
product line.
EAL4 is therefore applicable in those circumstances where developers or users require
a moderate to high level of independently assured security in conventional commodity
TOEs and are prepared to incur additional security-specific engineering costs.

Evaluation assurance level 5 (EAL5) - semiformally designed and tested


(chapter 6.2.5)

Objectives
EALS permits a developer to gain maximum assurance from security engineering
based upon rigorous commercial development practices supported
-by
moderatä
application of specialist security engineering techniques. Such a TOE will probably be
designed and developed with the intent of achieving EAL5 assurance. lt is likelyihat
the additional costs attributable to the EALS requirements, relative to rigorous
development without the application of specialised techniques, will not be large.
EALS is therefore applicable in those circumstances where developers or users require
a high level of independently assured security in a planned development and require a
rigorous development approach without incurring unreasonable costs attributable to
specialist security engineering techniques.

Evaluation assurance level 6 (EALG) - semiformally verified design and


tested (chapter 6.2.6)
Objectives
EALG permits developers to gain high assurance from application of security
engineering techniques to a rigorous development environment in order to produce a
premium ToE for protecting high value assets against significant risks.
EAL6 is therefore applicable to the development of security TOEs for application in
high risk situations where the value of the protected assets justifies the additional
costs.

Evaluation assurance level 7 (EAL7) - formally verified design and tested


(chapter 6.2.7)

Objectives
EALT is applicable to the development of security TOEs for application in extremely
high risk situations and/or where the high value of the assets justifies the higher costs.
Practical application of EALT is currently limited to TOEs witn tigfrtty focusäd security
functionality that is amenable to extensive formal analysis.

c-6
MAT A BSI-1-6c_3.pdf, Blatt 42

BSI-DSZ-CC-0212-2004 Certification Report

0037

Strength of TOE security functions (AVA_SOF) (chapter 14.3)

AVA_SOF Strength of TOE security functions

Objectives
Even if a TOE security function cannot be bypassed, deactivated, or corrupted, it may
still be possible to defeat it because there is a vulnerability in the concept of its
underlying security mechanisms. For those functions a qualification of their security
behaviour can be made using the results of a quantitative or statistical analysis of the
security behaviour of these mechanisms and the effort required to overcome them. The
qualification is made in the form of a strength of TOE security function claim.

Vulnerability analysis (AVA_VLA) (chapter 14.4)


O
AVA_VLA Vulnerability analysis

Objectives
Vulnerability analysis is an assessment to determine whether vulnerabilities identified,
during the evaluation of the construction and anticipated operation of the TOE or by
other methods (e.9. by flaw hypotheses), could allow users to violate the TSP.
Vulnerability analysis deals with the threats that a user will be able to discover flaws
that will allow unauthorised access to resources (e.9. data), allow the ability to interfere
with or alter the TSF, or interfere with the authorised capabilities of other users.

Application notes
A vulnerability analysis is performed by the developer in order to ascertain the
presence of security vulnerabilities, and should consider at least the contents of all the
TOE deliverables including the ST for the targeted evaluation assurance level. The
developer is required to document the disposition of identified vulnerabilities to allow
the evaluator to make use of that information if it is found useful as a support for the
evaluator's independent vulnerability analysis.
lndependent vulnerability analysis goes beyond the vulnerabilities identified by the
developer. The main intent of the evatuator analysis is to determine that the TOE is
resistant to penetration attacks performed by an attacker possessing a low (for
AVA_VLA.2), moderate (for AVA_VLA.3) or high (for AVA-VLA.4) attack potential.

c-7
MAT A BSI-1-6c_3.pdf, Blatt 43

Certification Report BSI-DSZ-CC-0212-2004


0038

This page is intentionally left blank.

c-8
MAT A BSI-1-6c_3.pdf, Blatt 44

BSI-DSZ-CC-0212-2004 Certification Report

0ü39

D Annexes

List of annexes of this certification report

Annex A: Evaluation results regarding development


and production environment D-3

D-1
MAT A BSI-1-6c_3.pdf, Blatt 45

Gertification Report BSI-DSZ-CC-0212-2004

0040

This page is intentionally left blank.

D-2
MAT A BSI-1-6c_3.pdf, Blatt 46

BSt-DSZ-CC-0212,2004 Certification Report

ü041

Annex A of Gertification Report BSI-DSZ-CC-0212-2004

Evaluation results regarding


development and production
environment

The lT product, Renesas AE45C1 (HD65145C1) Smartcard lntegrated Circuit, Version 01


(Target of Evaluation, TOE) has been evaluated at an accredited and licensed/ approved
evaluation facility using the Common Methodology for lT Security Evaluation, Part 1
Version 0.6, Parl2 Version 1.0, extended by advice of the Certification Body for
components beyond EAL4 and smart card specific guidance, for conformance to the
Common Criteria for lT Security Evaluation, Version 2.1 (|SO/IEC15408: 1999).
As a result of the TOE certification, dated 8 January 2004, the following results regarding
the development and production environment apply. The Common Criteria assurance
requirements

a ACM - Configuration management (i.e. ACM_AUT.I, ACM_CAP.4, ACM_SCP.2),


a ADO - Delivery and operation (i.e. ADO_DEL.2, ADO_IGS.I) and
a ALC - Life cycle support (i.e. ALC_DVS.2, ALC_LCD.I, ALC_TAT.I),

are fulfilled for the development and production sites of the TOE listed below ((a) - (e)):

(a) Renesas Technology Corp. -KodairaS-22-1, Jousuihon-town, Kodaira-city, To§o,


Japan
(b) Renesas Technology Corp. -Kofu, ß17 N ish ihachma n, Ryuoh-town, Nakakoma{ un,
Yamanashi Pref., Japan (production site "Kofu")
(c) Severa! subcontractors supporting the production with i.e. photomask fabrication
and lC packaging into modules

The hardware part of the TOE produced at site d (Kofu) indicated by lC manufacturer's lD
number 2110 for Kofu .
For the sites listed above, the requirements have been specifically applied in accordance
with the Security Target [6]. The evaluators verified, that the threats and the security
objective for the life cycle phases 2, 3 and 4 up to delivery at the end of phases 3 or 4 as
stated in the TOE Security Target (AE45C1 (HD65145C1) Version 01, Smartcard Secuity
Target, Semiconductor &- lntegrated Circuits Hitachi, Ltd., Version 2.0, 29 Apfl 2OO3,16l)
are fulfilled by the procedures of these sites.

Annex A D-3
MAT A BSI-1-6c_3.pdf, Blatt 47

Certification Report BSt-DSZ-CC-0212-2004

0ü42

This page is intentionally left blank.

Annex A
MAT A BSI-1-6c_3.pdf, Blatt 48

0043

Factoring RSA keys from certified smart cards:


Coppersmith in the wild

Daniel J. Bernsteinl'2, Yun-An Changs, Chen-Mou Cheng3, Li-Ping Choua, Nadia Heningers,
Tanja Lange2, and Nicko van Someren6
1 Department of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
dj b@cr . yp . to
2 Department of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600M8 Eindhoven, the Netherlands
. tarja@hyperelliptic. org
3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{ghf jdks1, doug}@crypto . tw
a Department of Computer Science and Information Engineering
Chinese Culture University Taipei, Taiwan
raadonalg@goail. corn
5 Microsoft Research New England
One Memorial Drive, Cambridge, MA 02142, USA
nadial@cs , princetorr. edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
nicko@good. com

Abstract. This paper explains how to efficiently factor 183 distinct RSA keys out of more
than two million 1024-bir RSA keys downloaded from Taiwan's national "Cit\zen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that share primes and that are efficiently factored by a
batch-gcd computation. This is the same type of computation that was used last year by two
independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman;
Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands
of cryptographic keys on the Internet.
The remaining 80 keys do not share primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation failures: first using the shared primes as a springboard
to characterize the failures, and then using Coppersmith-type partial-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys found in
the wild.
Ke5rwords: RSA, smart cards, integer factorization, Coppersmith, lattices

1 Introduction
In 2003, Taiwan introduced an e-governrnent initiative to provide a national public-key infrastruc-
ture for all citizens. This national certificate service allows citizens to use smart-card ID cards to
digitally authenticate themselves to government services, such as filing income taxes and modi-
fying car registrations online, as well as to a growing number of non-government services. RSA
keys are generated by the cards, registered with a government authority, and placed into an oniine
repository of "Citizen Digital Certificates".
Unfortunately, the random-number generators used to generate many of these keys are faüally
flawed, and have generated real certificates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 49

0044

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

inspect repeated primes,


batch gcd observe patterns,
generalize

Public-key 103
database secret keys
batch trial division

127
secret keys

o t25
secret keys 668 patterns

772
secret keys

i83
secret keys

Fig. 1. Retrospective summaxy of the data flow leading to successful factoiizations. After successfully
factoring keys using a batch gcd algorithm, we characterized the failures, and used trial division to check
for broader classes ofspecified primes (input on the right) as exact divisors. We then extended the attack
and applied Coppersmith's method to check for the specified primes as approximate divisors.

This paper explains how we have computed the secret keys for 183 different certificates in use by
real people.

1.1 Factorization techniques


Bad randomness is not new. Last year two independent research teams
[8, 11] exploited bad ran-
domness to find secret keys for tens of thousands of SSL certificates on the Internet, a similar
number of SSH'host keys, and a few PGP keys.
Our starting point in this work is the same basic attack used in those papers against poorly
generated RSA keys, narnely scanning for pairs of distinct keys that share a common divisor (see
Section 3). The basic gcd attack, applied to the entire database of Citizen Digital Certificates,
shows that 103 keys factor into 119 different primes.
We go beyond this attack in several ways. First, the shared primes provide enough data to
build a model of the prime-generatiou procedure. It is surprising to see uisible patterns of non-
randomness in the primes generated by these smart cards, much more blatant non-randomness
than the SSL key-generation failures identified by [8, 11]. One normally expects smart cards to
be controlled environments with built-in random-number generators, typically certified to meet
various standards and practically guaranteed to avoid such obvious patterns. For comparison, the
SSL keys factored last year were typically keys generated by low-power networked devices such as
MAT A BSI-1-6c_3.pdf, Blatt 50

0045

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers and firewalls running the Linux operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime factors: we hypothesize a particular model
of randomness-generation failures consistent with 18 of the common divisors. The same rnodel is
actually capable of generating 164 different primes, and testing all of those primes using batch ürial
division successfully factors further keys. One might also speculate that the cards can generate
primes fitting a somewhat broader model; this speculation turns out to be correct, factoring a few
additional keys and bringing the total to 125. See Section 4 for a description of the patterns in
these primes.
There are also several prime factors that are similar to the 164 patterns but that contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice-based partial-key-recovery attacks to efficiently find prime
divisors close to the patterns. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottom 40% of the bits of the prime. The bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes them particularly
susceptible to these attacks. These attacks produce dozens of additioual factorizatious, raising the
total to 183.
In the end nearly half of the keys that we factored d,id not share any common divisors with other
keys; most of these were factored by the Coppersrnith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersmith-style attack breaking keys in the wild.

1.2 Certification
The flawed keys were generated by government-issued smart cards that both the certification
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
It is clear from their externally visible behavior, as shown in this paper, that the random-
number generators used to generate the vulnerable keys actually fall far short of these standards.
This demonstrates a failure of the underlying hardware and the card's operating system, both of
which are covered by certification. we have no explanation for the discrepancy.

1.3 Observed response and reqommended response


When we reported the common-divisor vulnerabilities to government authorities, their response
was to revoke exactly the certificates sharing common factors and ask only those users to regenerate
keys. See Section 7 for more details.
Our further factorizations dernonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themselves as primes appearing twice, but sometimes
manifest themselves as primes that appear only once, such as the primes that we found by
Coppersmith-type attacks. Both cases are vulnerable to attackers with adequate rnodels of the
randomness-generation process, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for cornmon divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much more than an indication that those parüicular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system, replacing
it with a properly engineered system and to revoke all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the primes generated by these smart cards had been modifled to include a card serial number
as their top bits then the keys would have avoided common divisors but the primes would still
have been reasonably predictable to attackers. Our work illustrates several methods of translating
different types of rnalfunctioning behavior into concrete vulnerabilities. There are many potential
MAT A BSI-1-6c_3.pdf, Blatt 51

ü046

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vuinerabilities resulting from bad randomness; it is important to thoroughly test every comporent
of a random-nurnber generator, not merely to look for certain types of extreme failures.

2 Background
2.L The Taiwan Citizen Digital Certificate program
Taiwan's Citizen Digital Certificates (CDCs) are a standard rreans of authentication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certificate Authority (MOICA), a level I subordi-
nate CA of the Taiwanese governrnental PKI. Since the program's launch in 2003, more than 3.5
million CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates form a basis for the Taiwanese government's plan to migrate to electronic
certificates from existing paper certificates for a range of applications including national and other
identification cards, driver's licenses, and various professional technician licenses.
Taiwanese citizens can already use the CDC to authenticate themselves to a number of govern-
ment agencies over the Internet, in order to file personal income taxes, update car registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Certificate reg'istrat'ion: In order to generate a CDC, a eitizen brings their ID card to a government
registration office. A government official places the (smart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed by MOICA. The certificate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Standard,s certifi,cations: MOICA states that these cards are "high security", and "have been
accredited to FIPS 140-1 level 2", and also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For comparison, the SSL keys factored Iast year were generated
by software-hardware combinations that had never claimed to be evaluated for cryptographiö
security, such as Linux running on a home router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID program. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly all, of the problems we have identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS 140-1 level 2 [14]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certificates


In March 2012, inspired by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP directory at ldap://rnoica.nat.gov.tw. Out of these RSA keys, 2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The 1024-bit CDCs contain 2086177 distinct moduli, of which 171366 moduli appear more
than once. The repeated moduli appQar to all be due to expired certificates still contained in the
database which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 52

00 47

Factoring RSA keys from certified smart cards: Coppersmith in the wild

2.3 Random Number Generation


While generating high-quality random-numbers is critical to the security of cryptographic systems,
it is also notoriously difficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial component of generating random numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, 1, 6] specify correct behavior for these types of systems. In general, software pseudo-
random number generators require a significant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in tire paper, the smart cards used in the PKI we examined faii to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any run-time
testing before generating keys, and they clearly do not apply arry post-processing to the randomness
stream. The lack of testing or post-processing causes the iuitial randomness-generation failure to
be rnuch more damaging than it would have been otherwise.

Analog RNG circu'its; An analog circuit is the standard choice when hardware designers have the
luxury of designing dedicated circuits for random-nuurber generation. An analog circuit allows the
designer to obtain randomness from simple quantum effects. While the use of radioactive decay is
rare in commercial products, the quantum noise exhibited by a current through a suitably biased
diode can be arnplified and sampled to deliver an entropy source of very high quality.

On-chi'p RNG circui,ts; Mixing analog and digital circuits on the same die is costly, so chip designers
often seek other sources ofunpredictability. These sources can include variation in gate propagation
delays or gate metastability, which exhibit inherent randomness. Designers can explicitly harness
gate-delay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take advantage of randomness in gate metastability, designers
build circuits that output bits based on the time it takes for the circuit to settle to a steady state,
a variable which should be hard to predict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variations, and subtle on-chip effects such
as inductive coupling or charge coupling between components can cause free-running oscillators to
settle into synchronised patterns and metastable circuits to predictably land one way or the other
depending on other components nearby on the chip.

Hand'l'ing Entropy Sources: Even with perfectly unpredictable source of randomness, care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density, test the signal from the enüropy source at run
time, and run the output through a compression function such as a cryptographically secure hash
function. These practices are required by a number ofsecurity standards such as FIPS 140 [14].

3 Batch gcd
This section reviews the approach of [8, 11] for detecting common factors in a collection of RSA
keys, and reports the results of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA moduli Nt : per and Nz : pq2 sharing exactly one prime factor
p, then the greatest common divisor of lü and /{2 will be p. Computlng this gcd is fast, and
dividing it out of lü and I{2 produces the other factors e1 a\d e2.
Of course, this type of vulnerability should never arise for properly generated RSA keys. How-
ever, since [8,11] had observed weak random-number generators producing keys with repeated
factors in the wild, we began by checking whether there were repeated factors among the Citizen
Digital Certificates.
MAT A BSI-1-6c_3.pdf, Blatt 53

0048

D J Bernstein, Y-A Chang, C-M Cheng, L'P Chou, N Heninger, T Lange, N van Someren

Instead of the naive quadratic-time method of doing this computation (checking each l[
against each ly'2), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementatiou available athttps:/lfactorable.net/resources.html.
We ran this implementation on the 3192962 disiinct RSA moduli and found that 103 moduli
were factored due to nontrivial common factors. This computation, parallelized across four cores
of a 3.1GHz AMD FX-8120, finished in just 45 minutes.

Attacking patterned factors


A properly functioning random number generator would never generate identical 512-bit primes,
in the previous section immediately indicates
so the discovery of repeated prime factors described
that the random-number-generation process producing these keys is broken. This section analyzes
the structure ofthe repeated factors generated by the flawed random-nuinber generator and designs
a targeted attack againsi this structure.
The 103 moduli with repeated factors show a remarkable distribution of the shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appendix A.
One prime factor, p110, appears a total of 46 times with different second primes. The hexadec-
imal representation of this factor is
c000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000002f I
which is the next prime afber 2517 125to .
The next most common factor, repeated 7 times, is
c92 4249 2249 29 249 I 249 492 449 24249 2249 29 2499 249 49 2449 24249 2249 29 249
9 249 49 24 49 242 49 22 49 29 249 92 49 49 2 4 49 2 42 49 2249 29 249 I 249 49 24 49 2424 e 5

which displays a remarkable periodic structure. The binary representation of this integer, excluding
ofthe string 001 with a "hiccup" every
a few most and least significant bits, is a repeated sequence
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. We hypothesized that nearly every repeated prime factor had been generated using the
following process:

1. Choose a bit pattern of length 1, 3, 5, or 7 bits, repeaü it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the rnost significant two bits to 11.
4. Find the next prime greater than or equal to this number.

We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and üested divisibility with each modulus. This factored a total of 105 moduli, including
18 previously unfactored moduli, for a total of 127.
None of the repeated primes exhibit a (minimal) period of Iength 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods iypically appear
in fewer keys than patterns with shorter periods, and are thus less Iikely to appear as divisors of
two or more keys, raising the question of whether there are primes with larger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extended
this test to include length-9 periods and length-L1. periods. The lengbh-9 periods factored 4 more
keys but the length-11 periods did not factor any new keys, leading us to speculate that 3,5, and
7 are the only factors of the period length. We then ran a complete test on all length-l5 patterns
but did not find any further factors. The total number of certificates broken by these divisibility
tests, together with the initial batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 54

004e

Factoring RSA keys from certified sm fls: Coppersmith in the wild

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime factors dividing the same modulus.

Sporad,ic errors: The handful of shared prime factors in our sample of gcd-factored keys that did
not match the above form were differing from patterns in very few positions. We experimented with
finding more factors using brute-force search staxting from 0xc0. . .0 and found a new factors, but
these factors are more systematically and emciently found using LLL in Coppersmith's rnethod,
as described in the next section.

5 Univariate Coppersmith
Several of the factors computed via the GCD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic errors. Coppersmith's
method [5,4] factors RSA moduli if the top bits of the primes are known, which matches our
situation if the errors appear in the bottom few bits of a factor. This section presents this method
following the variant by Howgrave-Graham [10] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factored.
The idea is as follows: we assume that some prime.factor p of N is of the form

P:a+r
MAT A BSI-1-6c_3.pdf, Blatt 55

0050

8 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

where a is a 512-bit integer known to us (one ofthe bit patterns described in the previous section)
and r is a small integer error to account for a sequence of bit errors (and incrementing to next
prime) among the least significant bits of p.
In the Coppersmith/Howgrave-Graham method, we can write a polynomial

f(r):a+r
and we would like to find a root r of / modulo a large divisor of ,nt (of size approximatel y Nt /2 p) .
=
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new polynomial g(r) where g(r) :0 over the integers, and thus we can factor g to
discover it.
We construct the ]attice -L as
lxz xa of
lo xol
L0 0 I{l
corresponding to the coefficients of the polynomials N,f (Xr),Xrf (Xr), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of a polynomial g(Xr). Then we compute the roots 16 of g(r) and check if a * re divides N. If so,
we have factored I{.
Any lattice vector is a linear combination of / and Iy' and is thus divisible by p A prime p is
found by this method if g(r): 0 mod p holds not only modulo p but over the integers. The latter
is ensured if the coefficients of g are sufficiently srnall. The shortest vector u1 found by LLL is of
Iength
r-r) /a dim L,
lull < 2(ar' ldet L11/
which must be smaller than p for the attack to succeed.
In our situation this translates to

2t/z (X3 N)r/3. \gt/z a9 X< 2-7/21Jr/6 ,

so for .Ä{ x )7024 we can choose X as large 6


2170, meaning that for a fast attack using dimension-
3 lattices up to the bglloT third of a prime can deviate from the pattern a. In the following
we ignore the factor 23imL-7)/a since all lattices we deal with are of small dimension and the
contribution compared to .A[ is negligible.

5.1" Experimental Results


A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this method for one of the 164 patterns identified in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including all 105 keys derived from the patterns without error, and
found 39 previously unfactored keys.
It is worth noting that the 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000...0f. Including OxdOOOO...0, 0xe0000...0, 0xf0000...0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation rnight set the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's method can find primes with errors in up to lf2 of their bits using lattices of
higher dimension. Getting close to this bound is prohibitively expensive, but trying somewhat
larger dimensions than 3 is possible. For dimension b we used basis

{N2, N f (rx), f'(rx),rx f2(rx),(ux)z y2(rx)}


MAT A BSI-1-6c_3.pdf, Blatt 56

0051

Factoring RSA keys from certified smart cards: Coppersmith in the wild

which up to LLL constants handles X < N1/5 , i.e. up to 204 erroneous bottom bits in p for .l[ of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
making it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe000. . .f (2511 +2510+2s0e+15; appeared as a colnmon factor after taking GCDs but
was not be found by the lattice attacks described in this section starting from the basic patterns
described in Section 4. Coppersmith's attack also works to search for errors in higher bits of p by
definingthepolynomial/as l@):a*Ztx. Herelistheoffsetlocationof theerrorswehopeto
learn and the same rnethod will find errors of the form 2tr w\thr 1X.
However, since we hypothesize that the prirae factors are generated by incrementing to the next
prime after a sequence of bits output by the flawed RNG, we do not know the least significant bits
of a because they are rnodified in the prime generation process. This problem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for more strings a: For each of the 164 basic patterns include all 2*-r
variations of the bottom rn bits with the LSB flxed to 1. This will find factors if finding the next
prime from the base string did not require more than those bottom rn bits to change.
A brief analysis suggests that for this attack to have a 50Yo chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prime is approximately lllnz. See [7] for an overview and more precise statements.
In our case of primes around 2572, each number has about a 1/355 chance of being prirne. Since
1 - (1 - l/355)256:0.514290, trying 128 patterns for the bottom eight bits for odd patterns has
a 50% chance of covering a sufficiently Iarge interval to find a prime. For our implementation this
computation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be found with this search but the method presented in the following section is more
efficient at handling errors in top and bottom positions unless a very large portion of the top bits

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring,in the least significant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most significant bits of one of the factors,
without resorting to brute-forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of N has the form
p: a+2ts*r
where o is a 512-bit integer with a predictable bit pattern (as described in Section 4), ü is a bit
offset where a sequence of bit errors s deviating from the predictable pattern in a occurred during
key generation, and r is an error at the least significant bits to account for the implementation
incrementing to the next prime.
To apply Coppersmith's method, we can define an equation I@,U) - a+2talA and try to use
lattice basis reduction to find new polynomials Qa(r,9) with the property that if /(s,r) vanishes
modulo a large unknown divisor p of l{ and s and r are reasonably small, then Qa(s, r) : 0 over
the integers. In that case, we can attempt to find appropriate zeros of 8r. The most common
method to do this is to look at multiple distinct polynomials Q1 and hope that their common
solution set is not too large.
These types of bivariate Coppersmith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's attack against RSA privaie key d < If02e [3]. Our ap-
proach is very similar to that described by Herrmann and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 57

0052

10 D J Bernstein, Y-A Chang, C:M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

bits known [9], although for the application we describe here, we are less interested in optimai
parameters, and more in speed: we wish to find the keys most likely to be factored using very low
dimensional lattices.

Algebrai,c ,ind.ependence; Nearly all applications of multivariate Coppersmith method§ require a


heuristic assumption that the attacker can obtain two (or several) algebraically independent poly-
nomial equations determined by the short vectors in a Ll,I,-reduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of common solutions. Most theorem statements in
these papers include this heuristic assurnption of algebraic independence as a matter of course,
and note briefly (if at all) that it appears to be backed up experimentally.
Notably, in our experiments, this assurnption d,id, nol hold in general. That is, most of the
time the equations we obtained after lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because all of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
vanish at the desired solution, but without further information, there are an infinite number of
additional solutions that we could not rule out. However, we were often able to find the solution
using a simple rnethod that we describe below.
Herrmann and May [9] describe one case where the assurnption of algebraic independence did
not hold in their experiments, namely when X and Y were significantly larger than the values of
s and r. Similar to our case they observed that the polynomials of small norm shared a common
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our case does vanish over the integers at (s,r) while / vanishes only modulo p.
We experimented with running smaller dimensional lattice attacks iu order to generate this
sublattice more directly. The attack worked with smaller degree equations than theoretically re-
quired to obtain a result, but when we experimented with lattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a useful linear equation
in the sublattice instead of the useless factor /.

6.1 Implementation details

Latti,ce construction: Our lattice is constructed using polynomial multiples of / and .lü up to
degree ,k vanishing to degree 1 modulo p. Let X and Y be bounds on the size of the roots at o
and gr we wish to find. Our lattice basis consists of the coefficient vectors of the set of polynomials

{.0{, oX.l[, f , (x X)2 N, (r X) l, .. ., (yy)r*' (r x) f , (gv )k-1 f ],

using coefficients of the monomials {1, r, A,fiZ,. .. ,Ak-tr,gk).The determinant of this lattice is

der "L : 1,',t+r 176y;(uä').

and the dimension i. (ol').Omitting the approximation factor of LLL, we want to ensure that

(detL)1/ai*t.O
(-t') (^t')
(rv,r+r xr )"
< Nr/z

So for.l[ = 21024 l setting,k : 3 should let us find XY < 2102 ut6,t : 4 should let us find
XY < 2128. The parameter choice k : 2 results in a theoretical bound XY < 1, but we also
experirnented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 58

0053

Factoring RSA keys from certified smart cards: Coppersmith in the wild 11

Soluing for solutions: After running LLL on our lattice, we needed to solve the system ofequations
it generated over the integers to find our desired roots. The usual method of doing this in bivariate
Coppersmith applications is to hope that the two shortest vectors in the reduced basis correspond
to algebraically independent polynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in uearly all of our experiments, this condition did not hold, and thus
there were an infinite number of possible solutions.
. However, a simple rrethod sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose because the short vectors in the reduced basis conesponded to
a sublattice of multiples of the same degree-one equation, with seemingly random coefficients,
which vanished at the desired roots. (The coefficient vectors were linearly independent, but the
underlying polynornials were not algebraically independent.) The other polynomial factors of these
short polynomials did not vanish at these roots. This linear equation has an infinite number of
solutions, but in our experiments our desired roots corresponded to the smallest integer solution,
which we could obtain by rounding.
Let
unluY-w:0
be an equation we want to solve for a and y.If u and u are relatively prime, then we can write
c7u + c2u: 1, and parametrize an integer family of solutions

fi-crw+uz
A:czw-uz
withz:czr-ctU.
In experiments with the already-factored rnoduli, we observed that the solution was often the
minimum integer value of r or y among the solution family. So we searched for z among the
rounded values of -c1wf u and c2wf u.
For the handful of cases where the lattice did result in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6.2 Experimental results


We ran our experiments using Sage 5.8 parallelized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, and Singular to factor polynornials and
compute Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear factors and looking for small solutions of the linear equations
as described above or using Gröbner bases.
We attempüed to factor each of the 2,086,L7L 1024-bit moduli using several different parameter
settings. For k : 3, we had 1O-dimensional lattices, and attempted to factor each moduius with
the base pattern a:0 using Y :230, X :27o, and t : 442.We then experimented with k:4
Y : 228 and X : 21oo, which gave us l5-dimensional lattices, and experimented with a base
pattern a - 2517 + 2sl0 and flve different error offsets: t : 0 with Y - 2L28 and X : 1, and
t: 128,t:228,t:328, and t : 428 with Y :228 and X - 2100. Finally, we experimented with
thechoicek:2,X:4,Y:4andthechoicesoftandausedinthe,b:4experiments,which
used 6-dimensional lattices and theoretically should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice k : 1 with
the same parameter choices as k : 2 did not produce results.

6.3 Handling more errors


Ftom these experimental settings, it seems likely that many more keys could be factored by different
choices of parameters and initial pattern values; one is limlted merely by time and computational
resources. We experimented with iterating over all patterns, but the computation quickly becomes
very expensive.
MAT A BSI-1-6c_3.pdf, Blatt 59

0054

12 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

k logr(XY) ff t ff factored keys f alg. indep. eqns. running time


245 105 3 4.3 hours
31001 Lt2 2 hours
4 128 5 109 4 20 hours
Table 1. Experime proach, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all of the other cases were solved via the heuristic
methods described above.

Patterned, Jactors: Mysteriously, using the base patterns a : 0 and a - 257t l2570,the algorithm
produced factorizations of keys with other patterned factorizations. This is because the product
of the bit pattern of the relevant factor multiplied with a small factor produced an integer of the
form we searched for, but we are as yet unable to characterize this behavior in general.

Higher pouers o/p: Similar to the univariate case we can construct higher-dimensional lattices in
which each vector is divisible by higher powers of p, e.g. using multiples of I{2,N/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of. XY only for
Iattices of dirnension at least 28.

More uariables.' More isolated errors can be handled by writing p -- a+D|=t2to s,i with appropriate
bounds on the si 1 Xi so that the intervals do not overlap. The asymptotically optimal case is
described in 19] and reaches similar bounds for fli:, Xi as in the univariate and bivariate case.
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottorn bits to generate a prime, the condition (det.L)di* t/z 4 p holds
only for lattices of dimension at least 35 at which point X1X2Xy I Nt/tq' can be found. A lattice
of dimension 20 leads to the condition X1X2X3 < 1. A sufficiently motivated attacker can run
LLL on lattices of these dimensions but we decided that factors found thus far were sufficient to
prove our point that the smart cards are fatally flawed.

7 Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the system for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each of the affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they informed us that they were not issued new
cards.
Several of the more recently factored keys described in this paper are still valid. This means
that MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart cards.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
longer responds to our queries. However, it is still possible to download Citizen Digital Certificates
from MOICA through a web-based interface under "Query of Certification" of "Certificate Ser-
vices" on http://moica.nat.gov.tw/html/en/index.htm. Interestingly, the Chinese version of the
web interface requires much less information to query a certificate than the English version.
We emphasize that the random-nurnber generators used in these cards obviously do not meet
even minimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problems until all of the cards are replaced.

References
1. ANSI. ANSI X9.31:1998: Digital S'ignatures Using Reuersi.ble Publi.c Key Cryptography for the Finan-
ci,al Seruices Industry (rDSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 60

0055

Factoring RSA keys from certified smart cards: Coppersmith in the wild 13

2. Daniel J. Bernstein. How to find the smooth parts of integers, May 2004.

,. 3'j:'#"T""'#ä[:TI'L*:äli:T::,],is orRSA with private key dress 16unn0.2e2.rn Jacques


Stern, editor, EUROCRYPT,volume 1592 of Lecture Notes in Computer Science, pages l-11. Springer,
1999.
4. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. J.
Cryptology, 10(4) q233-260, 1997.
5. Don Coppersmith. Finding a small root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, editor, EUROCRYPT, volume 1070 of Lecture Notes in Cornputer Science, pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Informationstechnik. Evaluation ofrandom number generators,2013.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-number-gener
and https://www.bsi.bund.de/DE/Themen f ZertifiziertngundAnerkennungf Zert\fizierungnachCCundITSEC/Anwendungshin'
7. Andrew Granville. Ha"rald Cram6r and the distribution of prime numbers. Scand,. Actuarial J.,
I995(1):i2-28,1995.
8. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. ln Proceed,ings of the 21st USENIX Security
Sympo si,urn, August 201 2.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYPT, volume 5350 of Lecture Notes in Com,puter Science,
pages 406-424. Springer, 2008.
10. Nick Howgrave-Graham. Approximate integer common divisors. In Joseph H. Silverman, editor,
CaLC, volume 2746 of Lecture Notes in Computer Science, pages 51-66. Springer, 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh Safavi-Naini and Ran Canetti, editors, CRYPTO,
volume 7417 of Lecture Notes'in Computer Science, pages 626-642. Springer, 2012.
t2. Arjen K. Lenstra, Hendrik W. Lenstra jun., and Laszll Lovdsz. Factoring polynomials with rational
coefficients. Math. Ann., 261:515-534, 1982.
i3. MOICA. Safety questions, 2013. http://moica.nat.gov.tw/html/enJT2/faq22-066-090.htm.
t4. National Institute of Standards and Technology (NIST). Security requirements for crypto-
graphic modules. Federal Information Processing Standards Publication (FIPS PUB) 140-
2, May 2001. http://csrc.nist.gov/publications/fips/fipsl4O-21fips1402.pdf, updated 2002-12-03.
See http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf for differences between this and
FIPS-140-1.
t5. National Institute of Standards and Technology (NIST). Recommendation for random number gen-
eration using deterministic random bit generators. NIST Special Publication (NIST SP) 800-904,
January 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime was found.
46, 0xc00000000000000000000000000O00000000000000000000000000000000000000000000O00000000000000000000000000000000000000000000000000002f9
7 , 0xc92424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424es
7, OxcOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO000000OO0O00000000000000o00000000000000000O00000000000000000000000000000O101ff
6 , 0xd24949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949dT
4, Oxf6dbdb6aldb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6d.db6d6db66db6b6dbb6dbdb6ddbOd6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbc1
4, Oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddbOd6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6c6e23
4, Oxedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbbOdbdb6ddb6d6db66db6b6dbb6dbdbdddbOd6db66db6b6dbb6dbdb6ddb6d6db66db6b867
3, OxdO84o84242 7O21OAOa42A4272108108484214210108408424210210808428421210810848421421010840A4242LO2LOAOA42A4212L0A70A4A421421010840985
2 , OxeOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoooO000000000000000000000oo0000000000000000000000000000000000000000000000000000000f
2, OxfSadsad6d6b56bSaSad6ad6b6bSabsadad6bd6bSbSad5ad6d6bS6bSa5ad6ad6bObSabSadad6bd6bSbSadSad6d6b56bSaSad6ad6b6bSabsadad6bd6bSbSadsd39
2,0xc28550a1285O0a14850aa14250a114280a144285a14228501428850a428550a128500a14850aa14250a114280aL44285aL4228501428850a428550a128500a6f
2, OxfdefdefTfTbdTbdedeJTefTbTbdebdeJefTbfTbdbdofdefTfTbdTbdedeiTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdef€0b1
2, 0xd249492449242492249292499249492449242492249292499249492!492424922492924992494924492424922492924992494924492424922492924992444a01
2,0xe94a94a5a529529494a54a525294294a4a52a529294a94asa529529494a54a525294294a4a52a529294a94aSa529529494a54a525294294a4a52a529294b9afs
2, Oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d7015
2,0xca52a529294a94a5a529529494a544525294294a4a52a529294a94a8a529529494a54a525294294a4a52d529294a94t5a529529494a54a525294294a4a52a601
2 , OxcOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0OOOOOOOOOOOOOOOOOOOO0OOOOOOOOOO00000000000000000000000000o00000000000000000000000000000000002030b
2,0xd8c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c69107
2,0xf18c18c6c631631818c68c636318318c4c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6s631631818c68c636318318c8c63c631318c1907
2, OxfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfZbdbdefdefTfTbdTbdedefTefTbTbdeqdefefTbfTbdbdefdefTfTbdE2E9
2 , 0xc42142!O!0840842421021080A42A42L2!OALOA4842142101084084242!O2!OAOA4294272|OA7OA48427421OL084OA4242702ßAOA42A4272108108484214369
MAT A BSI-1-6c_3.pdf, Blatt 61

0056

L4 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

2 , OxefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbd€fdefTfTbdTbdedefT€f7b7bd€bdefef7bf969
1, Oxd4e682e94f1d6O18aO2O56cOdb85Oa74b3591bof84O514ce4O17b2f5d25925ba2429a66e384b5be96e6a0a03d4a11€ba10416018d43b3€354477250037b6f813
1, OxcacOSbeScLeabfOc2lfSegSceSd3§O777g}4282d71d}c77ggd727eL97aOa32fda4cc59cc5Ob99d29f7fa8d07c972402ab88673e25sdb6bab05505812c73c2911
1, 0xcf052499061243cd82cd1b2059446c963487834d929ac929d92b259245254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4d144e242dbd
7, Oxtag4ag72e2dcffO68ee1257€228b53€9b9fcf46877r07dea4dL3c2bedr132d07730f549f4691f68553f84be8ff405f16a663d8fbAf82987bd9E073a8108edc3
1, OxefTbefbdbdsfgef6fTbdTbdegefTefTbTbddgdcfetZb3TbdgfeddefTbTbdTbdedeeOet3bSbde3deTedTbfa99ad€bdefTbTbdTTdTcffleeTbTbdebdeeetT9fBab
1 , Oxoab2919e1dc9ce33c2aodg6190465b164a53c7cO3e9a3dOO9ecf8fd6bdf743a04444332b7ff4aOe8f53b5123a5422563a06a487cd6cb5f36cd5411f0a€4dbc69
1,0xf51576€530188d5gbbc5f4f6€c9€824d7a9e70142952b11c49a6f38188adgdbe3d29d1d9498b7aeffc4d9b0420f71895f62e2a7b79d4887e45b6227eob84fbg7
1, Oxd83f22a49af67dZf196df58Od514464d6dbb88Ob03bea5Oddcc1f931ef7fO9aJ2f88ode26d88cbf24567302a0d6€ed7c8Eab859aa0c1cc18bd8efacdc€194c13
1, Oxc1dfge8dbSf7b7f456edc1f6Od23f6036O536565836ce37af6fO2e5sde24a8dc373t3c5d49c93ba6f€e0d44d08bcSfb0655781adeeScO5777ld4da2bcd8O3dof
1, 0xe279872638463a0a32a1412b13efccfa5ed68db44963c7f6955a3816bcaa33f94794c8b75298ddf4a86646485e199e6d9469f5187939e395cb1f09e666786741
1, Oxce73e73939ce9ce7e738739c9ce7ce73739c39cece73e73939ce9ce7e739739c9ce7ce73739c39cecE73e73939ce9ce76739739c9ce7ce73739c39cece73oad7
1, Oxdg2ae5c6453efec55c56142O7827d.e2b77btgef,271423Otgaaclf.dgbOd69fdc61934132766fedd1d8cb22ec38d834037eff6dgdd3535b9€582fbdd2327c9ce5
1 , 0xc080000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000001003f
1, OxfffTfffffeffffffffffffffftffffJeTffffffTffffffffffftfffffffffdTffffffbffftffTbfffbtcffffTftfffffffbf00000000o0o0o0000000o00000cl
1, Ox€b6f80ff65b4a6d462cfa5961r542f25e207667752b0482f5ac9dc091f4dc854de9c73b288aaasda5298a33928f7b2920f89b81e3635932bc9db99a34652b82b
1, OxfdfTbgbffbffdobeb2Ssg2bT6f6gbbffbffdafa6ffdgfTbdIl€€7bfa6e2f33bb67d5a5b5676d2bf6a1de3626fO6be367ffde73db1eO1fSd3855f21fbeda8b4db
1 , 0xe643203b22b4048427210bd390d45a3a62ac132c0063990067686123d50128812e09411f27098400c841e09183400431018100a2b1cc0954c0405026420e8c7f
1, OxffefeJTffde6ffffTfftffbtffffffbffeffbffdffffffffffifffffffffffffffffJfffflfcffffef46fffdfdfffTffffffffffffffffffflfeefefecEffeSd

o 1
1
,
,
1,
1,
Oxf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66b37b6dbo19a4697
OxcOOOb8OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO00000000O68000000000000000000000000000000000000000000000000000000251
Oxccc5ebfea2f4bebSb62df€f5429f97f06afOaf8d08159d21df454OaO197ffdb8386cBebb18bd70b0f46c9615d2fcd0ea38a2cadb522ct7gL2c3ab27d9564a197
Ox6db6b6dbb6dbdb6ddb6d6db66db6b6dbbodbdb6ddb6d6db66db6b6dbb6dadb6d9b6f6db66da6b6fbf6cb9b7ddb656d9eOd36a7dbb673ba6ddb6f6db66dfObSes
1, Oxe7fa15ab6cgd2c3d1396Of598cd2bbf74a68858O65fdc70O64563a1O558f1dftl36d5e8aec88897c79d73ebdcbec1b5tO121176cBaae69e3a31a63f9e66eObfcs
1, Oxffb3O8867fee16267feb2b1at2L2ffetttf,te43O8866fJfSfffef613ffcf869aff4bf907ff1f9393fff0fffgfffcfff7ff3et703ftaa8c7ffffe491affeff3b1
1,0xc010208a48c1802121081084842L423OLOa4OA4242006309ca468d2123081q84a520431O0Oc4Oa4252LO210a084a9ce1290810cc84204a9011ac28424O1O22a7
1 , Ox€739729c9ce7c€73539c29cec126e7383b8e8gbd2207faedO8428421318c1084c410631858c68c63e31035cc8c63ce31318810c64331231818c60e63623b32a3
I , Oxfeb1b9efa29f64ed53628a1Oa924b5268163dd887f653a6b82edbo63b6874c2O39e4938O18ab949a3c28cdc785fe2be58872c0c8a9ec5171e37ea6a82d5d46d7
1 , 0xc010000O000000000000000000009000004260400c000000000018000000000040208000000000202000010800000000000000000000000000028000000002f3
1 , Oxf9d5834f918b673e1f7eaae3cc5d97dd27O6dd8de9cSb2fbef679b2c196933fe30f62ac3f7fcc1c593fb63a0bbb8838b8486aac959cc3949ea9182c46396fbcb
Oxdac45d37aadacfec73b3184ef43d52d6314754abd38414ddeOgade396bd8O9aa281 1047f015c9c7lf0cbb0a91028190adeacc36165b0e0e6fce64549f947E0ds
oxf49808713746a41a331625a7cb389611€aa3905984246f99e828f 17f867413ctaegL23O478715024db5ead44bsb20rbc73a23a27Ld627a7L747b6423f753ebo3
Oxd67a7b1 1 1c0401971f57806a2be12a174b8923fd3972Ec64fe3de3€e96594a14207831d12f 16i545851cad6356bb16221bee686b2f€e9427e0da0caSf98e6861
Ox€83071df5288c373asbc43fb2O3O9e25e99fd85b61a9a4e6f3f7151 1b98t7ec87O47fb32520d94cd7753dbe173304445cae48231f601dd19d3cd40c74190c77d
0xed4294b5a529529c94250ad35394214a4a52a569a94a94a5e56b52948c ü4a52529429524a5aa529294a9ca5e1295294d4a74a7 27394696a4a13a529236a968d
Oxd621eb6eSab7992c6efbaSf34a7b7b28O26fc93138998c113831dbaaaca1a15738a7b7agd191bcd77955b92b75263adgf6bbd4c€0b4edca1efd5f3e24b3a2889
Ord9a43ffO58df6b8d55O85028eac413a7439€1dc89eSd6e8bSd€09e7bc7483d762788ff9€36527ff67c39360cfc0d2a75986b7tb35614027cffb932es1 112€e8d
Oxe492924992494924492524922492924992494924492424922492924992494924492424922492924992494925492424922492924992494925492524922492938t
Oxf9cf9b29d767edb655b2f6bf964bce697f652fb669b322eb63dffb6e7a6c6gbb798396d284d85169883d42a6ec96b292761d6dcd7ab595b2adoa9a5d7697fe41
Oxfffefffefffffffffffefffefffefffefffffffeflfffffefffefffeffff{ffffffefffefffeJffefffefffefflfffff000000000000O0000000000000000obd
Oxf9cegce7e738738c9ce7ce73739cb9cece73e738398e9ce7e719739c9ce7ce7373dc39cece73€53839ce9ce7 e7b9739c9ce7 ce7 3739c39cece73e73839ce9d63
Oxds3bd2f 169ab7fb38abb7fOScb155Oe2OO914674b65ce176OO1lfeb2gdbd1e90c21a77e28c6dbfd6e6a782baaba532e2a98eff9edge924986at7O2c48504d0d1
Oxc3668f2addb6o2d9d18b2bO4Obc7aOObc7O46b203Oc2d3e91c4c161ed562a31d2d056afc769O42a46c28e2!8e25e7 c7882l.blcb2d66039ed961dac65€a69c5d7
Oxed15cbofde1567b278ef2422ea}16d658173594bObcb71594a18df455fc75ca7c5b529bb6b9ec229b€6ba977773eca917äc08a1e9f557atu079abBbceb2bc01b
OxdoObOdd78fd35c88db318O6803799deab89b8b36c39dc0321574801fb936f90e2920f3dd6540oddc00b€90ebceldd62dSc6c062c200bdb04aa6aSacf697e2a0d
OxdOO54c94O2O831e8O045OeO581 1840282088a906825002d9a0c340938dc0b20628072f800334102c08010309cO20800710200c044604083700aa440088411987
Oxc7592d7dc9ee1031dcd3A3Of43O288583OEac46ac981cafa164a8OOOa9c6E€b698181505242ac9dfes9e51c92460b987dbc8161def71863d35ac 18fa1235a903
OxfffbfcfTfZffdf3dfffefSffffffbfffffgffffffffdffTdffffffglfffffEfTatffffffffbfffdfffeffbftfltffl.tfffttTTtrfdffflfffffff lffffflfft3S
OxfSebOSd73ad4df3cdaf4fd2eaf41eBe405952b7a327479147fffa33eb829039e77ff 1 16f9€4958a3f604743ed2c5sba67b4763184290sdbc2f12c66fb6c4s40f
Oxc3ft4d3O4T4f4OdfOeTffffdfag2ffff 1 1d59d35d214tfff85c357cSc85Ed72acaf1fb7d43f76d85e€6b4fb3ffdd60d5095ef 1f290aU4ff888e7637efE4J9eBf
Oxcc7b18295347824ccb395bed351993c598c7cf7f4e32dcb9ab7a5d7€0baa7626d1b8dc651b34f5E4f5d3f2530b52fbgbd10s75259b36d774f059141bf96de91 1
Oxe675a7O59b1e6df2O198fBa75aOab28123fff79a67f59c7049ld37d48128J3b3a9b69475b902f4bc854ca1d€ecbce73cdab89b17ae3c6401a9d43594775a926b
Ox€f7b77bd3defdef7f7b47bdedef76f7b7bdebdefef7bf7bdbdee7€fZb73d7bged6f7ef7b7b9e3deeef7bf7b9bd€fd6ffffb9TbdedefTefTbTb9ebdafef3bfS4S
oxfd23b110962O00d598488c43407369898cd0086df780826dcfa14784f38388874362851b7711dc13564441351335c71fbd7c564d5d5008fsde20d4312476dTrs
Oxe918f 165879091 1a71a9ae1895cfe56ttbed767816e337e2f95O462aftb328OdBa8dcb124O62Oec8f 1d19c375Oafcfei95c58cca1 17b36632414cd9e114fdb097
Oxffffaa55ffffffffff3cd9fe3ffff676ffffffIffffeOOOOOOOOOO0OO00000000000O000000000O00000000000000000000000000O000000000000000000009d
OxcO21OOO048041OOOOO1OOO1OOO80OLce2O64OO4242c81218625O154cOO000088ba78008a43a9713bc0abb849220e8362cc838b53cf88f,cdbdd7fca83c8df8145
0xo318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c0c63c631318c18c6c631631818c68c63631831d3
Oxd5O1973162d4O17f4e3b3c9d68O3d4cc46a1d457c91fsb5b6c2a€77423ba41c9cfbd5f4b9235667874507e9cafb4123e1992d1c5ae75ee295087017a822a6cct
Ox€28ecce1de7a0326423076465160c1b03f8e721181e046ef4860ae94d7802a082f9f6007c001 1f20056de200677aa7d8a471 18e6692ee4b3f862c24e04b543b5
Oxda2f36d74bc2dc29ds4de92f4b37bo3942173e15a2dfb67eBfO9e79Oed1656afSa8aad€f14b696426f 1€929699da0ee3adgf21a9f66edg57d945fc165b27d217
Oxd2855Oa3a852Oa1c85Oaa1425Oa1 74ba}a744285a142285}742Aa50a428550e12840Oa14850aa14250a114080aL442A5a7422851 1428852a4686d0a128500a2d
0xE79082499b094b2459266493608a9249b241odi}409242692a490824d934941254935266a341086119449d824691524922697926bb24949044027108a8c939asd
Oxedfc3T3fTssffbfffTfefed3fffaJffefffdSfrfffderffsffdffffSffSffffefefd3fefTfbfSüff613bb59f9fbSfSbds2a6f,d78ebddfä6edeeff€3t3rb3dfs
OxfffT1fb6fbfffefffffffeeffff€efffefTfffebfffefffffftfefffgfffffcbfdbffOfaffffdtffTfT€dffeeTadtffafftbfbTefJffdffdeTfadJd€f63e806b
0xcaf67d473c1Of 4e73d6678d4a27e4eb}4a743926d72c31f97sfa51Oca68558b2c56d839acecb€75e935f86iec7da07c95aa0b93065aSaag24694fdJb9f521535
OxfOb43e3bd5284 1756dLa27t22a8590a8a1c43c1c36b95cc72d0102f26b6da1b238236856f7c6e6faa83cc70e84f2db44088487fd94a175f22a0d990cc1af€a6b
Oxd2a2Od1b986de2152b9d93cf6Obf98f68e9f9EO5Ofeb982ObOO6eSdc581f 17a82f36a78d23fb34fab3962ae9sbcr3a1e442eb5b1d72cd6966fa599483Eee38c1
0xe62e529494a54a635294294a4a51a509294a96a5a529529494a54a52529d29ea4a52a522298a94a5a522529494a44a525294294a4842a52e294a14a5a52f554b
0xc942c4644b1 169461581e0713ba400570237a55c9ae69€3fo58d189&a751d218208421934f2132a888e796bc1f0914a8c9b4f 116358cca22c69c35596bdg61es
Oxed7f7e78afc7d3735fc 1dfbOd13887cdatcd715c9f€S3OS3OeOelceaa4bcaffbaebacg€6O1623db36fffef47fffffefffffffOOO00000000000000000000003ed
Oxf6db9b6dda6d29b61df e73dbba5bdb6ddead6gbeedf6a6dbf7dadb6ddf6c6cb66db6f6dilb6db9b64997c6dbe6cb4364b96dbdb6ddb6c67be6da4b7cbaedadf35
Oxc08Oa1OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO03OO800O8800000026080200101200044080010042020800008000000500O0000100000000900e1
1, Oxe5335I76a97c5e29d455717Ocd9et3ed53efc819fda87a566a5ef€247ef 1O2b85c7adg0c484ade030c7ebc23455eodcbca2cec6afdf0e8c978cb6fbed5733fa5
OrcOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoOOOOOOOOOOOOOO00OO40000000000000000000000000000000000004000000000000000000O000O000000165
Oxc924249324929249b2ct49244924649264927a4892494936593320b93f 9292e992497d1449242492229293499249492449262493248e96fff3c9104432f4cdbb
1, Oxc9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
1-, 0xc00000000O0000000000000000000000000000000000000000000000000000000000000000000000000O00000000000000000000000000000000000100000177
1, 0xc00000041O0240000508000802100004900000010000O002080000000O01021O05180000000000000000210080600040082000400000183001000000200020f1
0xcad0ca7166b2aaf6c82b0eadfeb13409da7c2679517d4Jd96f89719659133e0492d209da600753dcSc2570ce128cf985332f944143204b706bf6o990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 62

0057

Factoring RSA keys from certified smart cards: Coppersmith in the wild l5

1, 0r€739739c9ce7ce73739c39cece73e73939ce9c€7e739739c9ce7ce73739c39cec873e73939ce9ce7e739739c9ce7cs73739c39c€ce73€73939ce9ce7e73973a1i
1, 0xe0929249924949244924249a249292499249492449242493249292499a49492449342492249292499249492449242492249 24992494924492424922482926t
I, 0xc000100000000000000000000000000000000000000000000000000000000000000100802000cb0040908809180008c8000000010c00012101b20000000002ad
1,0!cec727009ef07418dc89e2c96a796d44bc2244d88a0bb8ca90b4d661736b486b6e1at8352a22a4697cdd0702a3d8b7c4b23ada2286s2at09234a71346ba141795
1 , 0xc8dce72cOE38ecaf2e3e11ael07326e3431a92ad87€f296d3d0b5d4bgd00646bebd7b3afOcga424e074e7ß6d186aD6997a4d9c131acb624881aecace287c057
1,0xe609f0b€62014c7299e188527ab8cd00a1809c631f1fd50a20013331678ccad20631879842b8a1226696b18c4b1dd5e4b1lbce7a14f4a€76973debf4ca768c4bd
1 , 0xd66cdaeet276brd3d1Ee6sdf430dd7aeo16bd0€9a5e4:|89067835€2a2a0tb702703d6c3fd50d591713ba77aeb851c016d26135d754c114adf303d091600462bd
1 , oxlat47€a58caldaaabs6dfaO4ff891009db3fl37e1272d573b7a3da53g4f24f9612fda7tf4f763a72482a0edffa91400O1aae2115a64fd33of93e819ag68acatb7
1 , oxf718c0bc8c57cc318c99fa16236191a531828a95856d6ac833a7€3a2110dded25226ea4344cabbb2ro19de1486.3b8c46631b44038c87€8ce4aea42a10atabt91
1,0rd86d99e183ba3c0870238db37t1d31673cd€c3112196acfe1239667bcb3a3a7f6749f3229f550d5097510e8asdf0626a641e2112112f95080c5629973b1c975
1, 0xfc1fc95€€7482142bccb7f0bc5cd674ad82edca61fe2653c78622€ö673485cc11c993aaseb16t77d90dfe1c6a945s239ab47aSca3€b2aeb702f2de36626858db
1, oxf7c6bf218fcfadcba926ac5efdf60f97aeba8d5f70ceb27€tt0tEd67e763bfe86dc7a86ee76b8bagd076bf laAr4a7t cfb02g7 a96c6cEa706a7e5s3c38326fl83
1, 0rc594391€8eAc24c8^7fe97Ld78db784d43c96ba3384102act7!rc2606736c65f7c4&f6c3bbf7b05659b954c0b9c696t61t8c900b66cSf3c401647384ad4de577
1,0rda975410693d3120b32997c8c728f09d09610f5tef089a7cr63tf1dct673ffifb493c19c6416700457646aabaalt340gf,9648ft7c390c25d4a8a0d7c9b2f16b2d
1 , orf16teadgat03cfcb36571b8b3feBcf24e313aece858b7d4e800838329c9b729ecc6d691dl4e08647agldb18debbca338at8214fale03ad53fBega0503blb6735
1 , oxddf3b56a7bb556afa1476addb54aa95e569c94ab62d5ta95c054af04b5a3b56adff5562dbb466ed1b56aad5a1629cEa93ad66bfsad1e3ba4€5ab9722dal5d7bd
1 , 0xd9958{e30334b89c8c02ac210c4dc8€6e610d1c958cb4d436e11aed60f72egbBa88e18b7c663533218c68ed560b031ad4ce38aa13bbc1ob6c73f€3911accBde1
1 , 0xfcb0663el5€3c922936834039rd787aode9fdd178017021129cfbs92570fd:lcSe60787fc59128bcesbfcb38b€0c064b08c087fd8fe6b960207c93ca4cf3c5add
MAT A BSI-1-6c_3.pdf, Blatt 63

0058

16 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

B Appendix: FIPS-140 certifcation


Searching for the term "FIPS" on MOICA's website (http://moica.nat.gov.tw/html/en/index.htm)
returns the following entries in the FAQ section, all of which claim some security through FIPS
certification.

g-:
qtr,
o Crttflcrto egt{lortty ol ml
ü-

A hE iry*rbt" ," Eou Cenifcue IC cad. ,1 privae !

tey praE&! i5 flr:aßd in"!'Cl-q,(oglaPhi( l{oäd.r thich is tsilizr§ :

ldre RSA *d rudon gzreraot: A pritate lev is u$d ro «ede, ;

FNQ ,prffi, äd i(qe Bridu


io HSl,l. TIr lC rad actordwe rith :
IFIPS t.+o't !a,el ? ratifiable hy Ir cärd nüagrnam cenle, and tlt€ i

jc*d pc*s higtrr secruity. A Pr rvat€ k€y is (reattd ia§ids ildü0 ,

tprirxe ke! car r cxpm tou IC ca'd .ho Iß-:i o €tEd.


.l,rh s lrigF ritli ao sore catilicac ir tht floppy disk rh* cm raltin8
'rop) il ilti tiDe. ltre Citizfl digiral cerü6{ile PN§ FIPS 140- I
'aduir.r lesel 2 erd hale Ligfr reuity. Pl ivae ke] ca t be cop!
FAQ
l&or IC crd afrer graet atr key pair of inside tlrc lC cad. ILls
ratihc;lt level. is f.i09 V 3 fte Fslicy of ritiro ö6ital rarificae
lüni ( utiflcäre i&orrJd ldd ilxo lC Ca'd
:Ä i.lääri«, äi efuorcl.'rtr ic .ad is ltgi s«mitr od ir
l

LAq :tme bro racditcd to FtP§ t,{}-l lerrl ? md the crd ruc, is used . I
:b_9_up: ryffi,
ilds{se iD HSlu.
'.:t:tüe c.l tey pairr e gßn{r.ted wdt}is hrdwue ayprog4üic '
ino&rlrs q mftrrrerlu drtae cryptograpLit uodrrles wiüirr de IC .

o rAQ
lcad, ue«injteqrirendts of CpS andFPS 140-l leEl ?
i9$$-9$o1-qr1 3n-pa drle sgc'q§ go-d',tc c.*l!
A:TIE Ct k !6 üe cre.r€d iD a cryprographic Dodrle. Ning RSA
,algriör ad radon runber gm ao. Geatcd wiüin a h*{r+ac
,so&le, &e fivac key it frsed itrEide wftLolt leekäg!. uore€vcr.
F,\Q
c«iEcre qö«riber's Ic cild i5 ixrorlally gema{*ÜE§ f'ß
I ley€l ! ceilifictio[ of &e C{d Crü§. The priYtl!
,oqu.t dio-.getwrtiar
li,fii"lrgi r.Eu".i. od o the carier for dc
ca be exiLy <opied ad dF lisk i§ bigh
adoric*ior, dE (atifirafe IC cild is tilFb
F,\Q
ibciaarrao'ared inrmeuy afts which r prtrlE
opqted nor repliratrd. Subscibd'r iüld
ify_i§-.-"f9t{*y9.rcrio-X.5o9 !3 lcvd
- __*

Tolal6 Page I r1-- [t{od m I I hry 20 I

{-l
MAT A BSI-1-6c_3.pdf, Blatt 64

0059

Public-Key Cryptanalysis 2:
Random Number Generation Flaws

Nadia Heninger
University of Pennsylvania

July 21, 2013


MAT A BSI-1-6c_3.pdf, Blatt 65

0060

What does cryptography look like on a broad scale?

Methodology:

1 Collect cryptographic data (keys, signatures, ciphertext...)

2 Look for interesting things.


MAT A BSI-1-6c_3.pdf, Blatt 66

0061

Data Collection
MAT A BSI-1-6c_3.pdf, Blatt 67

0062

HTTPS

Public keys are used to:


> bind domain names to certificates
> sign certificates (for self-signed certificates or CA keys)
> encrypt sssion key information (in RSA key exchange, most
common case)

A compromised key could be used to:


> Man in the middle connections.
> Decrypt passively collected session traffic (if connection uses
. RSA key exchange)
> Sign new trusted certificates (if it's a CA key).

o
MAT A BSI-1-6c_3.pdf, Blatt 68

0053

{o Collecting HTTPS data

EFF SSL Observatory published certificate data from a scan


of lPv4 on port z[43 in August 2010 and December 2010.
Open port Handshake RSA keys DSA keys

16,200.000 7,700,000 3,900,000 1,900

We performed a similar scan in October 2011.


(Heninger Durumeric, Wustroar, Halderman 2012)
Open port Handshake RSA DSA ECDSA GOST

28.900,000 12,800.m0 5,600,000 6,000

Alex will talk about horru to do this kind of collection efficiently.


MAT A BSI-1-6c_3.pdf, Blatt 69

0054

SSH

SSH host kep are used


> to authenticate hosts to clients.

A compromised SSH host key could be used


> to man-in-the'middle connections (for SSHv2, most common
case)

We scanned port22 for SSH host keys and handshake signatures in


February and April 2012. (Heninger, Durumeric, Wustror, Halderman
2oL2)

Open pqrt Handshake RSA DSA ECDSA GOST

23,000,000 10,200,000 3,800,000 2,000,000 150,000 . 7


MAT A BSI-1-6c_3.pdf, Blatt 70

006s

PGP
PGP keys are used to
> sign and encrypt email messages.
A compromised key could be used to
> decrypt messages intended for that person
> sign messäges or other keys as that person.

PGP public keys and signatures are available on public key


repositories.

Several PGP key repository dumps available online.

RSA keys DSA kep ElGamal keYs

700,000 2,100,000 2,100,000

(Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter 2012) analyze


PGP data. (As well as SSL observatory data.)
MAT A BSI-1-6c_3.pdf, Blatt 71

0066

Bitcoin

Bitcoin uses ECDSA.


A compromised bitcoin key could be used to
> transfer bitcoins from the compromised account.

Addresses are public key§, and block chains contain signatures.

Block chain is transferred to clients connecting to the network.


Can also be dorrtrnloaded in bulk.

January keys transactions


2013: 187,000 23,,t61,500

(Analpis in Moore, Wustror 2013) and (Schneider 2013)


MAT A BSI-1-6c_3.pdf, Blatt 72

0067

Taiwan National Citizen lD Smartcards

Many countries adopting national PKl.


Taiwan's smart card lDs allow citizens to
> file income taxes,
> update car registrations,
> transact with government agencies,
> interact with companies (e.g. Chunghwa
Telecom) online.

March 2012: Collected 3,002,000 certificates (all using RSA keys)


from national LDAP directory.
2.3 million distinct 102+bit RSA moduli, 700,000 204&bit moduli.

Analysis to appear in (Bernstein, Chang, Cheng, Chou, Heninger,


Lange, van Someren 2013).
MAT A BSI-1-6c_3.pdf, Blatt 73

0068

Cryptography relies on good randomness.

lf you use predictable randomness, an attacker


might be able to guess your private key.

End of story?
MAT A BSI-1-6c_3.pdf, Blatt 74

0069

O What could go wrong: Repeated keys


RSA Public Keys

N : pQ modulus
e encryption exponent

> Two hosts share e: not a problem.

ltunrt er of C.rüG Expor.nt


I Ntrmb:r o,
Ct(s

t=L_-r---
r ^ - L--,
rl;s*d,4al-' r6rrlo6ie'po!if!yrt-ro'6rd'-^d."if6,$-;fiSlf,.s
MAT A BSI-1-6c_3.pdf, Blatt 75

0070

O What could go wrong: Repeated keys


RSA Public Keys

N : pe modulus
e encryption exponent

> Two hosts share e: not a problem.

> Two hosts share N: -+ both know private key of the other.

Hosts share the same public and private keys, and can decrypt and
sign for each other.
MAT A BSI-1-6c_3.pdf, Blatt 76

0071

What could go wrong; Shared factors

lf two RSA moduli share a common factor,

Nt: PQt Nz: PQz


MAT A BSI-1-6c_3.pdf, Blatt 77

007 2

What could go wrong: Shared factors

lf two RSA moduli share a common factor,

Nr: PQt Nz: PQz

gcd(Nr, Nz) : P

You can factor both keys with GCD algorithm.

Time to factor Time to calculate GCD


768-bit RSA modulus: for 1024-bit RSA modulr
2.5 calendar years 1Sprs

[Kleinjung et al. 2010]


MAT A BSI-1-6c_3.pdf, Blatt 78

0073

O What could go wrong: Repeated keys


DSA public keys

Public key
p prime
q prime, divides (p - t)
g generator of subgroup of order g mod p
y:g* modp

> Two hosts have same public key -+ both know private key of
the other.
MAT A BSI-1-6c_3.pdf, Blatt 79

0074

What could go wrong Weak DSA signature nonce

Public Key Private Key

p. q. g domain parameters x private key

y:g* modp

Signature: (.. rt )
r:gkmodpmodq
sr : k -'(P(rr) 1xr) mod q

> DSA nonce known -+ easily compute private key.


MAT A BSI-1-6c_3.pdf, Blatt 80

0075

O What could go wrong: Weak DSA signature nonce

Public Key Private Key

. p.q.g domain parameters x private key


y -g,modp

Signature: (.. sr ) Signature (r. t )


r: gk mod pmod g r: gk mod p mod q
sL:k t(g(rnr)*xr)mod q s2:k l(H(mz)+xr)modg
> DSA nonce known -+ easily compute private key.

5r - §z : k-L(H(m) - H(m2)) mod q

> DSA nonce reused to sign distinct messages -+ easily compute


nonge.
MAT A BSI-1-6c_3.pdf, Blatt 81

007 6

Do we actually expect to find key collisions in the wild?

Experiment: Compute GCD of each pair M moduli randomly


chosen from P primes.

What should happen? Nothing.


MAT A BSI-1-6c_3.pdf, Blatt 82

007 7

Do we actually expect to find key collisions in the wild?

Experiment: Compute GCD of each pair M moduli randomly


chosen from P primes.

What should happen? Nothing.

Prime Number Theorem: Birthday bound:


- 10150 512-bit primes Pr[nontrivial gcd] = 1-
"-2M2/P

i6" Earth's population $atoms in Ea*h fatoms in universe


IJ
"0 1
.9 i

.:
L
+J
E.
o (.1

F 1 10ro 1040 1060 1080 lgroo


#moduli M
MAT A BSI-1-6c_3.pdf, Blatt 83

0078

O How to efficiently compute pairwise GCDs

Computing pairwise gcd(rui, N;) the naive way on all of the RSA
keys in the above datasets would take

15ps x ('- ;'ou)0.,r, = 11oo vears


of computation time.
MAT A BSI-1-6c_3.pdf, Blatt 84

007 9

How to efficiently compute pairwise GCDs

Computing pairwise gcd(M, N;) the naive way on all of the RSA
keys in the above

of computation time.
MAT A BSI-1-6c_3.pdf, Blatt 85

0080

Efficiently computing pairwise GCDs


We adapted an efficient algorithm due to [Bernstein 20041.

ilr lYz iVs Nt


\/ \/
xx
\\/
ivrltJ
IVrlVzIVrIVr

tq
.od.NfM
Nl rufrr{
modtrl

/\
Itß
I )*'-"
f
Eod/Vr'.
,N? moaivf nod,ltif
modl ß rnoa{
I I I t
/Nr /Nz /ut lNt
,a(l,iv,) rr) s"d(l,lro)
,) e"a(l,lv, e"a(l,t,Ivg)

O(mn polylog(mn)) time for m n-bit integerc, a feur hours for datasets.
lmplementation available at. https://factorable. net.
MAT A BSI-1-6c_3.pdf, Blatt 86

0081

What happens if we compute GCDs of some RSA moduli?

What does happen when we GCD all the keys?


MAT A BSI-1-6c_3.pdf, Blatt 87

0082

O What happens if we compute GCDs of some RSA moduli?

What does happen when we GCD all the keys?


Compute private keys for

> 64,081 HTTPS servers (0.50%).

> 2 459 SSH servers (0.03%).

> 2 PGP users (and a few hundred invalid keys).

> 103 Taiwanese citizens.


MAT A BSI-1-6c_3.pdf, Blatt 88

0083

O What happens if we look for repeated DSA nonces?

Compute private keys for

> 105,728 (1 03%) of SSH DSA servers.

> 133 Bitcoin addresses.


MAT A BSI-1-6c_3.pdf, Blatt 89

0084

O What happens if we look for repeated keys?

> 60% of HTTPS and SSH hosts served non-unique public


keys.
MAT A BSI-1-6c_3.pdf, Blatt 90

0085

What happens if we look for repeated keys?

> 60% of HTTPS and SSH hosts served non-unique public


keys.

Many valid (and common) reasons to share keys:


> Shared hosting situations. Virtual hosting.
> A single organization registers many domain names with the
same key.
> Expired certificates that are renewed with the same key.
MAT A BSI-1-6c_3.pdf, Blatt 91

0085

O What happens if we look for repeated keys?

> 600/o of HTTPS and SSH hosts served non-unique public


keys.

Common (and unwise) reasons to share keys:


> Device default certificates/keys.
> Apparent entropy problems in key generation.
MAT A BSI-1-6c_3.pdf, Blatt 92

0087

,O What happens if we look for repeated keys?

> @olo of HTTPS and SSH hosts served non-unique public


keys.
:

Common (and unwise) reasons to share keys:


> Device default certificates/keys.
> Apparent entropy problems in key generation.

HTTPS: SSH:
defaultcertificates/kep: defauh or low-entropy kela:
670,000 hosts (5%) 1,@0,W hosts (1070)
lorr-entropy repeated keys:
40,000 hosts (0.3%)
MAT A BSI-1-6c_3.pdf, Blatt 93

OOBB

o Classifying repeated keys

U)
f Devices

o IHosting providers
a
C) E Unknown/other
o
L{
o
§
z

50 most repeated RSA SSH keys

o
MAT A BSI-1-6c_3.pdf, Blatt 94

0089

... only two of the factored https certificates were signed by a CA,
and both are expired. The web pages aren't active.
MAT A BSI-1-6c_3.pdf, Blatt 95

0090

... onlytwo of the factored https certificates were signed by a CA,


and both are expired. The web pages aren't active.

Look at subject information for certificates:


cI-seu-BigDed, c[-syst@ g6erat€d, ct{-016812200800002,1
Cl{-6€].l-slg!ed, Cl-ayateb georat€d, CX-0152092009003221
CN-se1f-819a€d, C[-syats g@erat.d, cN-01621?20o8o01051
C-CI, ST-C@gdong, o-lP-LIilK Iecbslogl6s c0., L]D., oU-TP-LIIK SoFT, Ct{=TL-M78+1145D6C30089/@ailAddr6.
c-Ctl, ST-clEgd@g, o-TP-LIIIK Techlologlea CO. , LID. , ou-TP-LIN( S0rr, CT=TL-M78+139819C30089/@uAddre:
clt-5e1f-8tgaed, cN-§yEt€D g€nerated, c[=016207201r.000074
cil-s6u-sigred, cl{-EysteD t@6rat€d, cil=0162122009008149
CN-seu-algDed, Cil=systoE g@6ratod, ct{-o162122009000432
cil-seu-slgned, cl=ayateD geerated, cil-o162062010005821
G{-Belr-a1g[6d, CI=syrteD gstr6rat€al, Ct{-0162072008005267
C-US, o-2ulre, ou-Catoray Devic€/s6rlalNeb€r-360617088769, CI-Gatesay Authettcatlo!
C['eelf-e1gEod, CN-§ystoD g@qated, C[-016208i1009008123
CN-8€U-slg!od, CII-ayst@ g@olated, CX-0162072008005385
c[-sou-siga€d, Ol-syst6 g@6rat6d, CI-0162082008000317
c-cl, ST-cuegd@t, (FTP-LIIr Tochuologles c0., LTD., oU-TP-LuII( S0rT, CtI-TL-R478+3F5878C30089,/@allAddrer
Cll-8olf-sigrod, Cl{-systets Büorated, C[-0162072008005597
ClI-sou-s1gnod, CN-aysteE g@elated, Cil-0162072010002630
CN+ou-slgr6d, Cll-syateE goerated, Cil-0162032010008958
CN-1O9.236.129.114
Cll-sslt-stgned, Cl-systeE g@elatsd, CI-0162O72011004942
cil-217.92,30.86
cll-ss1t-aigE6d, C'tl-syst@ g6e!äted, C11.016211201r.00019o
Cl{-8ell-8ig!€d, Cl-syst@ g@6tat€d, C!{-O162O620O8001934
C'N-Bou-stgled, C!l-8Fte g@€rat€d, CN-0162112011004312
Cll-se1l-sigiEd, C[-systd ge€rated, Cll-0162072011000946
C=lrS,ST-tlreg6, L-lrtilaoEvXlle, CN=141.213,19.107, 0-X6ror CorporatloE, 0u-Iercr 0ll1c€ Bui!6a6 CrouP,
CN-IRIoOoOAAD53FB7..€cs.uich.edu, Cl{-(1ll1.213.19.107lIRIoOoOllDs3FB7.€eca.@Lch.6du)
CN-8€Lt-ai.gEed, Cll.ayBteD g@elatod, Cil-01621020110O1174
c[-5e1r-§1gnd, cl-8yst€D g@erated, cil-0168u2011001015
T-::I-:18p:i, g':v::- c*:"d'l, g':*:9*:11:99:i9
MAT A BSI-1-6c_3.pdf, Blatt 96

0091

Attributing SSL and SSH vulnerabilities to implementations


iO

Evidence strongly suggested widespread implementation problems.

Ctue f l: Vast majority of weak keys generdted by network


devices:

*r
> Juniper network security devices
> Cisco routers
> IBM server management cards
> lntel server management cards
> lnnominate industrial-grade firewalls

tdentified devices from ) 50 manufacturerc


MAT A BSI-1-6c_3.pdf, Blatt 97

009 2

Random number generation in software


O
\
crypto keys
MAT A BSI-1-6c_3.pdf, Blatt 98

0093

Random number generation in software


E\p
crypto keys To generate random keys, we need a
source of randomness.
MAT A BSI-1-6c_3.pdf, Blatt 99

0094

o Random number generation in software


q
\r
crypto keys To generäte random keys, we need a

t source of randomness.

@,
application pseudorandom
number generator
MAT A BSI-1-6c_3.pdf, Blatt 100

009s

Random number generation in software

\
crypto keys To generate random keys, we need a

I source of randomness.

e
application pseudorandom
number generator
/t\
time I pid
"Any one who considers
^ arithmetial methods of
9$
os entropy pool y:!:cing random digits is'
of course, in a state of sin."

. -John'von Neumann
MAT A BSI-1-6c_3.pdf, Blatt 101

0096

Random number generation in software

\
crypto kep To generate random keys, we need a
t source of rapdomness.

@
application pseudorandom
number generator
\pia
,,^{ I
'i;1"-:;:i:::;:!::,
os
@,
entropy pool ':!:cing
ot
random
oo'lrse' in a
digi*
state of
is'
sin'"
,/ | \ \
2 t O \ -JohnvonNeumann
MAT A BSI-1-6c_3.pdf, Blatt 102

0 097

Random number generation in software


q .T Hypothesis: Devices automatically
generate crypto keys on first boot'
crypto keys
t

a
e
pplication pseudorandom
number generator
.,/ 1
t
\
time pid

(o
\_-
OS entropy pool

,/ | \\
t@
MAT A BSI-1-6c_3.pdf, Blatt 103

0098

Random number generation in software


q. Hypothesis: Devices automatically
ta
generate crypto keys on first boot.
crypro Keys

e
application pseudorandom
number generator
./ tt \
time pid

@
OS entropy pool

,/ / \\
tqIP > Headless or embedded devices may
lack these entropy sources.
MAT A BSI-1-6c_3.pdf, Blatt 104

0099

Random number generation in software


q Hypothesis: Devices automatically
Y generate crypto keys on first boot.
crypto keys
1

a
e
pplication pseudorandom
> OS random number generator may
number generator
not have incorporated any entropy
,,^! 1 to,o
when queried by software.

e
OS entropy pool

,//\\
t{P Headless or embedded devices may
lack these entropy sources.
MAT A BSI-1-6c_3.pdf, Blatt 105

01 00

Random number generation in software


tY Hypothesis: Devices automatically
generate crypto keys on first boot.
crypto keys
t

e
application pseudorandorn
OS random number generator may
number generator

,,,j 1
not have incorporated any entropy
'0,, when queried by software.

Experimentally verified Linux


"boot-time entropy hole"
OS entropy pool

,/r\\
2t{P Headless or embedded devices may
lack these entropy sources.
MAT A BSI-1-6c_3.pdf, Blatt 106

0101

Linux random number generators

/dev/raadom /dev/urandom
"high-quality" randomness pseudorandomness

blocks if insufficient entropy never blocks


available

"As a general rule, ,/itea/aronilon should be used for everything


a<cept Iong-Iived GPG/SSL/iSH keys."a t, randon

randon's conservative blocking behavior is a usability problem,


This results in many developers using urandon for cryptography.
MAT A BSI-1-6c_3.pdf, Blatt 107

01 ü2

/* We'lI use /dev/urandon by default, since


/dev/random is too nuch hassle. If systen developers
aren't keeping seeds-betüreen boots nor getting any
entropy from sonewhere it's their own f aul-t. *,/
#def ine DROPBEAR-RAND0M-DEV " /dev/urandon"
MAT A BSI-1-6c_3.pdf, Blatt 108

0103

o Generating vulnerable RSA keys in software

> lnsufficiently random seeds for pseudorandom number


generator + we should see repeated keys.

prng.seedo
p = prtrg.randon-prineo
q = prng.randon-prineo
N=p*q

> We do:
> 60% of hcts share keys
'> At least 0.3% due to bad randomness.
> Repeated keys may be a sign that implementation is
vulnerable to a targeted attack.

But why do we see factorable keys?


MAT A BSI-1-6c_3.pdf, Blatt 109

0104

Generating factorable RSA keys in software


prng. seedo
p = prng.randon-prine.o
prng.add-randonn"r"Oa OpenSSL adds time in seconds
g = prng.randon-primeo
N=p*q

lnsufficient randomness can lead to factorable keys.

fd"-r-Il

ld*i." r.l

e- generating p J generalrng g -i'


+- generating --''

Experimentally verified OpenSSL generates factorable keys in this


situation.
MAT A BSI-1-6c_3.pdf, Blatt 110

0105

Generating weak DSA signatures

Step 1: Low-entropy DSA key generation

Step 2: Low-entropy seed for PRNG generating signature nonce.

Host 1 Host 2
50 B4
5B 24
I 13
36 89
B4 B5
24 68
13 52
89 69
85 47

o Step 3. Two sequences in same state -+ colliding nonces.


MAT A BSI-1-6c_3.pdf, Blatt 111

0106

lnvestigating Taiwanese smartcard weak keys

' Most common factor appears 46 times

c0000000OOOOOO0O000OOOOOOO000OOO
00000000000000000000000000000000
00000000000000000000000000000000
oo0000000000000000000000000002f 9
MAT A BSI-1-6c_3.pdf, Blatt 112

0107

lnvestigating Taiwanese smartcard weak keys

Most common factor appears 46 times


c0000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
000000000000000000000000000002f I

which is the next prime after 2s11 12510.


MAT A BSI-1-6c_3.pdf, Blatt 113

0108

lnvestigating Taiwanese smartcard weak keys

Most common factor appears 46 times

c0000000000000000000000000000000
00000000000000000000000000000000
0000000000000000000000@00000000
oooooooooooo0Ö0000000000000002f I

which is the nort prime after 251r a 2510.


The next most common factor, repeated 7 times, is
c9242492249292499249492449242492
24929249924949244924249224929249
9 249 492M92+2 492249292499249 4924
492424922492924992494924492424e5

Several other factors o<hibit such a pattem.


MAT A BSI-1-6c_3.pdf, Blatt 114

0109

How is this pattern generated?

1100100100100100001001001001001000100100100100101001001001001001
100100100100100101001001001001000100100100 1001000010010010010010
001001001001 00101001001001001001 10010010010010010100100100100100
01 00100100100100001001 001001001000100100100100101001001001001001
1001001001001001010010010010010001001001001 001000010010010010010
00100100100100101001001001001001 10010010010010010100100100100100
01 00100100100100001001 001001001000100100100100101001001001001001
1001001001001001010010010010010001001001001 00100001001001 1 100101
MAT A BSI-1-6c_3.pdf, Blatt 115

0110

How is this pattern generated?

Swap every 16 bits in a 32 bit word

0010010010010010 i 100100100100100 1001001001001001 0010010010010010


010o1oo1oo1001oo 1001001001001001 0010010010010010 0100100100100100
1001001001001001 0010010010010010 0100100100100100 1001001001001001
0010010010010010 0100100100100100 1001001001001001 0010010010010010
0100100100100100 1001001001001001 0010010010010010 0100100100100100
1001001001001001 0010010010010010 0100100100100100 1001001001001001
0010010010010010 0100100100100100 1001001001001001 0010010010010010
0100100100100100 1001001001001001 001001001 1100101 0100100100100100
MAT A BSI-1-6c_3.pdf, Blatt 116

0111

How is this pattern generated?

Realign

001001001 001 0010 1 1001001001001001001001001001001001001001001001001


001001001001 00100100100100100100L001001001001001 001001001001 001 001
001001001001001001001001001001001001001 00100100100100 1001001001001
001001001001001001001001001001001001001001001001001001001m1001001
00100100i001001001001001001001001001001 001001001001 001001001001001
001001001001001001001001001001001001001001001001001001001001001001
001001001001001001001001001001001001001001001001001001001001001001
001001001001001001001001001 I 1001010100100100100100
MAT A BSI-1-6c_3.pdf, Blatt 117

0112

o How is this pattern generated?

Realign

00100100100100101 1001001001001001001001001001001001001001001001001
001001001001001001001 001001001001001001001001.001001001001001001 001
001001001001001001001001001001001001001001001001001001001001001001
00100100100100100100100i001001001001001001001001001001001001001001
001001001001001001001001001001001001001001001001001001001001001001
001001001001001001001001001001001001001001001001001001001001001001
001001001001001001001001001001001001001001001001001001001001001001
00100100100100100100100100i 1 1001010100100100100100

The 119 factors had patterns of period 1, 3, 5, and 7.


MAT A BSI-1-6c_3.pdf, Blatt 118

0113

O Shared prime generation

Hypothesized key generation process for weak primes:


1. Choose a bit pattern of length 1, 3, 5, or 7 bits.
2 Repeat it to cover 512 bits.
3 For every 32-bit word, swap the lower and upper 16 bits.
4 Fix the most significant two bits to 11.
5 Find the next prime greater than or equal to this number.
MAT A BSI-1-6c_3.pdf, Blatt 119

Shared prime generation

Hypothesized key generation process for weak primes:


1. Choose a bit pattern of length 1, 3, 5, or 7 bits.
2. Repeat it to cover 512 bits.
3. For every 32-bit word, swap the lorryer and upper 16 bits.
4. Fix the most significant two bits to 11.
5. Find the no<t prlme greater than or equal to this number.

Factoring by trial diuision


Enumerating all patterns of this form factored 1.8 more keys.

Extending to patterns of length 9 gave us 4 more keys.


MAT A BSI-1-6c_3.pdf, Blatt 120

0115

Why are government-certified smartcards generating weak


keys?
Best practices and standards in hardware random number
generation require
> designers to characterize the entropy generated by circuits
> testing of the signal from the entropy source at run time
> post-processing by running outPut through cryptographic hash
function
These cards are clearly doing none of these things, even though
they claimed FIPS compliance.
MAT A BSI-1-6c_3.pdf, Blatt 121

0116

o Why are government-certified smartcards generating weak


keys?
Best practices and standards in hardware random number
generation require
> designers to characterize the entropy generated by circuits
> testing of the signal from the entropy source at run time
> post-processing by running output through cryptographic hash
function
These cards are clearly doing none of these things, even though
they claimed FIPS compliance.

Hypothesized failure:
> Use of hardware ring oscillator that can get stuck in a
particular pattern under certain conditions
> Failure of card software to do post-processing on RNG output.
MAT A BSI-1-6c_3.pdf, Blatt 122

01 17

O PGP: An unsolved mystery.

Why did GCD factor two PGP keys?

We and Lenstra et al. have no explanation.

They were both > L0 years old.

Open problem: What happened?


MAT A BSI-1-6c_3.pdf, Blatt 123

0118

Bitcoin
(Moore, Wustrow 2013) and (Schneider 2013)

Hypothesis:
The 133 vulnerable keys were associated with uncommon or test
implementations. (Confirmed for at least one implemehtation.)

ln January none of the vulnerable addresses contained any Bitcoins.

' .r\'. 'tft.''r

'#:iA ,+lt
'
uj,

'.t
I

\b-
ii 11...<r:
r.l:...."r
-
tat
red = wlmblc lcys
MAT A BSI-1-6c_3.pdf, Blatt 124

011e

O Disclosure for HTTPS and SSH vulnerabilities


> Wrote disclosures to 61 companies.

> 13 had Security lncident Response Team contact information


available.

> Received responses from 28.

> 13 told us they fixed the problem

> 5 informed us of security advisories

> Coordinated through US-CERT, ICS CERT, JP-CERT

> Linux kernel has been patched

> Since publication in August 2012,20yo decrease in number of


hosts serving factorable RSA keys.
MAT A BSI-1-6c_3.pdf, Blatt 125

0120

Disclosure for Taiwan lD card vulnerabilities

Disclosed vulnerability to Taiwan MOICA (Ministry of Interior).

> Have replaced cards for users directly impacted by GCD


vulnerabilities.

> Promised to replace cards from particular vulnerable batch.

o
MAT A BSI-1-6c_3.pdf, Blatt 126

a1 21

Gallery of horrors

o
MAT A BSI-1-6c_3.pdf, Blatt 127

a1 22

O Debian RNG

Debian weak keys served on:

> 4,L47 (0.03%) of HTTPS hosts


> 31,111 (0.34o/o) of RSA SSH hosts
> 22,030 (0.34%) of DSA SSH hosts
MAT A BSI-1-6c_3.pdf, Blatt 128

al 23

i a-ltidmtu.§iti
!. Y hcl

Orsüdd l*4,fr,
Ois.,rrl&.rUnh t8"G
adnört.ft
tru[ Udrlr, -süJhi
*adrDalt

f,,,{rl §
i!rr.. t,.d/.. llbba
trJ{f L-'lu
a,rr'tdü tlboa.ll
O,g.i,rroa tdr d*fif..t
cens, §.fu l*oacr
l*rUd.Er #--

o
MAT A BSI-1-6c_3.pdf, Blatt 129

4124

EllFDtlas*rE, r
,} lü6rr!lur.t8.üti
ilry,lmürd,

[.y-bE5üffiolt

rruE
MAT A BSI-1-6c_3.pdf, Blatt 130

0125

Distribution of prime factors


IBM Remote Supervisor Adapter ll and Bladecenter Management Module

h
o
b 100
d
C)
ü
U)

€50
A
MAT A BSI-1-6c_3.pdf, Blatt 131

a1 26

,O' Unexplainedoddities

Here are some prime factors of SSH keys (changed to protect the
guilty):

dsooooooooooooo . . . oooooooooooooooooooooooooooooooooolb3
bc00oo00oo0oo00. . . 00000000000000000000000000000000000c9
c60000000000000 . . . 00000000000000OO0000000000000000001ae

'O
MAT A BSI-1-6c_3.pdf, Blatt 132

41 27

o Unexplained oddities
.

Here are some other prime factors of HTTPS keys we found:

c3a64ae7f cltd4d9f 75cd2a49ec2d9f7 . . .


c3a64ae7f catd4d9f75cd2e5f2f c56c9 . . .
c3a64ae7f cttd4d9f 75cdee869c62229 . . .

ee93536e58a60b0f 56bf 95f aedc7ca42a9c9809a0aae2 . . .


ee93536e58a60b0f56bf95f aedc7ca42a9c9809a2cf5b. . .
ee93536e58a60b0f 56bf 95f aedc7ca42a9c9809aad4a8 . .'
ee93536e58a60b0f 56bf 95f aedc7ca42a9c9809abb02d . . .
ee93536e58a60b0f 56bf 95f aedc7ca42a9c9809acef 6f - . .
MAT A BSI-1-6c_3.pdf, Blatt 133

0128

,O Practical mitigations
Developers and manufacturers:
> Defense in depth: test, post-process, use multiple sources of
randomness.
> Collect entropy more aggressively, add hardware sources.
> Seed devices with entropy at the factory.
r Run for a while before generating cryptographic keys.

CAs:
> Test for repeated, factorable, and other weak keys.

Users:
> Check against known weak keys. (See factorable.net)
> Replace default certificates.
MAT A BSI-1-6c_3.pdf, Blatt 134

a12e

O Weak keys: Lessons

t New insights from taking a macroscopic view of


Systems: crypto practice.
> Cryptographic entropy is hard to get right.
MAT A BSI-1-6c_3.pdf, Blatt 135

0130

O Weak keys; Lessons

> New insights from taking a macroscopic view of


Systems: crypto practice.
> Cryptographic entropy is hard to get right.

Cryptography: > Need to design cryptosystems resilient to random


number generation problems. ("Hedged" crypto)
MAT A BSI-1-6c_3.pdf, Blatt 136

Weak keys: Lessons

New insights from taking a macroscopic view of


crypto practice.
Cryptographic entropy is hard to get right.

Cryptography: > Need to design cryptosystems resilient to tandom


number generation problems. ( "Hedged" crypto)

Many interesting algorithmic problems related to


Theory: efficiently and obliviously mining data sets for
cryptogra ph ic vulnerabilities.
MAT A BSI-1-6c_3.pdf, Blatt 137

0132

Summary:
lf you have bad randomness,
you have bad keys.

Next Lecture:
More math, more keys!
MAT A BSI-1-6c_3.pdf, Blatt 138

0133

Mining your Ps and Qs: Widespread Weak Keys in Network Devices


Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman
Usen ix Sec u rity 20 12 https: / lfactora ble. net

"Ron was wrong, Whit is right" published as


Public Keys Arjen K. Lenstra, James P. Hughes, Maxime Augier,
Joppe W. Bos, Thorsten Kleinjung, and Christophe Wachter Crypto 2012

Bitcoins and entropy Jonathan Moore and Eric Wustrow, 2013.


https://plus.google.com f u f0/106313804833283549032 / posts /XlTvcxNhMWz

Recovering Bitcoin private keys using weak signatures from the


blockchain Nils Schneider 2013.
http://www.nilsschneider.'netl20L3/01f 28f recovering-bitcoin-private-
keys.html

Factoring RSA keys from cenified smart cards: Coppersmith in the wild
Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou,
Nadia Heninger, Tanja Lange, and Nicko van Someren 2013, to appear.
file:lll #1
MAT A BSI-1-6c_3.pdf, Blatt 139
I Renesas I unsichere RSA-Sch1üssetgenerierung
Von:
An: 013
Kopie: 'ry
<christian.krauseGbsi,bund-de>, "Littian. Gereon" <oereon.killian@bsi.bund.de>
Blindkopie: Manf red Lochter <Manf red. Lochter@bsi.bund.de>
Datum: 23.08.2013 09:42

eben habe ich mündlich gehört, dass es eventuett Probleme gibt mit einem
-
Renesas-Chip, Das Problem sott sein, dass schwache RSA-Schtüssel erzeugt
werden, Der Angriff sott (so wie ich es verstanden habe) auf der ASIA Crypt
vorgestetl,t werden. [Jahrscheintich findet man dann auch eine entsprechende
Veröffenttichung auf eprint.
Wissen Sie vielleicht etwas mehr? Ist eines unserer zertifizierten Chips
bet roffen?

G rüße
Hessetmann
Orr

Unfortunately I witL be out of the office in the weeks 41-42, 52-02. During
this time I witt be unabte to repty to your mail.

Bundesamt für Sicherheit in der fnformationstechnik


Dr. Thomas Hessetmann
Referat S22
Godesberger Attee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefont +49 (0)228 99 9582 5691


Tetefax: +49 (0)228 99 10 9582 5691
Thomas. Hessetmann@bsi. bund. de
-it:
.tGrnet : urww. bsi, bund. de
wtnr. bsi- fuer- buerge r. de
filetlll #1
MAT A BSI-1-6c_3.pdf, Blatt 140
Al'I: lRenesasl unsichere RSA-Schtüssetgenerierung
Von:
An:
Kopie: 01 5

Datum: 23.08.2013 10:53

Hatto Herr Hessetmann,

die Herren I und lsind z. Z. nicht im Büro verfügbar.


Uns sind keine Informationen über schwache RSA-Schlüsset auf Renesas-Chips bekannt.
Es kann sich nur um Krypto-Bibliotheken auf Chips handetn, die ggf. vom Betriebssystemherstelter
oder von Renesas geliefert wird, Der Chip selbst erzeugt keine RSA-Schtüsset.
Wenn tatsächtich ein von uns evaluiertes Produkte betroffen sein sotlten, so könnte es sich z.B. um
- Renesas Cryptographic Library v5126 on Renesas RS47X security integrated circuit Version 01
BSr-DSZ-CC -O774-20LL
- Renesas Cryptographic Library v5126 running on the RS46X V02
handetn.
Es wurden aber auch andere Renesas-Chips und ggf. sogar mit Krypto-Bibtiotheken zertifiziert (2.8.
Chip HD65256D1, Brightsight BV, BSI-DSZ-CC-0529-2010).

weitere Angaben sind teider keine präziseren Auskünfte mögtich'


!
@rüßen / Best regards

P roduction , Computing Se,;^vices & Sotutions (CSS)


GCU MPHS, Security Consutting & Engineering

Mait:
leL: {
E-Mait.
Internet:

stuh rung :
Handets register:
Sitz dff
ce: This l;ransmlttai endr'or attachments may be privileged or confidentiat. If you are not the
intended recipient, you are hereby notified that you have received this transmittat in error; any
review, dissemination, or copying is strictty prohibited, If you received this transmittal in
error, ptease notify us immediatety by repty and immediatety detete this message and alt its
attachments. Thank you.

- - - --Ursprüngliche Nachricht-- ---


Von: Hesselmann, Thomas Imaitto:thomas.hessetmannGbsi.bund.de]
August 2013 09:42

; Kräuse,JhTistian; Kittian, Gereon


Betreff : IRenesasl unsichere RSA-Schtüsselgenerierung

Halto Herr
Hatto Herr
eben habe ich mündtich gehört, dass es eventuelt Probteme gibt mit einem Renesas-Chip. Das Probtem
soll sein, dass schwache RSA-Schtüssel erzeugt werden. Der Angriff sott (so wie ich es verstanden
habe) auf der ASIA Crypt vorgestellt h,erden. Wahrscheintich findet man dann auch eine entsprechende
Veröffentlichung auf eprint.
Wissen Sie vietleicht etwas mehr? Ist eines unserer zertifizierten Chips betroffen?
tilezlll #2
MAT A BSI-1-6c_3.pdf, Blatt 141

G rüße

Thomas Hessetmann
0136

Unfortunately I wi'Lt be out of the office in the weeks 41-42,52-92. During this time I wilt be
unabl"e to repty to your mait.

Bundesamt für Sicherheit in der Informationstechnik Dr. Thomas Hesselmann Referat S22 Godesberger
Attee 185 - 189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (0)228 99 9582 5691


Tetefax: +49 (0)228 99 10 9582 5691
E-Mait : Thomas . Hessetmann@bsi. bund . de<maitto:Thomas . Hesselmann@bsi. bund . de>
Internet: www.bsi.bund.de<htto://www.bsi.bund.de>
www. bsi - f ue r- bue roe r. de<htto: //r"rwtr. bsi- f ue r- b,ue roe r, de>
file:lll #1
MAT A BSI-1-6c_3.pdf, Blatt 142
lRenesas I possibly unsecure RSA key generation

Von: Thomas" <t BSI Bonn)


An: l
Kopie: "
Christian" <christian. krause@bsi'bund.de>,
23.08.2013 11:04

uurro il
I was informed today RSA-key generation
that there could be a probtem with on
Renesas smartcards. The RSA key generator does not generate secure keys. I do
not have more detailed information about the attack but a lot of identity
cards in Asia shoutd be effected. I also heard that the attack witl be
presentated on Asia crypt and tater on on eprint.

Do you have more informations? Are certified products (from Germany?) realty
invotved? Product? What exactty is the problem?

Please contact me if you have more informations' Thank you.

Rega rds
Hesselmann

O"

Unfortunatety I will be out of the office in the weeks 4L-42, 52'92. During
this time I witt be unabte to reply to your mail.

Bundesamt für Sicherheit in der Informationstechnik


Dr. Thomas Hesselmann
Referat S22
Godesberger Altee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefon: +49 (0)228 99 9582 5691


Telefax: +49 (0)228 99 10 9582 5691
trl{ait: Thomas . Hessetmann6bsi. bund . de
www.bsi.bund.de
]rnet: unru- hsi -f rrer-hueroer.de
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 143
Fwd: AtI: IRenesasl unsichere RSA'Schtüssetgenerierung

Von:',Hessetmann, Thomas" <thomas.hessetmann@bsi.bund.de> (BSI Bonn)


An: ,,Krause, Christian" <christian.krause@bsi.bund.de>, illgtlia-n--Geleon" 01 3
<ge recjn . killian@bsi . bund ' de>
Datum: 23.08.2013 11:06

weitergeteitete Nach richt


Von:
Datum: Freitag, 23. August 2013, 10:53:09
An: thomas. hessel

Betr. : AW: IRenesas] unsichere RSA-Schtüssetgenerierung

Hatto Herr Hessetmann,

nfl
:
i I i il"
fl l"d#n,' ü 13 .' ;.i;, I il:' Lii, : il ffi , : : i' : 3 ?' [ä n.,,, - *' i
"H#
p,
bekannt.
Es kann sich nur um Krypto-Bibtiotheken auf chips handeln, die ggf. vom
^rriebssystemherstetter oder von Renesas geliefert wird. Der Chip selbst
Irg- Ke.Ine KrA-)cnLusseL.
wenn iatsächtich ein von uns evaluiertes Produkte betroffen sein soltten, so
könnte es sich z.B, um
- Renesas Cryptographic Library v5126 on Renesas RS47X security integrated
circuit Version 01 BSI-DSZ-CC-9774-2gLL
- Renesas Cryptographic Library v5126 running on the RS46X V02
handetn.
Es trurden aber auch andere Renesas-Chips und ggf' sogar mit
Krypto-Bibtiotheken zertifiziert (2.8. chip HD65256D1, Brightsight BV,
BSr - DSZ - CC - 0529 - 2010 )

Qhne weitere Angaben sind teider keine präziseren Auskünfte mögtich.


Mit freundlichen Grüßen / Best regards

Production, Computing Services & Sotutions (CSS)


GCU MPHS, Security Consutting & Engineering

e
Mail:
Tel:
E-Mail:
Internet:

Aufsichts rat I
Geschäftsführung:
Handelsregister: r
Sitz der Gesettschaft:
Ust.-Id Nr.
Notice'tnisF:nffid/orattachmentsmaybeprivitegedorconfidentia1.
If you are not the intended recipient, you are hereby notified that you have
received this transmittal in error; any review, dissemination, or copying iS
strictty prohibited. If you received this transmittat in error, ptease notify
us immediatety by reply and immediately delete this message and alt its
attachments. Thank you.

- - - --Ursprüngtiche Nachricht- - - - -
:
Von Hessetmann, Thomas Imaitto:thomas.hesselmann6bsi.bundftl
Ges
An:
Cc: Krause, hristian; Kiltian, Gereon
titeill #2
MAT A BSI-1-6c_3.pdf, Blatt 144
Betreff r IRenesas] unsichere RSA-Schlüssetgenerierung

Halto
013e
Hatto

eben habe ich mündtich gehört, dass es eventuett Probteme gibt mit einem
Renesas-Chip. Das Probtem sott sein, dass schwache RSA-Schtüssel erzeugt
werden. Der Angriff sotl (so wie ich es verstanden habe) auf der ASIA Crypt
vorgestettt werden, brlahrscheintich findet man dann auch eine entsprechende
Veröffentlichung auf ePrint.
Wissen Sie vietteicht etwas mehr? Ist eines unserer zertifizierten Chips
bet roffen?

G rüße

Thomas Hessetmann

UnfortunatetyI witt be out of the office in the weeks 41-42, 52-92. During
this time I witt be unabte to repty to your mait.

Bundesamt für Sicherheit in der Informationstechnik Dr. Thomas Hesselmann


Referat S22 Godesberger Altee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefon; +49 (91228 99 9582 5691


Telefax: +49 ß1228 99 10 9582 5691
E- Mait : Thomas Hes setmannGbsi , bund . de<maitto Thomas
. , : . Hesselmann@bsi . bund . de>
Inte rnet r tirww. bsi. bund . de<htto : //wunr. bsi . bund de> ,

www. bsi- fue r- bue roe r. de<htto: //wunr. bsi- fue


file:lll #1
MAT A BSI-1-6c_3.pdf, Blatt 145
Re: IRenesasl possibtv unsecure RSA kev aaneration

Von:
An:
Kopie: 'r.ur&J 4
Datum: 23. 08.2013 L7 t02

Dear Mr. Hessetmann,

Yes, I have discussed this at length trrith some of the authors. Atso,
the attack bras presented at the rump session at Crypto over here. I
wilt be happy to share with you what I have learnt from my discussion,
but it needs to be off the record, at least untit the paper is
published. I will gladty catt you when I get back next vreek.
To put your mind at ease a littte, I can telt you the following (I am
a tittle reluctant since at this moment I have no possibility to
encrypt this information).
- the bad news is that the underlying product is a product once
certified by BSI.
.rtre oood news is that it is used outside of its evatuated configuration.
!"fso suspect that the certification has 'expired'. The product
does appear in the List of BSI certified products at the BSI website,
- atthough it is a pretty impressive resutt, so far they have found
onty ca. 200 keys out of a pool of several hundreds of thousands that
they have retrieved.0f course this does not mean there is no problem,
but it suggests the product is vutnerable to this approach only in
pa rticular circumstances.

- a minor point, but the product was not evaluated by us. Frankly, it
might as wett have been; many TOEs are not comptetety secure when
guidance is not fottov'red.

I hope this hetps. I would appreciate it if you used this information


as you see fit, but without reveating its source.
If I might suggest, perhaps you coutd atso ask dr. Lochter (or
yourself, or another cotleague) to reach out to our mutuat friend in
Eindhoven. That would open a channet straight to the source.

.r.t reoards.
!
Quoting "Hesselmann, Thomas" <thomas.hesselman :

l ru..o lE,
> I was informed today that there coutd be a problem urith RSA-key generation on
> Renesas smartcards. The RSA key generator does not generate secure keys. I do
> not have more detailed information about the attack but a lot of identity
> cards in Asia should be effected. I also heard that the attack witl be
> presentated on Asia crypt and tater on on eprint.
> Do you have more informations? Are certified products (from Germany?) really
> invotved? Product? k'lhat exactly is the probtem?
> Please contact me if you have more informations. Thank you.

> Regards
> Thomas Hessetmann
MAT A BSI-1-6c_3.pdf, Blatt 146

> Unfortunatety I witt be out of the office in the weeks 41-42, 52-92: During
> this time I witl be unabte to repty to your mait.
,
> Bundesamt für Sicherheit in der Informationstechnik
01 41
> Dr. Thomas Hessetmann
> Referat S22
> Godesberger Attee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn
> Tetefon: +49 (0)228 99 9582 5691
> Telefax: +49 (S)228 99 l0 9582 5691
> E-Mait: Thomas.llessetmannGbsi.bund.de
> Internet: wr.rw.bsi.bund.de

O-;;;;;;;-;;;-;""1 usins rMP, the r;;;;;-;;;;il;;-;;;;;;:


tile:lll #1
MAT A BSI-1-6c_3.pdf, Blatt 147
Re: Al,I: lRenesasl unsichere RSA-Schlüssetgenerierung
Von: n (BSI Bonn)
An:
Kopie: 01 4
"Krause. Christian" <christian.krause@bsi. bund.de>,
"Kiltian, Gereon" <oereon.killian@bsi.bund.de>
Datum: 23.08.2013 17:18

Halto

wir bemühen uns um mehr Informationen, aber fotgendes scheint sich zu


bestätigen (atles noch ohne Gewähr):
- Produkt ist beim BSI zertifiziert worden, evatuiert anscheinend von
T- Systems
- Produkt wurde NICHT gemäß Guidance genutzt .. . es gibt eine Vermutung, dass
der FIPS-Tests (??) nicht durchgeführt wurde (gute Nachricht für uns)
- man konnte ca. 200 Schtüssel aus einem Poot von einigen Hunderttausend
e rhatten

Der Angriff sott auch kurz auf der Rump Session der Crypto vorgestetlt worden

o
Nächste lrJoche erfahre ich vielteicht mehr.

G rüße
Thomas Hessetmann

Unfortunatety I wilt be out of the office in the weeks 4L-42, 52-02. During
this time I witt be unable to reply to your mail.

Bundesamt für Sicherheit in der Informationstechnik


Dr. Thomas Hesselmann
Referat S22
Godesberger Atlee 185 -189
53175 Bonn
'^r.tfach 20 03 63
l}, o=nn

Tetefon: +49 (01228 99 9582 5691


Telefax: +49 (@)228 99 10 9582 5691
E-Mait: Thomas. Hessetmann@bsi. bund. de
Internet; unvw. bsi. bund. de
unvw. bsi - fue r- bue roe r. de

ursprüngtiche Nachricht

Freitag, 23. August 2013, 10:53:09

Betr,: AW: IRenesas] unsichere RSA-Schtüssetgenerierung

> Halto Herr Hessetmann ,

> die Herren a unO Esind z. Z. nicht im Büro verfügbar.


> Uns sind keine Informationen über schwache RSA-Schlüsset auf Renesas-Chips
bekannt.
> Es kann sich nur um Krypto-Bibtiotheken auf Chips handetn, die ggf. vom
file:lll #2

Betriebssystemherstetter oder von Renesas geliefert


MAT wird.BlattDer
A BSI-1-6c_3.pdf, 148Chip selbst
erzeugt keine RSA-Schtüssel.
> Wenn tatsächtich ein von uns evaluiertes Produkte betroffen sein sottten, so 0143
könnte es sich z.B. um
> - Renesas Cryptographic Library v5126 on Renesas RS47X security integrated
circuit Version 01 BSI-DSZ-CC-0774-2011
> - Renesas Cryptographic Library v5126 running on the RS46X V02
> handetn
> Es wurden aber auch andere Renesas-Chips und ggf. sogar mit
Krypto-Bibliotheken zertifiziert (2.B. chip HD65256D1, Brightsight BV,
BSr -DSZ- CC- 0529- 2010) .

Qhne weitere Angaben sind leider keine präziseren Auskünfte mögtich.

Mit freundtichen Grüßen / Best regards

Production, Computing Services & Solutions (CSS).


G€U MPHS, Security Consulting & Engineering
ldiEry
> Mait:
' -el: r

> Geschäftsführung:
> Handetsregister: I
> Sitz der Gesetlschaft:
> Ust.-Id Nr.
> Notice: This transmittat and/or attachments may be priviteged or
confidentiat. If you are not the intended recipient, you are hereby notified
that you have received this transmittat in error; any review, dissemination,
or copying is strictty prohibited. If you received this transmittat in error,
please notify us immediatety by repty and immediatety delete this message and
att its attachments. Thank you.

> Von: Hesselmann, Thomas Imaitto:thomas.hessetmanntabsi.bund.de]

stian; Killian, Gereon

> Hatto
> Hatlo
> eben habe ich mündlich gehört, dass es eventuetl Probleme gibt mit einem
Renesas-Chip. Das Problem sol1 sein, dass schwache RSA-Schlüssel erzeugt
werden. Der Angriff solt (so wie ich es verstanden habe) auf der ASIA Crypt
vorgesteltt werden. Wahrscheintich findet man dann auch eine entsprechende
Veröffentlichung auf eprint.
> Wissen Sie vietleicht etwas''mehr? Ist eines unserer zertifizierten Chips
betroffen?
> Grüße
> Thomas Hesselmann

> Unfortunately I witt be out of the office in the weeks 4l-42,52-92. During
this time I witt be unabte to repty to your mait.
flle:lll
MAT A BSI-1-6c_3.pdf, Blatt 149

> Bundesamt für Sicherheit in der Informationstechnik Dr. Thomas Hessetmann


Referat S22 Godesberger fttee 185 -189 u 1I 'tt 'tn
A
> 53175 Bonn

> Postfach 20 03 63
> 53133 Bonn
> Tetefon: +49 (0)228 99 9582 5691
> Telefax: +49 (0)228 99 10 9582 5691
> E-Mait i
Thomas. Hesselmann@bsi. bund. de<mailto:Thomas.Hessetmann@bsi. bund. de>
> Internet: www.bsi.bund.de<htto://utrm.bsi.bund.de>

o
file:lll #t
MAT A BSI-1-6c_3.pdf, Blatt 150
Re: IRenesasl possibty unsecure RSA key qeneration

An : "Hesselmann, Thomas " <thomas . hessetmann@bsi, bund . de> 014


Datum: 27.08.2013 15:31

Dear mr. Hessetmann,

I am back in the office, if you'd tike we could have a chat about the RSA KG
thing. It would have to be before friday, though, after that I witl be on a
hotiday for two weeks.
If you don't have them by now, the stides of the presentation can be
downtoaded at
htt o: //c rvoto .2013 . rumo. c r. vp. tol55e2988c4ed3c9f635c9a4c3f52fa0b1 . odf

I tried to calt you but there was no answer. If you would tike to tatk, please
propose a timestot which is good for you.

Best regards,

]riOay 23 August 2OL3 Lh 11:03 you wrote:


> Thank you.
> the tip came from Dr. Lochter. He has atready asked the authors for more
> informations, ... welt tre wilt see, what is coming up. If possibte I witl
> tetl something in the next HW-Forum.
> Best regards
> Thomas Hesselmann
file:lll #1
MAT A BSI-1-6c_3.pdf, Blatt 151
Re: AIrl r IRenesasl unsichere RSA-Schlüssetgenerierung
Von: tr tr (BSI Bonn)
An: 014
iopier
!, "Krause, Christian" <christian,krause@bsi.bund'de>,
"Kil1ian, Gereon" <gereon. kiltian@bsi.bund.de>
Datum: 27 .08.2013 16:31

Halto

die Präsentationsfotien hiervon findet man unter

htto : //c rvoto . 2013 . rumo .c r. vo. tol55e2988c4ed3c9f635c9a4c3f52fa0b1 . odf

G rüße
Thomas Hesselmann

Unfo rtunately I witt be out of the office in the weeks 4l-42, 52-92. During

e time I will be unabte to reply to your mail.

Bundesamt für Sicherheit in der Informationstechnik


Dr. Thomas Hessetmann
Referat S22
Godeiberger Atlee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon t +49 (9)228 99 9582 5691


Telefax: +49 (0)228 99 10 9582 5691
E-Mail:
Internet: !444.. bsi. b.U.!dJg
lrnry. bsi - f ue r- bue rge r. de

ursprüngtiche Nachricht

"Hesselmann, Thomas" <


Datum: Freitag, 23. August 2013, 17:18:15
An:
Kopie:
;ahristian
>, "Kiltian, Gereon"
killian(äb
<qe reon .
Betr.; Re: AW: IRenesas] unsichere RSA-Schtüssetgenerierung

> Halto
> wir bemühen uns um mehr Informationen, aber folgendes scheint sich zu
> bestätigen (attes noch ohne Gewähr):
>- Produkt ist beim BSI zertifiziert worden, evaluiert anscheinend von
> T-Systems
>- Produkt vrurde NICHT gemäß Guidance genutzt .. . es gibt eine Vermutung,
dass
> der FIPS-Tests (??) nicht durchgeführt wurde (gute Nachricht für uns)
> - man konnte ca. 200 Schtüssel aus einem Poot von einigen Hunderttausend
> erhatten
> Der Angriff sott auch kurz auf der Rump Session der Crypto vorgestellt
fite:lll #2
MAT A BSI-1-6c_3.pdf, Blatt 152
wo rden
> sein.
> Nächste Woche erfahre ich vielteicht mehr.
01 47
> Grüße
> Thomas Hesselmann

> Unfortunately I will be out of the office in the treeks 4L-42,52-52. During
> this time I will be unable to reply to your mait'

> Bundesamt für Sicherheit in der Informationstechnik


> Dr. Thomas Hesselmann
> Referat S22
> Godesberger Attee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn

!"a"ron t +4e (0)228


ls)228 99 9582 s691
> Tetefax: +49 99 10 9582 5691
> E-Mait: Thomas.Hessetmann6bsi.bund.de
> Internet: @_bu.!d.de
www. bsi- fue r- buerge r. de

ursprüngliche Nachricht
> Von:
> Datum: Freitag, 23. August 2013, 10:53:09
> An:

AW: IRenesas] unsichere ,Schtüssetgene rie rung

> > Hatto Herr Hesselmanp,

>>die sind z. Z. nicht im Büro verfügbar.


-^ Uns sand keine Informationen über schwache RSA-Schtüsset auf Renesas-Chips
(},.unn.
>-> Es kann sich nur um Krypto-Bibtiotheken auf Chips handetn, die ggf. vom
> Betriebssystemherstetter oder von Renesas getiefert wird. Der Chip selbst
> erzeugt keinä RSA-Schtüssel.
> > Wenn tatsächlich ein von uns evatuiertes Produkte betroffen sein sollten,
SO
> könnte es sich z.B. um

> circuit Version 01 BSI-DSZ-CC-9774-201L


> > handetn.
> > Es wurden aber auch andere Renesas-Chips und ggf. sogar mit
> Krypto-Bibliotheken zertifiziert (2.8. Chip HD65256D1, Brightsight BV,
> BSr-DSZ-CC-0529-2010) .
> > Ohne weitere Angaben sind leider keine präziseren Auskünfte möglich.
> > Mit freundtichen Grüßen / Best regards

> > Production, Computing Services & Sotutions (CSS)


> > GCU MPHS, Security Consutting & Engineering
frle:lll #3
MAT A BSI-1-6c_3.pdf, Blatt 153
> > Mait:
> > Tet: Mobite, *al
E-Mail:
JnfA rnFt
0148

> > Aufsichtsrat:


> > Geschäftsführung:
> > Handelsregister:
> > Sitz der Gesellschaf
> > Ust.-Id Nr.
> > Notice: This trarismittat and/or attachments may be priviteged or
> confidential. If you are not the intended recipient, you are hereby notified
> that you have received this transmittat in error; any review, dissemination,
> or copying is strictty prohibited. If you received this transmittat in
error,
> please notify us immediatety by reply and immediatety detete this message
and
its attachments. Thank you.
I laa

Von: Hessetmann, Thomas Imailto:thomas.hesselmannGbsi.bund.de]


^
> > Cc: E -k-rause, Christian; Kittian, Gereon
> > Betreff: IRenesasl unsichere RSA-Schtüssetgenerierung

> > Halto


> > Hatlo
> > eben habe ich mündtich gehört, dass es eventuelt Probteme gibt mit einem
> Renesas-Chip. Das ?robtem sott sein, dass schwache RSA-Schlüssel erzeugt
> werden. Der Angriff sott (so wie ich es verstanden habe) auf der ASIA Crypt
> vorgestellt werden. Wahrscheintich findet man dann auch eine entsprechende
> Veröffenttichung auf eprint.
> > Wissen Sie vietleicht etwas mehr? Ist. eines unserer zertifizierten Chips
> betroffen?
>> Grüße
- Thomas Hessetmann
o
> > Unfortunatety I witt be out .of the office in the weeks 4L-42, 52-02.
Du ring
> this time I witt be unabte to repty to your mait.

> > Bundesamt für Sicherheit in der Informationstechnik Dr. Thomas Hessetmann
> Referat S22 Godesberger Atlee 185 -189
> > 53175 Bonn
> > Postfach 20 03 63
> > 53133 Bonn
> > Tetefonr +49 (0)228 99 9582 5691
> > Tetefax: +49 (0)228 99 r0 9582 5691
> > E-Mait:
> Thomas. Hessetmann@bsi. bund. de<maitto :Thomas.He
> > Internet: un'rur.bsi.bund.de<htto://www.bsi.bund.de>
urww. bsi - fue r- bue rge r. de<http: //www. bsi- fue r- bue rge r. de>
tite;lll #1
MAT A BSI-1-6c_3.pdf, Blatt 154
Re: Fwd: Re: lRenesasl possibly unsecure RSA key generation
Von: "Hesselmann. Thomas" <thomas. hessetmann@bsi. bund.de> (BSI Bonn)
An: Manfred Lochter <Manfred.Lochter@bsi,bund.de>, "schindter, Werner" 014
<werner.schindter@bsi.bund.de>, "Krause, Christiän" <christian.krauseGbsi.bund,de>,
"Ga b rie l . Ad ria n " <a d ri a n . g a b [iel@bsi- !-u-ndJ-Q,, -5-a-o4..--0,Etavi
g]
<octavio.gamero@bsi.bund,de>, "Kittian. Gereon" <gereon.kittian6bsi.bund.de>
Datum: 27 .98.2013 18:58

Hatto,

im fotgenden ein kleines Update nach Tetko mit T-Systems.


1) Wenn es ein Renesas-Produkt betrifft, so ist woht AE57C1. Es ist 2097/2908
zertifiziert worden.
2) Es ist etwas komisch, dass einer der Primzahten so viete 0 hat. Der TRNG
von AE57C1 hat einen tinearen Schieberegister als Nachbearbej"tung. hrlenn der
TRNG nicht mehr funktioniert, dann müsste man nur noch 0 oder (je nach
internem Zustand) nur "zufälLige" Werte erhalten.
3) Auch die Generierung von *24922492924992* ist komisch (wegen linearen
Schieberegister bei Nachhbearbeitung)
4) T-Systems wird Renesas (mit Verweis auf Link) nach mehr Informationen

;::"'"'
Thomas

ursprüngtiche Nachricht
Von: "Hessetmann, Thomas" <thomas.hessetmann@bsi.bund.de>
Datum: Dienstag, 27. August 2013, 16:29:10
An: Manfred Lochter <Manfred'Lochtero , "Schindler, Werner"
<we rne r. schindle r
Kopie i
Betr.: Fwd: Re: IRenesas] possibly unsecure RSA key generation

weiterqeteitete Nach richt


> Von:
' 'atum: Dienstag,27. August 2013, 15:31:02
o.',
> Kopae:
"Hessetmann, Thomas" <thomas . hesselmann@bsi . bund . de>

> Betr.: Re: IRenesas] possibly unsecure RSA key generation

l>
Dear mr. Hesselmann,

> I am back in the office, if you'd like we coutd have a chat about the RSA KG
> thing. It would have to be before friday, though, after that I will be on a
> hotiday for two weeks.
> If you don't have them by now, the slides of the presentation can be
> downloaded at
> http : //c rvp'to . 2013 , rump . c r. yp . tol55e2988c4ed3c9f635c9a4c3f52fa0b1 . Pdf
> I tried to catt you but there was no anshrer. If you woutd tike to tatk,
please
> propose a timestot which is good for you.

,r
> Best regards,
#2
MAT A BSI-1-6c_3.pdf, Blatt 155
hri nhtsioht hv

0150
filelll
MAT A BSI-1-6c_3.pdf, Blatt 156
#1

Re: IRenesasl possibly unsecure RSA key generation

Von: "Hesselmann, Thomas" <thomas,hesseLmannGbsi.-bg!-d.i-e>, (BSI Bonn)


An:
Datum:
01s

Helto @
really great thanks for your tink. Meanwhite it seems to us, that possibty the
TOE is certified in 2007/2008 and not by Brightsight. It seems a tittle be
strange, that one of the primes does contain so many 0. Atso one other prime
contains *24922492924992*. Because of the postprocessing of the chip usuatly
this cannot be generated (practicatly) in this TOE. Wett, the other ITSEF has
contacted the devetoper and asked for more information.
> I tried to catt you but there was no anshrer. If you would f.ike to tatk,
> ptease propose a timestot which is good for you.
If you have more informations we shoutd talk. Proposat: tomorrow, 28.08,
10:00. Othen*ise the other ITSEF has to foltow the incident ... as tong as
they are involved.

O*t for your rnformatron!

Best regards
Thomas Hessetmann

Unfortunately I will be out of the office in the weeks 4l-42, 52-02. Du ring
this time I witl be unabte to repty to your mait.

Bundesamt für Sicherheit in der Informationstechnik


Dr, Thomas Hesselmann
Referat 522
Godesberger Atlee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

?"ron: +49 (0)22899 9s82 s691


Tetefax: +49 (0)228 99 10 9582 5691
E - Mait : Thomas . Hes selmann@bsi . bund . de
Internet I @-b_U!ldr.de
wunr. bsi- fue r- bue rge r. de

ursprüngU,che Nach richt

Von:
Datum: Augus
An: "Hessetmann, Thomas" < >
Kopie:
Bet r. : Re: IRenesas] possibly unsecure RSA key generation

> Dear mr. Hesselmann,

> I am back in the office, if you'd tike we coutd have a chat about the RSA KG
> thing. It woutd have to be before friday, though, after that I witl be on a
> hotiday for two weeks
> If you don't have them by now, the stides of the presentation can be
> downtoaded at
tile:,lll
MAT A BSI-1-6c_3.pdf, Blatt 157 #2
> http://crvpto.2013.rump,cr.yp.tol55e2988c4ed3c9f635c9a4c3f52fa0b1.Pdf
> I tried to catt you but there v',as no ansv,rer. If you woutd tike to talk,
please
> propose a timestot which is good for you. 0152
> Best regards,
,-
I On ,rrduy 23 August 2013 17:11;03 you wrote:
> > Thank you.
> > the tip came from Dr. Lochter. He has already asked the authors for more
> > informations, ... urell we wilt see, what is coming up. If possibte I wilt
> > tett something in the next HW-Forum.
> > Best regards
> > Thomas Hessetmann

lr
-t-
-A
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 158
#1

Re: IRenesas] possibty unsecure RSA key generation

Von:
An: "Hesse1mann, Thomas" <thomas. hessetmann@bsi. bund 'de>
Datum: 27 .08.2013 19:35 0153
Hel1o,

I think I can help, L0:00 tomorrow is a good idea. The other prime has
some interesting properties when shown in binary.
Let's tatk tomorrow,

Best regards,

Quoting "Hessetmann, Thomas" <thomas.hessetmannobsi.bund.de>:

> Hetlo

br,lr-great thanks for your link. Meanwhite it seems to us, that


i +8:ti:'l"Hirr"o in 2o07/2008 and not by Brishtsight. rt seems a tittte be
> strange, that one of the primes does contain so many 0. Atso one other prime
> contains *24922492924992*. Because of the postprocessing of the chip usually
> this cannot be generated (practicatly) in this TOE. tr{ett, the other ITSEF has
> contacted the devetoper and asked for more information.
>> f tried to call you but there was no ansrirer. If you woutd like to talk,
>> please propose a timestot which is good for you.
> If you have more informations hre should tatk. Proposat: tomorrow, 28'08,
> 10:00. 0therwise the other ITSEF has to fottow the incident ..' as long as
> they are invotved,
> Thanks for your informationl
> Best regards
> Thomas Hessetmann
"o
> Unfortunatety I witl be out of the office in the weeks 4L-42,52-02. During
I ::t: :1t: I :t:: :: :::::: :: i:tir :: lti titl_
> Bundesamt für Sicherheit in der Informationstechnik
> Dr, Thomas Hessetmann
> Referat S22
> Godesberger Atlee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn
> Telefon: +49 (0)228 99 9582 5691
> Telefax: +49 (0)228 99 L0 9582 5691
> E-Mait: Thomas.Hessetmann@bsi.bund,de
> Internet: www. bsi. bund. de
> www.bsi-fuer-bueroer.de

ursprüngliche Nach richt


filezlll #2
MAT A BSI-1-6c_3.pdf, Blatt 159
> Von:
> Datum: urenstag, 27. August 2013, 15:31:02
" Hessetmann, Thomas " <thomas . hessetmann6bsi
> An: . bund ' de>

> Kopie:
> Betr.: Re: IRenesas] possibty unsecure RSA key generation
0154

>> Dear mr. Hesselmann,

>> I am back in the office, if you'd Like we could have a chat about the RSA KG
>> thi.ng. It woutd have to be before friday, though, after that I witt be on a
>> hotiday for two weeks.
>> If you don't have them by now, the slides of the presentation can be
>> downtoaded at
>> htto : //c rvoto .2013 . rumo . c r. vo . tol55e2988c4ed3c9f635c9a4c3f52fa0b1. Ddf

>> I tried to catt you but there h,as no answer. If you trould tike to talk,
> please
>> propose a timeslot r.rhich is good for you.

>> Best regards,

I'lr
>> 0n Friday 23 August 2gL3 L7:11:03 you wrote:
>> > Thank you.

>> > the tip came from Dr. Lochter. He has atready asked the authors for more
>> > informations,.... wett we witl see, what is coming up. If possibte I t'ritt
>> > tett something in the next HW-Forum.

>> > Best regards


>> > Thomas Hesselmann

o
This message was sent using IMP, the Internet Messaging Program.
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 160

Re: Atrl: [Renesasl unsichere RSA-Schlüsselgenerierung


Von: (BSI Bonn)
An:
Datum: 27 .98.2013 19:52

If hat mich gerade eben hingewiesen, dass die primzahlen interessante


Eigenschaften besitzen, hrenn man sie sich binär ansieht ...

Ich leite zur Zeit fnfos nur weiter...


G rüße
Thomas Hessetmann

ursprüngtiche Nachricht
Von: "Hessetmann, Thomas" <thomas.hessetmannGbsi.bund.de>
Datum: onctaa - 77. t 2013, 16:31:
An:
K
"Krause, Christian"
, "Kiltian, Gereon"

IRenesas] unsichere RSA-Sch[üssetgenerierung

Harro
-,,IÜ,
die Präsentationsfolien hiervon findet man unter
http://crvpto.2013. rump.cr.vo.to/55e2988c4ed3c9f635c9a4c3f52faOb1.pdf
G rüße
Thomas Hessetmann

> Unfortunatety I witt be out of the office in the weeks 41-42, 52-02. During
> this time I witl be unabte to reply to your maiL.

frndesamt für Sicherheit in der Informationstechnik


Vr. Thomas Hessetmann
> Referat S22
> Godesberger Altee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn
> Tetefon t +49 lg')228 gg g5g2 5691
> Telefax: +49 (0)228 99 10 9582 5691
> E-Mait: Thomas.Hesselmann@bsi.bund-de
> fnternet: www.bsi.bund.de
www. bsi- f ue r- bue roer. de

ursprüngtiche Nachricht
Von: "Hesselmann, Thomas" <thomas.hesselmann@bsi.bund.de>
F reit st 2013. 17: 18:

"Krause, Christian"
, "Kiltian, Gereon"
<gereon. kittian(ab
Betr.: Re: AW: IRenesas] unsichere RSA-SchlüsseLgenerierung
fitelll
MAT A BSI-1-6c_3.pdf, Blatt 161 #2

>>Hatlo
> > wir bemühen uns um mehr Informationen, aber fotgendes scheint sich zu
> > bestätigen (attes noch ohne Gewähr): 0156
-
> > T-Systems
> > - Produkt wurde NICHT gemäB Guidance genutzt ... es gibt eine Vermutung,
> dass
> > der FIPS-Tests (??) nicht durchgeführt wurde (gute Nachricht für uns)
> > erhalten
> > Der Angriff solt auch kurz auf der Rump Session der Crypto vorgestettt
> worden
> > sein.
> > Nächste Woche erfahre ich vielteicht mehr.

> > Grüße


> > Thomas Hessetmann
o
> > Unfortunatety I wilt be out of the office in the weeks 4L-42,52-02.
Du ring
> > this time I wilt be unable to repty to your rnail.

> > Bundesamt für Sicherheit in der Informationstechnik


> > Dr. Thomas Hessetmann
> > Referat S22
> > Godesberger Allee 185 -189
i > 53175 Bonn
> > Postfach 20 03 63
> > 53133 Bonn
> > Tetefon: +49 (0)228 99 9582 5691
> > Tetefax: +49 (0)228 99 10 9582 5691
f r-ffaif r Thomas . Hesselmann@bsi. bund . de
V Internet: www. bsi. bund.de
www, bsi- f ue r-bue roe r. de

ursprüngtiche Nachricht _,

> > Vonr


> > Datum: Freitag, 23. August 2013, 10:53:09
> > An: thomas.hesselmann@bsi.bund.de

> > Bet'.; AW: IRenesas] unsichere RSA-Schl.üsselgenerierung

Renesas - Chips
>> bekannt.

> > BetriebssystemhersteLter oder von Renesas geliefert wird. Der Chip setbst
> > erzeugt keine RSA-Schtüsset.
sottten,
>so
MAT A BSI-1-6c_3.pdf, Blatt 162
> > könnte es sich z.B. um

integ rated
> > circuit Version 01 BSI-DSZ'CC-9774-20LL

0157
> > Krypto-Bibtiotheken zertifiziert (2.B. Chip HD65256D1, Brightsight BV,
> > BSr-DSZ-CC-0529-2010).

lllg
>>>G s,acrrritv Consutting & Engineering

> > > Mait:


l'ffti' fuIMobite'f
nte rnet :

> > confidentiat. If you are not the intended recipient, you are hereby
notified
> > that you have received this transmittat in error; any review,
dissemination,
> > or copying is strictly prohibited. If you received this transmittat in
> error,
> > ptease notify us immediately by repty and immediatety detete this message
> and
> > att its attachments. Thank you.

O : -----ursprünstiche Nachricht-----
ust 2013 09:42
> > > An:
> > > Cc: , Christian; Kittian, Gereon
Renesas] unsichere RSA-Schlüsselgenerierung

Probteme gibt mit einem


> > Renesas-Chip" Das Problem sott sein, dass schwache RSA-Schlüssel erzeugt
> > werden. Der Angriff soll (so wie ich es verstanden habe) auf der ASIA
C rypt
> > vorgestetl,t werden. Wahrscheintich findet man dann auch eine entsprechende
> > Veröffentlichung auf eprint.

> > betroffen?


fiteilt #4
MAT A BSI-1-6c_3.pdf, Blatt 163

> During
> > this time I will be unable to reply to your mait.

Hesselmann
> > Referat 522 Godesberger Attee 185 -189

> > Thomas.Hessetmann6bsi.bund.de<mailto:Thomas.Hesselmann@bsi.bund.de>


tile:lll
MAT A BSI-1-6c_3.pdf, Blatt 164
#1

Re: IRenesasl possibly unsecure RSA key generation

Von: tr (BSI Bonn)


An:
Datum: 27 .08.2013 19:53
0159
Hetlo,

this sounds really interesting. Let's tatk tomorrow.

Thomas Hesselmann

u rsp rüngtiche Nach richt


Von:
Datum: urens Lag, a l. August 2013, 19:35 :54
An: "Hessetmann, Thomas" <thomas.hesselmannGbsi.bund.de>
Kopie:
Betr.: Re: IRenesas] possibly unsecure RSA key generation

> Hello,

fanrn* r can.heip, 1o:oo tomorrovr. ls a gooo roea' Tne orner prrme


.Jome interesting properties when shown in binary.

] a"*'s tatk tomorrow.

> Best regards,


lr
] Orotins "Hessetmann, Thomas" < :

l]r"..o-
> > reatly great thanks for your tink. Meanwhite it seems to us, that
> > possibly the
> > TOE is certified in 2gg7/2008 and not by Brightsight. It seems a tittle be
> > strange, that one of the primes does contain so many 0. Atso one other
p rime
>-2 contains *24922492924992*. Because of the postprocessing of the chip
?tll, cannot be generated (practicatty) in this TOE. Wett, the other ITSEF
has
> > contacted the devetoper and asked for more information.

> >> I tried to catt you but there was no anslrer. If you woutd like to talk,
> >> please propose a timestot,which is good for you
> > If you have more informations we should tatk. Proposat: tomorrow, 28.08,
> > 10:90. otherwise the other ITSEF has to foltow the incident ... as long as
> > they a re invotved.
> > Thanks for your informationl
> > Best regards
> > Thomas Hesselmann

> > Unfortunately I will be out of the office in the weeks 4l-42, 52-92.
Du ring

I t::t: ::T:1:i:]:::::::::: ::l:r:: Y: i:i]:


i>
> > Bundesamt für Sicherheit in der Informationstechnik
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 165 #2

> > Dr. Thomas Hesselmann


> > Referat 522
> > Godesberqer Altee 185 -189
> > 53175 Bonn
0160
> > Postfach 20 03 63
> > 53133 Bonn
> > Tetefon: +49 (0)228 99 9582 5691
> > Tetefax: +49 (0)228 99 10 9582 5691
> > E-Mail: Thomas.Hessetmannr0bsi.bund.de
> > Internet: wwu.bsi.bund.de
www. bsi- f ue r- bue roer. de

ursprüngliche Nachricht
> > Von:
> > Datum: äenstag, 27. nugust 2013, 15 :31:02
> > An: "Hesselmann, Thomas" <thomas.hesselman
> > Kopie:
>-i, Betr.: Re: IRenesas] possibty unsecure RSA key generation
-v
-t)) >>
> Dear mr. Hesselmann,

> >> I am back in the office, if you'd like we coutd have a chat about the RSA
KG
> >> thing. It woutd have to be before friday, though, after that I wilt be on
a
nr,tray for two weeks
I ::
> >> If you don't have them by now, the stides of the presentation can be
> >> downloaded at
> >> http://crvoto.2013. rumo.cr.vp.tol55e2988c4ed3c9f635c9a4c3f52fa0b1.odf
> >> I tried to catt you but there was no answer. If you would like to tatk,
> > please
> >> propose a timestot which is good for you.
> >> Best regards,

t;
> >> 0n Friday 23 August 2013 17:11:03 you urrote:

Dr. Lochter, He has already asked the authors for


mo re
uretl ure wilt see, urhat is coming up. If possibte I
witt
the next HW-Forum,
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 166

,
> This message was '
sent using IMP, the Internet Messaging Program.
0161
MAT A BSI-1-6c_3.pdf, Blatt 167

01 62

Comments on Crypto 2013 Ramp-Session


Presentation about Weak Taiwan Citizen Digital
Ceftificates
Wolfgang Killmann, 28.08.2013

The lssue

Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja
Lange and Nicko van Someren gave a presentation on Crypto 2013 ramp-session "Factoring
RSA keys from certified smart cards: Coppersmith in the wild" available on fl1. The authors
analyzed Taiwan Citizen Digital Certificates issued for government-issued smart cards (slide
2 shows the MOICA card). They discuss a hypothesized key generation process for weak
primes (slide 9) and hypothesized reasons (failure) why government-issued smartcards
generating weak keys (slide 16). On the 2d slide is a statement'FIPS-140 and Common
Criteria Level 4+ certified", where it is unclear what component is meant: the smartcard
application, the operating system (OS) or the integrated circuit (lC). Unfortunately, the vocal
presentation is not available for additional information.

The following comments discuss the key generation for Taiwan Citizen Digital Certificates
and whether Common Criteria certified components might cause the weakness discussed in
this presentation.

The term .RSA key generation" refers to the generation of the two prime numbers p and q,
which product build the modulus n and if a fixed public exponent e is assumed also define
the private exponent d.

Summary of the presentation about RSA generation used for Taiwan Gitizen Digital
Certificates

The authors of the presentation analyzed 3,002,000 certificates for RSA keys available from
Taiwan national LDAP directory and found 2.3 million distinct 1024-bit RSA moduli, 700,000
2048-bit moduli (cf. slide 3). Note The Certificate Authority of Ministry of lnterior (MOl) issued
a total number of 3733239 certificates (2013108128).

They apply an algorithm finding common prime numbers in different moduli and found
commonly shared factors (cf. slides 7, 8):

(1) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000002f 9
(2) c9242492249292499249492449242492249292499249492449242492249292499
249 4924 492424922 49292 499249 492 449242492249292499249 4924 492424e5

Based o these primes they assume a hypothesis about the prime number generation
algorithm (cf. slide 9) and apply factorization algorithms based on hypothesis on specific
types of prime numbers in the moduli (cf. slides 11 and 14):

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 168

0163
(3) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000101f f
(4) c0000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000100000r-77

(5) ffffaas5ffffffffff3cd9fe3ffff616fffffffffffe000000000000000000000
00000000000000000000000000000000000000000000000000000000000009d

(6) c000b800000000000000000000000000000000000000000000000000000000000
0000680000000000000000000000000000000000000000000000000000002s1

Based on their findings the authors conclude hypothesized failure

(1)a weak algorithm were used for generation of the prime numbers (cf. slide 9) and

(2)possibly weak random number generator was used (cf. slide 16), especially

a) hardware ring oscillator gets stuck in some conditions,

b) card software not post-processing RNG output.

Key Generation for Taiwan Citizen Digital Certificates

This chapter analyzes public available information about the key generation for the Taiwan
Citizen Digital Certifi cates.

1.1.CSP of Ministry of the lnterior Certification Authority

The slides of the presentation do not provide details about the certificates with found weak
RSA keys like issuer, validity of the certificates, Certification Policy or Certification Practice
Statement (CPS).

The CSP of Ministry of the lnterior Certification Authority (MOICA) is issued as version 1.0 in
2003-04-03 and last updated as version 1.6 in 2013-06-11 (cf.
http://moica.nat.gov.tw/html/en/cps.htm). Only the versions 1.2 issued in 2003-11-26 was
found in English translation. The CPS Version 1.6 in Chinese is available from the website
http://moica.nat.gov.tMdownload/MOICA_CPS_V1 .6. pdf.

The CPS, version 1 .2, states in chapter 6.1 .1 Key pair production:

,,Based on the provision of section 6.2.1, this authority will produce key pair within the
software cryptographic module and will adopt true randorn number generator and RSA key
calculation method. After the production of private key within the hardware cryptographic
module, it will be stored there all along and will not be leaked out."

"The token utilized by the subscriber is lC card. For its key pair, after the card management
center has driven the lC with the safety control system, it will be produced on its own within
the lC card. ln addition, after the key pair production is completed, its private key cannot be
transmitted from the lC card."

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 169

4164

Further statements are in chapter 6.1.7 Key parameter quality inspection:

"This authority adopts ANSI X0.31 calculation method to generate the prime number required
by RSA calculation method. That method can guarantee that the prime number is strong
prime.

Subscriber's key can generate the required prime number in the RSA calculation method
inside the lC card or other software and hardware cryptographic module. However, it is not
guaranteed that such prime number is strong prime."

The descriptions of key generation in chapter 6.1.1 and 6.1.7 in CSP version 1.2 are contra
dictionary. Therefore, few detected weak RSA keys might be produced by software and
hardware cryptographic module, not by lC card.

Note, Google translation of CSP, version 1.6, section 6.1.7 seems requiring that "the user is
using the security level through FlPS140-2 Level 2 certification the user smartcard Security
lC card hardware cryptographic modules". [2] refers to the MOICA FAQ that cards are "high
security", and "have been accredited to FIPS 140-1 level 2" (cf. chapter 4.1 below).

1.2.MOICA Smartcard

Suppose the weak RSA keys, i.e. the prime numbers p and q of the module n are generated
by the smartcard used as subscriber token. What is known about security assessrnents of
the MOICA smartcard?

MOICA states on his homepage [3]:

"lf an applicant loses his/her/its lC card, and the card is picked up by someone, can the card
information be stolen out?

A: The CA keys are created in a cryptographic module, using RSA algorithm and random
number generator. Created within a hardware module, the private key is stored inside without
leakage. Moreover, certificate subscriber's lC card is internally generated with FIPS 140-1
level 2 certification of the Card Center. The private key will not export after generation."

MOICA does not provide technical information about the subscriber lC card product itself.

The company lDpendant GmbH, a member of the TRÜB Group, informs on its website [4]
about a reference project [5] for the MOICA card. The described solution is based on the
SafeSign ldentity Client of AET. AET provides the SafeSign ldentity Client with JCOP smart
card. lDpendant provides other smartcards as well, cf. [6] (2008) including

. IBM Java card OS JCOP21 v2.3.1 (CC EAL4+; on NXP chip P5CC036172,
P5CD036/72 and P5CTO72 (all CC EALS+),

. Giesecke&Devrient Sm@rtCafe Expert FIPS 64 (FIPS140-2 level 3) and Sm@rtCafe


Expert 64 Bio on Renesas chip AE46C1 (CC EALS+),

. |-COS 36 on ST Microelectronic chip ST19XT34

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 170

0165

and other smartcards. JCOP v2.3.1is evaluated by TÜVIT and certified by BSl. Sm@rtCafe
Expert FIPS 64 is F|PS140-2 level 3 accredited. The Sm@rtCafe versions provided by
lDpendant are not CC evaluated, but Sm@rtCafe version 5.0 is evaluated by TÜVIT. All NXP
and Renesas mentioned chips are CC EALS+ (including AVA_VAN.S) evaluated by
T-Systems and certified by BSl. The chip ST19XT34 is according to [] EAL4+ evaluated but
the corresponding certificate was not published B] t91 The OS i-COS 36 is neither evaluated
nor accredited.

[10] refer to private communication with a supplier of MOICA card (probably lDpendant
GmbH) that his MOICA cards are EAL4+ certified and accredited to FlPS140-2 level 2. This
does not fit with [11].

Based on the referenced public available information one cannot concluded about the
concrete MOICA card implementation which could have generated weak RSA keys.

RNG used in MOICA smartcard chips and their successors

[12] states in chapter 2.1:

"lt is clear from our results that the random-number generators used in these cards are in
fact awed, and that any keys generated using these cards should be considered insecure."

The hardware'random number generator (RNG) of the chip is an important but not the only
smartcard component involved in RSA key generation. The OS of many state of the art
smartcards is responsible for online testingl and post-processing of the generated random
numbers. Even the current state of the art smartcard chips do not generate RSA keys. Only
the combination of hardware RNG of the chips and OS generates RSA keys. Therefore the
weak RSA key generation may be caused by errors in the usage of the hardware RNG
output and key generation as well.

This chapter discusses generation and use of random numbers for RSA key generation.

1.1.RNG of FIPS 140-2 accredited smartcards

Ghapter 2.3 discusses random number generation and states:

"As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any
run-time testing before generating keys, and they clearly do not apply any post-processing to
the randomness stream. The lack of testing or post-processing causes the initial
randomness-generation failure to be much more damaging than it would have been
otherwise."

They authors refer to standards (NIST SP 800-90A, ANSI X9.31 :1998) and evaluation criteria
(FIPS 140-2, BSI AIS for CC evaluation / certification) for RNG. They missed the fact that
NIST SP 800-90A and ANSI X9.31:1998 describe deterministic RNG only. FIPS 140-2
require approved RNG but only deterministic RNG are approved so far.
1 Note the newest NXP chips implement online tests in hardware.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 171

a1 66

FIPS 140-1 level 2 smartcards are required to implement statistical power-on tests. The
power-on test will not effectively protect against failure during operation and perturbation.

FIPS 140-2, chapter 4.9, requires a continuous random number generator test, which
requires to compare any nevrl generated n bit block (n>15) with the previous generated block
and the test fails if bit blocks are equal. lf the length of any repeated pattern does not divide
the output length of the compared pattern the test will not detect the bad random numbers
(e.g. if the pattern has odd length and the compared pattern has even length the consecutive
blocks may be different and the test fails).

lf the MOICA card is FIPS 140-2level 2 accredited the continuous random number generator
test should detect the patterns causing the weak keys by repeating short bit sequences in
the prime numbers shown above and in the Annex A of [13].

1.z.CC evaluated RNG according to AlS20 / AlS31

The BSI requirements for Common Criteria (CC) RNG evaluation laid down in AIS 20'l AlS31
address

(1) the generation of entropy,

(2) the post-processing if implemented,

(3) the quality of the RNG output,

(a) the health test (tot test and online test) detecting failure after start-up and during RNG
operation.

The requirements shall prevent the weaknesses discussed in [4]:

The T0 test (disjointness test) as part of test procedure A of PTG1 and PTG.2 class
RNG will detect repeated patterns in the RNG output during the evaluation. The
PTG.3 class RNG prevents such patterns by means of cryptogr.aphic
post-processing.

The tot test shall detect break-down of the entropy source and prevent bad random
numbers output for PTG.1, PTG.2 and PTG.3:

"A total failure fesf defecfs a total failure of the entropy source immediately when the
RNG has stafted. When a total failure is detected, no random numbers will be
output."

The online test shall detect non-tolerable statistical defects of the raw random number
sequence immediately when the RNG has started, and while the RNG is being
operated. lt is a quality check of the generated random numbers usually realized by
hardware by physical measurements, or by OS as statistical test or a test procÖdure

2 The first n bit block generated after power-up, initialization or reset is only stored and compared
with the next n bit block.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 172

01 67

that applies several statistical tests. lt shall detect bad random numbers output for
PTG.2 and PTG.3.

Roughly speaking the tot test shall detect very bad random numbers very quick (short
seqüentesl and the online test other non-tolerable weak random numbers slowly.

Some RNG prevent with high probability repeated short patterns in. the RNG output
probability
additionally by design. The poit-piocessing with internal memory may reduce the
of repeated patterns and stores some iniernal entropy to mitigate temporary low entropy
output of the source of randomness. E.g. the BSI CC-certified Renesas chips are AIS 31
coÄpliant and provide post-processing by linear shift registers (LFSR). Some chips allow the
OS to enable / disable the post-processing'

The RNG of smartcards under evaluation may be implemented completely in hardware or as


combination of hardware and software (OS) components. lf the RNG is implemented as
combination of lC and OS components the OS components shall be precisely described in
the guidance documentation and are subject of the lC evaluation. lf the OS developer
impläments the certified software components the RNG evidence of the lC evaluation are
applicable for the smartcard. lf the OS developer deviates from the guidance documentation
tfid os developer shall provide additional evaluation evidence and the composite evaluation
shall analyze the modified RNG.

The failure of the hardware RNG is not the only possible source of failure of the RSA key
generation. The OS using the hardware RNG shall obey _the guidance-.documentation
äescribing the method of uie of the hardware RNG which is iC evaluated. lf the guidahce is
not obeyäd the operating developer cannot rely on the certified security functionali§ of the
RNG.

Typical errors of hardware RNG usage are:

. The OS may read the hardware RNG output register before the start-up tests after
power-on,.sleep mode or soft-reset are completed. The RNG output register may
äontain undefined or constant values (e.g. zeros or short patterns as seen in the
weak prime numbers).

. The OS does not implement and run online tests even if required by the guidance
documentation of the certified lC. This might speed up the key generation process but
with bad random numbers.

o The OS does implement and run RNG tests different from those described in the
guidance documentation of the certified lC. These tests might not be non-appropriate
for the hardware RNG used

o The OS read the hardware RNG interface in short intervals not obeying the time for'
generation of fresh random numbers in the output register of lhe hardware RNG
äescribed in the guidance documentation. Note the hardware RNG may generate the
shorter internal rändom numbers and sequentially fill the output register' ln this case
the output register will contain fresh and old random numbers if read before
refreshing the whole output register.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 173

0168

Summary

The available information is not sufficient do decide about the reasons for generation of weak
RSA prime numbers in the RSA moduli in some Taiwan Citizen Digital Certificates. The
conclusion made in [1S] and [16] about failure of hardware random generator of the MOICA
smartcards is only one of possible reasons.

The reason for the detected weakness shall be analyzed by (i) checking whether the weak
RSA keys were generated by the MOICA cards or not, and (ii) if smartcard key generation is
confirmed by anälysis of RNö implementation and usage in the MOICA smartcard.

References

J. Bernstein, Yun-An Chang, chen-Mou _C!gng, Li-Ping chou.,.Nadia Heninger,


' Tanja Lange,
[17]Daniel
Nicko van Someren: Factoring RSA keys from certified smart cards:
Coppersmiln in the wild, slides of ramp-session presentation at - Crypto 2013,
frttö'rcrypto Z0t 3 rump cr yp to/55e2988c4ed3c9f635c9a4c3f52fa0b1 Pdf

[18] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng,


Li-Ping Chou,.-Nadia Heninger,
Tanja Lange, and Nicko van Someren: Factoring RSA keys frgq certified smart cards:
Cofpersmith in the wild, paper to be presented at ASIA Cryp12013

[1 9] http:l/www. idpendant. de/loesungen/egovernment' html

t20l

l21l
[22] http ://www. com moncrite riaportal. org/prod ucts/

[23] http.//www. ssi. gouv.frlen/products/certified-products/

[24] http. //mo ca. n at. gov. twi htmllenii ndex. htnr, FAQ 0502
i

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 174

Re: AU: lRenesasl unsichere RSA-Schtüssetgenerierung


Von:
An:
Kopie: 016
"Krause. Christian" <christian.krauseGbsi.bund,de>,
"Kiltian, Gereon" <oereon. killian@bsi.bund.de>
Datum: 28,08.2013 11:28

Hatto

weitere mündtiche Informationen habe ich erhatten:


- betroffene TOE: höchstwahrscheintich AE489, wobei das in der Draftversion
des Papers (tiegt mir nicht vor) nicht gesagt wird.
- Schtüsset werden mittels der Smartcard erzeugt.
- auf Grund PerformanceprobLeme hat man beim Post-Processing etwas gespart
(was gespart wurde, habe ich nicht erfahren, meine Vermutung: den
0nline-Test )
* Der betroffene Composite-Herstetler ist bereits dabei, das Probtem zu lösen.
- bei anderen Produkten des Smartcard-Herstelters hat man dieses Phänomen noch
-irht beobachtet.
!rch finde es kritisch,dass der Rauschgenerator überhaupt sotche wiederhotbare
Patterns ausgibt
es passiert aber woht nur recht setten, sonst wäre das
Probtem öfters aufgetaucht.

Grüße
Thomas Hesselmann

Unfortunatety I wilt be out of the office in the weeks 41-42, 52-92. During
this time I wilt be unable to repty to your mail.

Bundesamt für Sicherheit in der fnformationstechnik


Dr. Thomas Hesselmann
Referat S22
Godesberger Altee 185 -189
aonn
Js
. ostfach 20 03 63
53133 Bonn

Tetefon: +49 (0t228 99 9582 569f


Tetefax: +49 (0)228 99 10 9582 5691
E-Mail: Thomas. Hessetmann@bsi. bund . de
Internet: wvlr+. bsi. bund . de
wr"rw. bsi- f ue r- bue roe r. de

ursprüngLiche Nachricht

Von: "Hesselmann, Thomas " <thomas . hesselmann@bsi. bund . de>


Datum: Dienstag,27. Auqust 2013,16:31:34
An:

"Krause, Christian"
<christian.krause@bsi.bund.de>, "Kittian, Gereon"
<@>
Betr.: Re: AW: IRenesas] unsichere RSA-Schlüssetgenerierung

I
MAT A BSI-1-6c_3.pdf,
filel.lll Blatt 175 #2

> die Präsentationsfotien hiervon findet man unter

> httD / I crvoto.


z 2013. rumD . c r. vo . tol55e2988c4ed3c9f635c9a4c3f52fa
417 0
> Grüße
> Thomas Hesselmann

) ---:
> Unfortunately I will be out of the office in'the weeks 41-42,52'02. During
> this time I witt be unabte to reply to your mail.

> Bundesamt für Sicherheit in der Informationstechnik


> Dr. Thomas Hessetmann
> Referat S22
> Godesberger Attee 185 -189
> 53175 Bonn
> Postfach 20 03 63
aonn
frs3
, Tetefon: +49 (0)228 99 9582 5691
> Tetefax: +49 (0)228 99 10 9582 5691
> E-Mail: Thomas.HesselmannGbsi,bund.de
> Internet: &bs:L.U-UId.Jg
www. bsi- fue r- bue roe r . de

ursprüngliche Nachricht
Von: "Hesselmann, Thomas " <thomas . hesselmänn6bsi. bund . de>
E tao.23. Auqust 2013, 17: 18: 15

"Krause, Christian"
, "Kittian, Gereon"

Betr.: Re: AtI: IRenesas] unsichere RSA-Schtüssetgenerierung

| *u..o
> > wir bemühen uns um mehr Informationen, aber fotgendes scheint sich zu
> > bestätigen (altes noch ohne Gewähr):
> > - Produkt ist beim BSI zertifiziert worden, evatuiert anscheinend von
> > T-Systems
> dass
> > der FIPS-Tests (??) nicht durchgeführt wurde (gute N.achricht für uns)

> > erhatten


> > Der Angriff solt auch kurz auf der Rump Session der Crypto vorgestettt
> hrorden
> > sein.
> > Nächste Woche erfahre ich vielteicht mehr.

> > Grüße


> > Thomas Hesselmann

> > Unfortunately I witt be out of the office in the weeks 4L.-42,52-92,
filel.lll #3
MAT A BSI-1-6c_3.pdf, Blatt 176

Du ring
> > this time I witl be unable to reply to your mail.
417 1
> > Bundesamt für Sicherheit in der Informationstechnik
> > Dr, Thomas Hessetmann
> > Referat S22
> > Godesberger Attee 185 -189
> > 53175 Bonn

> > Postfach 20 03 63


> > 53133 Bonn
> > Telefon: +49 (0)228 99 9582 5691
> > Telefax: +49 (01228 99 10 9582 5691
> > E-Mait: Thomas.HesselmannGbsi.bund.de
> > Internet: wt'rw.bsi.bund.de
www . bsi - f ue r- bue roe r . de

u rsprüngliche Nachricht

rrer-tag, 23, August 2013, lo:53t09


Qri;u
> > Kopie:
> > §qnl-@
> > Betr.: AW: IRenesas] unsichere RSA-Schtüsselgenerierung

Renesas - Chips
> > bekannt.
> > Betriebssystemherstetter oder von Renesas geliefert wird, Der Chip selbst
> > erzeugt keine RSA-Schlüssel.

sotlten,
>so
> > könnte es sich z.B. um

Q'U::;lt version 01 BSr-DSz -cc-s774-2sLr

> > Krypto-Bibliotheken zertifiziert (2.8. Chip HD65256D1, Brightsight BV,


> > BSr-DSZ-CC-0529-2010).

,a
> > > mall:
>>>Tel:
> > > E-Mail:
G f Mobiler*,-

E
#4
MAT A BSI-1-6c_3.pdf, Blatt 177

>>>Ust.-IdNr 017 2
> > confidential. If you are not the intended recipient, you are hereby
notified
> > that you have received this transmittal in error; any review,
dissemination,
> > or copying is strictly prohibited. If you received this transmittat in
> error,
> > ptease notify us immediatety by reply and immediately detete this message
> and
> > att its attachments. Thank You.

>>>Gese
>>> An:
>>> Cc: Krause,' n; Kittian, Gereon
IRenesas] ünEichere RSA-Schtüssetgenerierung

?rHarlo

> > Renesas-Chip. Das Probtem sotl sein, dass schwache RSA-Schtüsset erzeugt
> > werden. Der Angriff soll (so wie ich es verstanden habe) auf der ASIA
C rypt
> > vorgesteltt werden. Wahrscheinlich findet man dann auch eine entsprechende
> > Veröffentlichung auf ePrint.

> > betroffen?

I witl be out of the office in ihe weeks 4L-42,52-02'


Qr;r:;t"rtunatety
> > this time I witt be unable to repty to your mai1.

Hesselmann
> > Referat 522 Godesberger Atlee 185 -189

> > Thomas.Hessetmann@bsi.bund.de<maitto:Thomas.Hesselmann@bsi.bund.de>


www. bsi - f ue r- bue roer, de<htto : //www. bsi - f ue r- bue roe r. de>
file:.lll #1
MAT A BSI-1-6c_3.pdf, Blatt 178

Re; Fwd: Re: lRenesasl possibty unsecure RSA key generation


Von:,'Hessel.mann, Thomas', <thomas.hesselmann(öbsi.bund,de> (BSI Bonn) 417
An: Manfred Lochter <Manfred.Lochter@bsi'bund.de>, "Schindler' Werner"
.ure rne r. schindte r@bsi ' bund . der '
igaU.i"t."t. lUrirn. .aOiian. grUti"I@bti. brnO.O"r, "Gamero. Octavio"
<octavio.gameroObsi.bund,de>, "Kitlian' Gereon" <oereon.kiltianGbsi'bund'de>
Datum: 28.08,2013 11:30

Hallo,

weitere mündtiche Informationen habe ich erhattenr


- betroffene TOE: höchstwahrscheintich AE489, wobei das in der Draftversion
des Papers (tiegt mir nicht vor) nicht gesagt wird'
- Schlüssel werden mittels der Smartcard erzeugt'
- auf Grund Performanceprobteme hat man beim Post-Processing etwas gespart
(was gespart wurde, habe ich nicht erfahren, meine vermutung: den
0ntine -Test )
- Der betroffene Composite-Hersteller ist bereits dabei, das Problem zu lösen'
- bei anderen produkten des Smartcard-Herstelters hat man dieses Phänomen noch
nlht beobachtet.
?rrn6" es kritisch, dass der Rauschgenerator überhaupt solche wiederhotbare
Patterns ausgibt es passiert aber wohl nur recht setten, sonst wäre das
Probtem öfters aufgetaucht,

G rüße
Thomas

ursprüngtiche Nachricht

Von: "Hesselmann, Thomas" <thomas.hessetmannt0bsi'bund'de>


Datum: Dienstag, 27. August 2013, 18:58:35
An: Manfred Lochter <Manfred.Lochter@ , "schindter, Werner"
<werner.schindter , "Krause, Christian"
<christian.krause , "Gabriel, Adrian"
<adrian,oabriettabsi.bund.de>, "Gamero, 0ctavio"
.oat*i**"aoouri.u Gereon" <oereon.kiltian@b
Kopie: "r,,'Kittian,
: Re: Fwd: Re: lRenesasl possibty unsecure RSA key generation
ö
> Hatlo,
> im fotgenden ein kteines Update nach Tetko mit T-Systems '

> 1) Wenn es ein Renesas-Produkt betrifft, so ist wohl AE57C1. Es ist


2097/2008
> zertifiziert worden.
> 2) Es ist etwas komisch, dass einer der Primzahten so viete 0 hat. Der TRNG
> von AE57C1 hat einen linearen Schieberegister als Nachbearbeitung. Wenn der
> TRNG nicht mehr funktioniert, dann müsste man nur noch 0 oder (je nach
> internem Zustand) nur "zufällige" Werte erhalten.
> 3) Auch die Generierung von *24922492924992* ist komisch (wegen tinearen
> Schieberegister bei Nachhbearbeitung)
> 4) T-Systäms wird Renesas (mit Verweis auf Link) nach mehr Informationen
> nachfragen.
G rüße
Thomas

u rsprüngliche Nachricht
Von: "Hessetmann, Thomas" <thomas'hesselmann@bsi.bund'de>
fitelll #2
MAT A BSI-1-6c_3.pdf, Blatt 179
> Datum: Dienstag, 27. August 2013, 16:29: 10
> An: Manfred Lochter <Manfred'Lochter@ ' "schindler' werner"
> <v,,e rne r. schindle r 017 4
> Kopie:
> Betr. l Fwd: Re: IRenesas] possibly unsecure RSA key generation

weitergeleitete Nachricht
> > Von:
> > Datumr Dienstag, 27' August 2013, 15:31:02
> > An: "Hesselmann, Thämas" <thomas.hessetmann@bsi.bund'de>
> > Kopie:
> > Betr.: Rer IRenesasl possibty unsecure RSA key generation

> > Dear mr. Hessetmann,

>> I am back in the office, if you'd tike we coutd have a chat about the RSA

KG
> > thing. It would have to be before friday, though, after that I witt be on
a
> > hotidav for two treeks'

Q * you don,t have them by now, the stides of the presentation can be
downtoaded at

> > I tried to calt You but there was no answer. If You would tike to talk,
> ptease
> > propose a timestot which is good for you.
> > Best regards,

o
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 180 #1

Re: All: lRenesas] unsichere BSA-Sahtüsselgenerierung


Von: "Hessetmann. Thomas" ( BSI
417
llor",
Krause, Christian" <christian.krause@bsi.bund.de>,
Gereon" <qereon.kiltian@bsi.bund.de>
"Killian,
Datum: 28.08.2013 11 r58

Korrektur:
TOE zertifiziert unter BSI-DSZ-CC-0489

ursprüngtiche Nachricht
Von: "Hessetmann , Thomas " <thomas . hesselmann@bsi . bund . de>
Datum: Mittwoch, 28. Auqust 2013, 11t28:28
An:
Kopie:
Krause, Christian"
, "Kittian, Gereon"
<oe reon . kittiant0b
Betr. : Re: AW: IRenesas] unsichere RSA-Schlüsselgenerierung

> Hallo
> weitere mündliche Informationen habe ich erhatten:
> - betroffene TOE: höchstwahrscheintich AE489, wobei das in der Draftversion
> des Papers (tiegt mir nicht vor) nicht gesagt urird.
> - Schtüssel werden mittels der Smartcard erzeugt,
> - auf Grund Performanceprobleme hat man beim Post-Processing etwas gespart
> (was gespart wurde, habe ich nicht erfahren, meine Vermutungl den
> Ontine-Test)
> - Der betroffene Composite-Herstelter ist bereits dabei, das Probtem zu
tösen
> - bei anderen Produkten des Smartcard-Herstetters hat man dieses Phänomen
noch
beobachtet.
ü.n.
, Ich finde es kritisch, dass der Rauschgenerator überhaupt solche
wiede rholba re
> Patterns ausgibt es passiert aber woht nur recht setten, sonst wäre
das
> Probtem öfters.aufgetaucht.
> Grüße
> Thomas Hessetmann

> Unfortunatety I will be out of the office in the weeks 4I--42, 52-92, During
> this time I witt be unabte to reply to your mail.

> Bundesamt für Sicherheit in der Informationstechnik


> Dr. Thomas Hesselmann
> Referat S22
> Godesberger Altee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 181 #2

> Tetefon: +49 (0)228 99 9582 5691


> Tetefax: +49 (0)228 99 10 9582 5691
> E-Mait: Thomas . Hesselmann@bsi . bund . de
> Internet: www. bsi. bund. de 017 6
wunr, bsi- fue r- bue roe r , de

ursprüngtiche Nachricht
> Von: "Hessetmann, Thomas" <thlmas.hessetmann@bsi.bund.de>
> Datum: Dienstaq, 27. August 2013, 16:3I:34
> An:
> Kopie:
"Krause, Christian"
, "Kitlian, Gereon"
> <oereon.kitlianGb
> Betr.: Re: Ald: IRenesas] unsichere RSA-Schtüssetgeneri.erung

> > Hatto

Q Oi" Präsentationsfotien hiervon findet man unter


> > http : //c rvDto . 2013 . rump. c r. vp . tol55e2988,c4ed3cgf635cga4c3f52faob1 . pdf

> > Grü8e


> > Thomas Hessetmann

> > unfortunately r witl be out of the office in the weeks 41-42, s2-02.
Du ring
> > this tine I wilt be unabte to repty to your mait.

> > Bundesamt für Sicherheit in der Informationstechnik


> > Dr. Thomas Hesselmann
> > Referat S22
> > Godesberger Attee 185 -189
> > 53175 Bonn
Opo.rfrch 2o o3 63
> > 53133 Bonn
> > Telefon: +49 (0)Z2B 99 9592 5691
> > Tetefax: +49 (0)228 99 10 9582 5691
> > E-Mait: Thomas.HessetmannGbsi,bund.de
> > Internet: www.bsi.bund.de
wwur. bsi- fue r-bue roe r. de

ursprüngliche Nachricht
> > Von: "Hessetmann, Thomas" <thomas.hessetmannGbsi.bund.de>
23. August 2913, 17:18:15

"Krause, Christian"
> > <christian.krauseGbsi.bund.de>,,'Killian, Gereon,'
> > <qereon.kitlian@bsi. bund. de>
> > Betr,: Re: AW: IRenesas] unsichere RSA-Schtüssetgenerierung
file:lll #3
MAT A BSI-1-6c_3.pdf, Blatt 182

0177
>> dass

> > worden


> > > sein.

]iIflr, time r will be unable to repty to your mafl.

www. bsi - fue r- bue rge r. de

t:l
t: ursorünoliche Nachricht

Freitag,23. August 2013, 10:53:09

>>>!
AW: IRenesas] unsichere RSA-Schtüssetgenerierung

sind z. Z. nicht im Büro verfügbar.


> Renesas-Chips

vom

setbst

> soltten,
>>so

> integrated
tile:lll #4
MAT A BSI-1-6c_3.pdf, Blatt 183

417 B

] I I ] ,r. freundtichen Grüßen / Best regards

>>>>l
>>>>]

ll'flr

ttschaft:

> notified
> dissemination,
> > error,
message
>>and

lv: r> >> Von: Hesselmann, Thomas [maitto:thomas.hesselmann@bsi.bund.del


Gesen{eti_Erqitag, 23. August 2013 09:42
> > > > An:
> > > > Cc: tian; Kittian, Gereon
IRenesasl unsichere RSA-Schtüssetgenerierung

einem

> Crypt
entsp rechende

Chips
fite:lll
MAT A BSI-1-6c_3.pdf, Blatt 184
#5

r wnr be out of the office in the weeks 41-42, sz-02. 017 9


I :;r;rilfortunately

> Hesselmann

o
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 185
#1

Re: Fwd: Re: lRenesasl possibly unsecure RSA key generation

Von: "Hessetmann, Thomas" <thomas.hesselmann@bsi.bund.de> (BSI Bonn)


An: Manfred Lochter <Manfred.Lochter@bii.bund.de> 0180
Kopie: "Schindler. l,lerner" <werner.schindler@bsi.bund.de>, @
<christian.krause@bsi.bund,de>, "Gabriet, Adrian" <adrian.oabriet@bsi.bund,de>, i§A-tng-f,q-
octavio" <octavio.oamero@bsi.bund.de>, "KiUian, Gereon" <oereon.kitlian@bsi.bund.de>
Datum: 28.08.2013 11:59

Ko r rektu r:
TOE zertifiziert unter BSI-DSZ-CC-0489
ursprüngtiche Nach richt
Von: "Hesselmann, Thomas" <thomas.hesselmann@bsi.bund.de>
Datum: Mittwoch,28. August 2013, 11:30r54
An: Manfred Lochter <Manfred'Lochter@ , "Schindler, Werner"
<hrerner.schindler , "Krause, Christian"
<christian.krause , "Gabriet, Adrian"
<adrian.gabrielGb , "Gamero, 0ctavio"
, "Kj-ltian, Gereon" <oereon'kittian(db
gätr.: Re: Fwd: Re: IRenesas] possibty unsecure RSA key generation

> Hatto,
> weitere mündliche Informationen habe ich erhatten:
> - betroffene TOEr höchstwahrscheinlich AE489, wobei das in der Draftversi-on
> des Papers (liegt mir nicht vor) nicht gesagt wird.
> - Schlüsset werden mittets der Smartcard erzeugt.
> - auf Grund Performanceprobteme hat man beim Post-Processing etwas gespart
> (was gespart wurde, habe ich nicht erfahren, meine Vermutung: den
> Ontine-Test)
> - Der betroffene Composite-Herstetter ist bereits dabei, das Probtem zu
tösen
> - bei anderen Produkten des Smartcard-Herstetlers hat man dieses Phänomen
noch
> nicht beobachtet.
n.t.tsch, dass der Rauschsenerator überhaupt sorche
k:*Ulri,
> Patterns ausgibt es passiert aber r*ohl nur recht setten, sonst wäre
das
> Problem öfters aufgetaucht.
> Grüße
> Thomas

ursprüngtiche Nach.richt
> Von: "Hessetmann, Thomas" <thomas.hessetmann@bsi.bund.de>
> Datum: Dienstag, 27. August 2013, 18:58:35
> An: Manfred Lochter <Manfred.Lochter@ , "schindler, werner"
>< , "Krause, Christian"
> <christian.krause , "Gabriet, Adrian"
> <adrian.oabriel@b , "Gamero, Octavio"
> <octavio.gamero@b , "Kitlian, Gereon" <gereon.kitlian@bsi.bund.de>
> Kopie:
> Betr.: Re: Fwd: Re: [Renesas] possibty unsecure RSA key generation

] ] "tto'
fite:lll #2
MAT A BSI-1-6c_3.pdf, Blatt 186
> > im folgenden ein kleines Update nach Telko mit T-Systems.

> > 1) Wenn es ein Renesas-Produkt betrifft, so ist woht AE57C1. Es ist
> 2007/2098 0181
> > zertifiziert worden.
> > 2't Es ist etwas komisch, dass einer der Primzahlen so viele 0 hat. Der
TRNG
> > von AE57C1 hat einen tinearen Schieberegister als Nachbearbeitung. Wenn
der
> > TRNG nicht mehr funktioniert, dann müsste man nur noch 0 oder (je nach
> > internem Zustand) nur "zufättige" Werte erhalten.
> > 3) Auch die Generierung von *24922492924992+ ist komisch (wegen linearen
> > Schieberegister bei Nachhbearbeitung)
> > 4) T-systems wird Renesas (mit Verweis auf Link) nach mehr Informationen
> > nachfragen.
> > Grüße
> > Thomas

J ron: "Hessetmann, Thomas" <thomas,hessetmann@bsi.bund.de>


E Datum: Dienstag, 27. August 2013, 16129:10
> > Anl Manfred Lochter <Manfred.Lochter6 , "Schindter, Werner"
> > <werner.schindler6bsi. bund'de>
> > Kopie:
> > Betr,: Fwd: Re: lRenesasl possibly unsecure RSA key generation

weitergeleitete Nachricht

Dienstag, 27. August 2013, 15:31:02


"Hesselmann, Thomas" <thomas.hesselmann@bsi.bund.de>

Re: IRenesas] possibly unse.cure RSA key generation

o
on
>a

> > ptease


tilezlll
MAT A BSI-1-6c_3.pdf, Blatt 187
#1

Re: Fwd: Re: [Renesasl possibly.unsecure RSA key generation


Bonn)
H:' .rlStr o1 B
Kopie: "Schindter, Werner" <werner.schindler@bsi.bund,de>, "Peter, Matthias"
<matthias.peter@bsi..bund.de>, "Wiemers, Andreas" <andreas,wiemers@bsi.bund.de>, -].l@Cr
Christian" <christian. krause@bsi.bund.de>, "Gabriet, Adrian"
<adrian.gabrietGbsi.bund.de>, "Gamero,0ctavio" <octavio.gamero@bsi.bund.de>, iKlLIiA!-
Gereon" <gereon. kiltiantdbsi. bund.de>
Datum: 29.08.2013 08:49
Anhänger ßj
r',. smartfacts. odf

Halto Thomas,

angehängt das paper dazu. Die Präsentation von der Crypto habt ihr ja schon.
Viele Grüße
Manf red

öP
{ sma rtfacts . odf
MAT A BSI-1-6c_3.pdf, Blatt 188

0183

Factoring RSA keys from certified smart cards:


Coppersmith in the wild

Danier J' Bemsteinl'', Nadia Heningers'


"'-*ll?.",.-"rlm-ffix,"l"Jä"'#l;rr "nou''
1 Department of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
djb@cr.yp.to
2 Department of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600MB Eindhovbn, the Netherlands
tanj achyperelliPtic. org
' 3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{ghfj dksl , doug}@crYPto . tw
a Depa.rtment of Computer Science and Information Engineering
Chinese Culture University, Taipei, Taiwan
ra:rdomalg@gnail. con
5 Microsoft Research New England
One Memorial Drive, Cambridge, MA 02142, USA
nadia.h@cs . princetou. edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
nicko@good ' con

Abstract. This paper explains how to efrciently factor 183 distinct RSA keys out of more
than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that sha.re primes and that are efficiently factored by a
batch-gcd computation. This is the same type of computation that was used last yea,r by two
independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman;
Crypto 2012: Lenstra, Ilughes, Augier, Bos, Kleinjung, Wachter) to factor tens ofthousands
of cryptographic keys on the Internet.
The remaining 80 keys do not share primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation failures: first using the shared primes as a springboard
to characterize the failures, and then using Coppersmith-type partial-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys found in
the wild.
Keywords: RSA, smart cards, integer factorization, Coppersmith, lattices

1 Introduction
In 2003, Taiwan introduced an e-government initiative to provide a national public-key infrastruc-
ture for all citizens. This national certiflcate service allows citizens to use smart-card ID cards to
digitally authenticate themselves to government services, such as filing income taxes and modi-
fying car registrations online, as well a,s to a growing number of non-government services. RSA
keys are generated by the cards, registered with a government authority, and placed into an online
repository of "Citizen Digital Certificates".
Unfortunately, the random-number generators used to generate many of these keys are fatally
flawed, and have generated real certificates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 189

ü184

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

inspect repeated primes,


batch gcd observe patterns,
generalize

Public-key 103
database secret keys
batch trial division

t2t
secret keys
batch trial division

t25
secret keys
prrmes
primes

172
secret keys

183
secret keys

Fig. 1. Retrospective summaxy of the data flow leading to successful factorizations. After successfully
factoring keys using a batch gcd algorithm, we characterized the failures, and used trial division to check
for broader classes of specified primes (input on the right) as exact divisors. We then extended the attack
and applied Coppersmith's method to check for the specified primes as approximate divisors.

This paper explains how we have computed the secret keys for 183 different certificates in use by
real people.

1.1 Factorization techniques


Bad randomness is not new. Last year two independent research teams [8, 11] exploited bad ran-
domness to flnd secret keys for tens of thousands of SSL certificates on the Internet, a similar
number of SSH host keys, and a few PGP keys.
Our starting point in this work is the same basic attack used in those papers against poorly
generated RSA keys, namely scanning for pairs of distinct keys that share a common divisor (see
Section 3). The basic gcd attack, applied to the entire database of Citizen Digital Certificates,
shows that 103 keys factor into 119 different primes.
We go beyond this attack in several ways. First, the shared primes provide enough data to
build a model of the prime-generation procedure. It is surprising to see ui,si,ble patterns of non-
randomness in the primes generated by these smart. cards, much more blatant non-randomness
than the SSL key-generatio-n failures identified by [8, 11]. One normally expects smart cards to
be controlled environments with built-in random-number generators, typically certifled to meet
various standards and practically guaranteed to avoid such obvious patterns. For comparison, the
SSL keys factored last year were typically keys generated by low-power networked devices such as
MAT A BSI-1-6c_3.pdf, Blatt 190

üx E5

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers and firewalls running the Linux operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime. factors: we hypothesize a particuiar model
of randomness-generation faiiures consistent with 18 of the common divisors. The same model is
actually capable ofgenerating 164 different primes, and testing all ofthose primes using batch trial
division successfully factors further keys. One might also speculate that the cards can generate
primes fitting a somewhat broader model; this speculation turns out to be correct, factoring a few
additional keys and bringing the total to 125. See Section 4 for a description of the patterns in
these primes.
There are also several prime factors that are similar to the 164 patterns but that contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice-based partial-key-recovery attacks to efficiently find prirne
divisors close to the patterns. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottom 40Vo ol the bits of the prime. The bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes thern particularly
susceptible to these attacks. These attacks produce dozens of additional factorizations, raising the
total to 183.
In the end nearly half of the keys that we factored did not share any common divisors with other
keys; most of these were factored by the Coppersmith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersrnith-style attack breaking keys in the wild.

1.2 Certification
The flawed keys were generated by government-issued smart cards that both the certification
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
Itis clear from their externally visible behavior, as shown in this paper, that the random-
number generators used to generate the vulnerable keys actually fall far short of these standards.
This demonstrates a failure of the underlying hardware and the card's operating system, both of
which are covered by certification. We have no explanation for the discrepancy.

1.3 Observed response and recommended response


When we reported the common-divisor vulnerabilities to government authorities, their response
was to revoke exactly the certificates sharing common factors and ask only those users to regenerate
keys. See Section 7 for more details.
Our further factorizations demonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themselves as primes appearing twice, but sometimes
manifest themselves as primes that appear only once, such as the primes that we found by
Coppersmith-type attacks. Both cases are vulnerable to attackers with adequate models of the
randomness-generation process, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for common divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much more than an indication that those particular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system, replacing
it with a properly engineered system and to revoke all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the prirnes generated by these smart cards had been modified to include a card serial number
as their top bits then the keys would have avoided common divisors but the primes would still
have been reasonably predictable to attackers. Our work illustrates several rnethods oftranslating
different types of malfunctioning behavior into concrete vulnerabilities. There are many potential
MAT A BSI-1-6c_3.pdf, Blatt 191

01 8,6

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vulnerabilities resulting from bad randomness; it is important to thoroughly test every component
of a random-number generator, not merely to look for certain types of extreme failures.

2 Background
2.L The Taiwan Citizen Digital Certificate prograrn
Taiwan's Citizen Digital Certificates (CDCs) are a standard means of authenlication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certificate Authority (MOICA), a level I subordi-
nate CA of the Taiwanese governmeutal PKI. Since the program's launch in 2003, more than 3.5
million CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates forrr a basis for the Taiwanese government's plan to migrate to electronic
certificates from existing paper certificates for a range of applications including national and other
identification cards, driver's licenses, and various professional technician licenses.
Taiwanese citizens can aiready use the CDC to authenticate themselves to a number of govern-
ment agencies over the Internet, in order to file personal income taxes, update car registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted'as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Certificate regi,stration: In order to generate a CDC, a citizen brings their ID card to a government
registration office. A government official places the (smart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed by MOICA. The certificate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Standard,s certificationsr MOICA states that these cards are "high security", and "have been
accredited to FIPS 140-1 level 2", and also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For comparison, the SSL keys factored last year were generated
by software-hardware combinations that had never claimed to be evaluaüed for cryptographic
security, such as Linux running on a home router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID program. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly all, of the problems we have identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS 140-1 level 2 [14]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certificates


In March 2012, inspired by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP directory at ldap://moica.nat.gov.tw. Out of these RSA keys, 2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The 1024-bit CDCs contain 2086177 distinct moduli, of which 171366 moduli appear more
than once. The repeated moduli appear to all be due to expired certifrcates still contained in the
database which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 192

,ü1 E7

Factoring RSA keys from certified smart cards: Coppersmith in the wild

2.3 Random Number Generation


While generating high-quality random-numbers is critical to the security of cryptographic systems,
it is also notoriously difficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial component of generating random numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, 1,6] specify correct behavior for these types ofsystems. In general, software pseudo-
random number generators require a significant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in the paper, the smart ca.rds used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any run-time
testing before generating keys, and they clearly do not apply any post-processing to the randomness
stream. The lack of testing or post-processing causes the initial randomness-generation failure to
be much more damaging than it would have been otherwise.

Analog RNG ci,rcu,itsr An analog circuit is the standard choice when hardware designers have the
luxury of designing dedicated circuits for random-number generation. An analog circuit allows the
designer to obtain randomness from siryrple quantum effects. While the use of radioactive decay is
rare in commercial products, the quanturn noise exhibiüed by a current through a suitably biased
diode can be amplified and sampled to deliver an entropy source of very high quality.

On-chi.p RNG ci,rcuits: Mixing analog and digital circuits on the same die is costly, so chip designers
often seek other sources ofunpredictability. These sources can include variation in gate propagation
delays or gate metastability, which exhibit inherent randomness. Designers can explicitly harness
gaüe-deiay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take advantage of randomness in gate rnetastability, designers
build circuits that output bits based on the time it takes for the circuit to settle to a steady state,
a variable which should be hard to predict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variations, and subtle on-chip effects such
as inductive coupling or charge coupling between components can cause free-running oscillators to
settle into synchronised patterns and metastable circuits to predictably Iand one way or the other
depending on öther components nearby on the chip.

Hand,li,ng Entropy Sources: Even with perfectly unpredictable source of randomness, care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density, test the signal from the entropy source at run
time, and run the output tirrough a compression function such as a cryptographically secure hash
function. These practices are required by a number of security standards such as FIPS 140 [14].

Batch gcd
This section reviews the approach of [8, 11] for detecting common factors in a collection of RSA
keys, and reports the results of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA moduli Nr : pet and .l[2 : pq2 sharing exactly one prime factor
p, then the greatest corrmon divisor of -l[r and l/z will be p. Computing this gcd is fast, and
dividing it out of Iü1 and lü2 produces the other factors (1 and Q2.
Of course, this type of vulnerabiiity should never arise for properly generated RSA keys. How-
ever, since [8,11] had observed weak random-number generators producing keys with repeated
factors in the wild, we began by checking whether there were repeated factors among the Citizen
Digital Certificates.
MAT A BSI-1-6c_3.pdf, Blatt 193

rüi
8B

D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

Instead of the naive quadratic-time method of doing this computation (checking each Iü
against each .l{2 ), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementation available at https:l f factorable.net/resources.html.
Wä ran this irnplementation on the 3L92962 distinct RSA moduli and found that 103 moduli
were factored due to nontrivial common factors. This computation, parallelized across four cores
of a 3.1GHz AMD FX-8120, finished in just 45 minutes.

Attacking patterned factors


A properly functioning random number generator would never generate identical 512-bit primes,
in the previous section immediately indicates
so the discovery of repeated prime factors described
that the random-number-generation process producing these keys is broken. This section analyzes
the structure ofthe repeated factors generated by the flawed random-number generator and designs
a targeted attack against this structure.
The 103 moduli with repeated factors show a remarkabie distribution of the shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appendix A.
One prirae factor, p110, appears a total of 46 times with different second primes. The hexadec-
imal representation of this factor is
c000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000002f 9

which is the next prime after 25tt a 2510.


The next most common factor, repeated 7 times, is
c92 4249 2249 29 2 49 I 249 49 24 49 242 49 22 49 29 2499 249 492 4 49 242 492249 29 249
g 249 49 2449 2 42 49 224929 249 g 249 49 24 49 2 42 49 22 49 29249 g 2 49 49 2449 2 42 4e $

which displays a remarkable periodic structure. The binary representation of this integer, excluding
a few most and least significant bits, is a repeated sequence ofthe string 001 with a "hiccup" every
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. We hypothesized that nearly every repeated prime factor had been generated using the
following process:

1. Choose a bit pattern of length 1, 3, 5, or 7 bits, repeat it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the most significant two bits to 11.
4. Find the next prime greater than or equal to this number.
We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and tested divisibility with each modulus. This factored a total of 105 moduli, including
18 previously unfactored moduli, for a total of l2l.
None of the repeated primes exhibit a (minimal) period of length 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods typically appear
in fewer keys than patterns with shorter periods, and are thus less likely to appear as divisors of
two or more keys, raising the question of whether there are primes with lalger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extended
this test to include length-9 periods and length-11 periods. The length-9 periods factored 4 more
keys but the length-ll periods did not factor any new keys, leading us to speculate that 3, 5, and
7 are the only factors of the period length. We then ran a complete test ou all length-15 patterns
but did not find any further factors. The total number of certificates broken by these divisibility
tests, together with the initiai batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 194

0189

Factoring RSA keys from certified sm §s: Coppersmith in the wild

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime factors dividing the same modulus.

Sporad,ic eryors: The handful of shared prime factors in our sample of gcd-factored keys that did
not match the above form were differing from patterns in very few positions. We experimented with
finding rnore factors using brute-force search starting from 0xc0. . .0 and found a new factors, but
these factors are more systematically and efficiently found using LLL in Coppersmith's method,
as described in the next section.

5 UnivariateCoppersmith
Several of the factors computed via the GiD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic error§. Coppersmith's
method [5,4] factors RSA moduli if the top bits of the primes are known, which matches our
situation if the errors äppear in the bottom few bits of a facüor. This section presents this method
following the variant by Howgrave-Graham [10] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factored.
The idea is as follows: we assume that some prime factor p of -lt is of the form
P:a+r
MAT A BSI-1-6c_3.pdf, Blatt 195

0190

8 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

where a is a 512-bit integer known to us (one of the bit patterns described in the previous section)
and r is a small integer error to account for a sequence of bit errors (and incrementing to next
prime) among the least significant bits of p.
In the Coppersrnith/Howgrave-Graham method, we can write a polynomial

f(*):o+*
and we would like to find a root r of / modulo a large divisor of N (of size approximately NL
/2 * p) .
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new polynomial g(r) where g(r) :0 over the integers, and thus we can factor I to
discover it.
We construct the iattice .L as
lx2 xa o1

L: ä i,l
corresponding to the coefficients of the polynomials N, f (Xr), Xrf (Xt), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of a polynom ial g(Xr). Then we compute the roots ri of g(r) and check if a * r,i divides -l{. If so,
we have factored N.
Any lattice vector is a Iinear combination of / and .l{ and is thus divisible by p. A prime p is
found by this method it g(r): 0 mod p holds not only modulo p but over the integers. The latter
is ensured if the coefficients of g are sufficiently small. The shortest vector u1 found by LLL is of
length
r-1)/4(det L)1/ dim t
lt,1 | < 2(ai* ,

which must be srnaller than p for the attack to succeed.


In our situation this translates to
Ytz 1ye N)\/u . *r,, <+ X < 2-r/2 XJ7/6 ,

so for .l{ - 2Lo2a we X as large as 2170, meaning that for a fast attack using dimension-
can choose
3 lattices up to the bottom third of a prime cau deviate from the pattern o. In the following
we ignore the factor 2@imL-l)/a since all lattices we deal with are of small dimension and the
contribution compared to Iü is negligible.

5.1 Experimental Results


A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this method for one of the 164 patterns identified in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including alt 105 keys derived from the patterns without error, and
found 39 previously unfactored keys.
It is worth noting that the 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000. . .0f . Including 0xd0000. . .0, 0xe00OO. . .0, 0xf0000.. .0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation might set the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's method can find primes with errors in up to ll2 of their bits using lattices of
higher dimension. Getting close to this bound is prohibitively expeusive, but trying somewhat
larger dimensions than 3 is possible. For dimension 5 we used basis

{N2, N !(nx), 12@x),rx f2(rx),(rx)z 72(rx)\


MAT A BSI-1-6c_3.pdf, Blatt 196

019t

Factoring RSA keys from certified smart cards: Coppersmith in the wild

whiclr up to LLL constants handles X < Nr/5 , i.e. up to 204 erroneous bottom bits in p for .lü of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
ma,king it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe000 . . . f. (2511 +26 to 12sos 1 15) appeared as a common factor after taking GCDs but
was not be found by the lattice attacks described in this section starting from the basic patterns
described in Section 4. Coppersrrith's attack also works to search for errors in higher bits ofp by
defining the polynomial / as f (r) : a + 2t r . Here t is the offset loca,tion of the errors we hope to
learn and the same method will find errors of the form 2tr with r I X.
However, since we hypothesize that the prime factors are generated by incrementing to the next
prime after a sequence of bits output by the flawed RNG, we do not know the least significant bits
of a because they are modified in the prime generation process. This problem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for more strings a: For each of the 164 basic patterns include all 2*-r
variations of the bottom rn bits with the LSB fixed to 1. This will find factors if finding the next
prime from the base string did not require more than those bottom rn bits {o change.
A brief analysis suggests that for this attack to have a 50% chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prime is approximately l/lnz. See [7] for an overview and more precise statements.
In our case of primes around 2572, each number has about a i/355 chance of being prime. Since
1 - (1 - 1/355)256:0.514290, trying 128 patterns for the bottom eight bits for odd patterns has
a 50% chance of covering a sufficiently large interval to find a prime. For our implernentation this
corrputation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be fouud with this search but the method presented in the following section is more
efficient at handling errors in top and bottom positions unless a very large portion of the top bits
are erroneous.

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring in the least significant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most significant bits of one of the factors,
without resorting to brute-forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of I{ has the form

P: a+Zts*r
where o is a 512-bit integer with a predictable bit pattern (as described in Section 4), t is a bit
offset where a sequence of bit errors s deviating from the predictable pattern in a occurred during
key generation, and r is an error at the least signiflcant bits to account for the implementation
incrementing to the next prime.
To apply Coppersmith's rnethod, we can define an equation f (x,A) - a+2tr*U and try to use
lattice basis reduction to find new polynomials Qa(x,y) with the property that if /(s,r) vanishes
modulo a large unknown divisor p of -l{ and s and r are reasonably small, then Q6(s,r) :0 over
the integers. In that case, we can attempt to find appropriate zeros of Qi. The most common
rnethod to do this is to look at multiple distinct polynomials Qa and hope that their common
solution set is not too large.
These types of bivariate Coppersmith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's attack against RSA.private key d < ro'zs [3]. Our ap-
proach is very sirnilar to that described by Herrmann and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 197

0192

10 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

bits known [9], althoug]r for [he application we describe here, we are less interested in optimal
pararneters, and more in speed: we wish üo find the keys most likely to be factored using very low
dimensional lattices.

Algebra,ic i,nd,ependence: Nearly all applications of multivariate Coppersmith methods require a


heuristic assumption that the attacker can obtain two (or several) algebraically independent poly-
nomial equations determined by the short vectors in a Lll-reduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of common solutions. Most theorem statements in
these papers include this heuristic assumption of algebraic independence as a matter of coursÖ,
and note briefly (if at all) that it appears to be backed up experimentally.
Notably, in our experiments, this assumption di,d, not hold in general. That is, most of the
time the equations we obtained after lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because all of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
vanish at the desired solution, but without further information, there are an infinite number of
additional solutions that we could not rule out. However, we were often able to find the solution
using a simple method that we describe below.
Herrrrann and May [9] describe one case where the assumption of algebraic independence did
not hold in their experiments, namely when X and Y were significantly larger than the values of
s and r. Similar to our case they observed that the polynomials of small norm shared a common
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our case does vanish over the integers at (s, r) while / vanishes only modulo p'
We experimented with running smaller dimensional lattice attacks in order to generate this
sublattice more directly. The attack worked with smaller degree equations than theoretically re-
quired to obtain a result, but when we experimented with lattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a useful linear equation
in the sublattice instead of the useless f.actor f.

6.1 Implementation details


Lattice constracti.on: Our lattice is constructed using polynomial multiples of / and .l[ up to
degree k vanishing to degree 1 modulo p. Let X and Y be bounds on the size of the roots at e
and g we wish to find. Our lattice basis consists of the coefficient vectors of the set of polynomials

{lü, rxN, f , (n X)2 N, (* X) f ,.. ., (yy)o-' (r x) f , (yY )k- L f },

using coefficients of the monomials {1,x,y,x2,.. . .,Ak-!fr,ge}. fne determinant of this lattice is

det.L : 1v't+tixr;(*ä').
and the dimension ir (*,') . Omitting the approximaüion factor of LLL, we want to ensure that

(detLl/ai^t.o
(lv,t+rxr(*t') )'/(-'') l Nr/z

So for .l{ = 21024, setting k :


3 should let us find XY < 2to2 ald,k :4 should let us find
XY < 2128. The parameter choice k : 2 results in a theoretical bound XY < 1, but we also
experimented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 198

0193

Factoring RSA keys from certified smart cards: Coppersmith in the wild 11

SoLaing for solutions: After running LLL on our lattice, we needed to solve the systern of equations
it generated over the integers to find our desired roots. The usual method ofdoing this in bivariate
Cöpersmith applications is to hope that the two shortest vpctors in the reduced basis correspond
to algebraically independent poiynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in nearly all of our experiments, this condition did not hold, and thus
there were an infinite number of possible solutions.
However, a simple method sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose because the short vectors in the reduced basis corresponded to
a sub|attice of multiples of the same degree-one equation, with seemingly random coefficients,
which vanished at the desired roots. (The coefficient vectois were linearly independent, but the
underlying polynomials were not algebraically independent.) The other polynomial factors of these
short polynomials did not vanish at these roots. This linear equation has an infinite number of
solutions, but i1 our experiments our desired roots corresponded to the smallest integer solution,
which we could obtain by rounding.
Let
ufr+aA-w:0
be an equation we want to solve for r and y.If u and u are relatively primö, then we can write
c7u + c2a: 1, and parametrize an integer family of solutions

-c|w+az
A:czu-uz
withz:cza-cty.
In experiments with the already-factored moduli, we observed that the solution was often the
rninimum integer value of r or A among the solution family. So we searched for z among the
rounded values of -c1wf u and. c2wf u.
For the handful of cases where the lattice did result in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6.2 Experimental results


We ran our experiments using Sage 5.8 paralleiized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, and Singular to factor polynomials and
.o*prt" Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear factors and looking for small solutions of the linear equations
as described above or using Gröbner bases.
We attempted to factor each of the 2,086,171 1024-bit moduli using several different parameter
settings. For k : 3, we had 10-dimensional lattices, and attempted to factor each modulus with
tlre base pattern o:0 using Y :230, X :27o, and t: 442.We then experimented with k:4
Y : 228 and X : 2100, which gave us l5-dimensional lattices, and experimented with a base
pattern a : 25t7 * 2sro and five different error offsets: t : 0 with y - 2tz8 and X : 1, and
t :128,t :228,t:328, and t : 428 with Y :228 and X - 2100. Finally, we experimented with
the choice k : 2, X : 4, Y : 4 and the choices of t and a used in the k : 4 experiments, which
used §-dimensional lattices and theoretically should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice k : 1 with
the same parameter choices äs k: 2 did not produce results.

6.3 Handling more errors


Ftom these experimental settings, it seems likely that many more keys could be factored by different
choices of parameters and initial pattern values; one is Iimited merely by time and computational
resources. We experimented with iterating over all patterns, but the computation quickly becomes
very expensive.
MAT A BSI-1-6c_3.pdf, Blatt 199

419 4

12 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

k logr(XY) #t# factored keys # alg. indep. eqns. running time


245 105 3 4.3 hours
31001 tt2 - 2 hours
41285 109 4 20 hours
Table 1. E*pe.ime pproach, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all of the other cases were solved via the heuristic
methods described above.

Patterned factors: Mysteriously, using the base patterns o : 0 and o - 251r * 2510, the algorithm
produced factorizations of keys with other patterned factorizations. This is because the product
of the bit pattern of the relevant factor rnultiplied with a small factor produced an integer of the
form we searched for, but we are as yet unable to characterize this behavior in general.

Hi,gher powers case we can construct higher-dimensional lattices in


o/p: Similar to the univariate
which each vector is divisible by higher powers of p, e.g. using multiples of -0y'2,1ü/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of XY only for
lattices of dimension at least 28.

More aariables: More isolated errors can be handled by writing p : a* Ii=t 2t'st with appropriate
bounds on the st I X.t so that the intervals do not overlap. The asymptotically optimal caSe is
described in [9] and reaches similar bounds for lli:, Xi as in the univariate and bivariate case'
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottom bits to generate a prime, the condition (det -L)di* t/r < p holds
only for lattices of dimension at least 35 at which point XTXzXB < Nt/r4 can be found. A lattice
of dimension 20 leads to the conditior. X1X2Xy < i. A sufficiently motivated attacker can run
LLL on lattices of these dirrensions but we decided that factors found thus far were sufficient to
prove our point that the smart cards are fatally flawed.

7 Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the system for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each of the affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they inforrned us that they were not issued new
cards.
Several of the more recently factored keys described in this paper afe still valid. This means
that MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart card§.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
longer responds to our queries. However, it is still possible to download Citizen Digital Certificates
from MOICA through a web-based interface upder "Query of Certifiqation" of "Certificate Ser-
vices" on http://moica.nat.gov.tw/html/en/index.htm. Interestingly, the Chinese versiön of the
web interface requires much less information to query a certificate than the English version'
We emphasize that the randorn-nurnber generators used in these cards obviously do not meet
even rrinimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problems until all of the cards are replaced.

References
1. ANSI. ANSI X9.31:1998: Digital Signatures lJsing Reuersible Publi,c Key Cryptography for the Finan-
cial Serti,ces Industry (rDSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 200

019s

Pactoring RSA keys from certified smart cards: Copper§mith in the wild 13

2. Daniel J. Bernstein. How to find the smooth pa.rts of integers, May 2004.
http: I I cr.yp.to/papers.htmlfsmoothparts.
3. Dan Boneh and Glenn Durfee. Cryptanalysis of RSA with private key d less 1'n n n0'292.In Jacques
Stern, editor, EUROCRYPT, volume 7592 of Lecture Notes in Computer Science, pages 1-11. Springer,
1999.
4. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. 'I.
Crgptology, L0(4) :233-260, 1997 .
5. Don Coppersmith. Finding a small root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, editor, EUROCRYPT, volume 1070 of Lecture Notes i,n Computer Sci,ence, pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Informationstechnik. Evaluation of random number generators, 2013.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-number-gener
and https://www.bsi.bund.de/DE/Themenf ZefüfrzierungundAnerkennungf ZertlfizierungnachCCundITSEC/Anwendungshin'
7. Andrew Granville. Harald Cram6r and the distribution of prime numbers. Scand,. Actuarial J.,
1995(1):12-28, 1995.
8. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. In Proceed,ings of the 21st USENIX Securitg
Symposium, August 2012.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYPT, volume 5350 of Lecture Notes i,n Computer Sc'ience,
pages 406-424. Springer, 2008.
10. Nick Howgrave-Graham. Approximate integer common divisors. In Joseph H. Silverman, editor,
CaLC, volume 2146 of Lecture Notes in Computer Sci,ence, pages 51-66. Springer, 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh Safavi-Naini and Ran Canetti, editbrs, CRYPTO,
volume 7417 of Lecture Notes i,n Computer Science, pages 626-642. Springer,2012.
12. Arjen K. Lenstra, Hendrik W. Lenstra jun., and L6rszl6 Lovdrsz. Factoring polynomials with rational
coefficients. Math. Ann., 261:515-534, 1982.
13. MOICA. Safety questions, 2013. http://moica.nat.gov.tw/html/en-T2/faq22-066-090.htm.
14. National Institute of Standards and Technology (NIST). Security requirements for crypto-
graphic modules. Federal Information Processing Standards Publication (FIPS PUB) 140-
2, May 2001. http://csrc.nist.gov/publications/fips/fips1 40-2lfipsl4rl2.pdf, updated 2002-72-03.
See http://csrc.nist.gov/publications/nistpubs/800-29/sp80G29.pdf for differences between this and
FIPS-r40-1.
15. National Institute of Standards and Technology (NIST). Recommendation for random number gen-
eration using deterministic random bit generators. NIST Special Publication (NIST SP) 800-904,
January 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime wa"s found.
46, OxcOOOOOOOOOOOOO0OOOoOOOOOooOOOOOOOOOOOOOOOOOoooOOOOOOOOOOOOOOOOOOOOOOOOO000o000000000000000000000000000000000000000000000000002f9
7 , Oxc924249224929249924949244s2424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424as
7 , OxcoOOoOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO00000000000O00o00000000000000O000000000000000000000000000000101ff
6 , Oxd2+949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949d7
4 , Oxf6dbdb6aldb6d6alb66db6b6atbb6dbdb6ddbOd6db66db6b6dbb6dbdbOddb6d6db66db6b6dbb6dbdb6ddbOd6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbcl
4, Oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbbOdbdb6ddb6d6db66db6bOdbb6dbdbGddb6c6e23
4, Oxedb6b6dbb6dbdb6d.db6at6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b867
3,0xd084084242102ßA0842842127081OA4a42L421O7O840842427027O808428421210810848421421010840a42427O2LO80842A42L270810848421421010840985
2 , OxeOOOOOOOOOOOOOOOOOOoOOOOOOOOOOOOOOOOOOOOOOOOOO0OOOOOOOOOOOOOoOOOOOO0O0000000000000000000000000000000000000000000000000000000000f
2 , OxfSadsad6d6b56bSaSad6ad6b6bSabSadadobd6b5b5ad5ad6d6b56b5a5ad6ad6b6bSab6adad6bd6b5bSadsadOd6b56b5a5ad6ad6b6b5ab5adad6bd6bSb5ad5d39
2, Oxc2855Oa1285OOa1485Oaa1425Oa7!4280a744285a14228501428850a428550a128500a14850aa14250a114280a744285a74228501428850a428550a128500a6f
2 , Oxtdeldet7!.TbdTbd.edetTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdobdefefTbfTbdbdefdefTfTbdTbdedEfT6fTbTbdebdefefTbfTbdbdefe0bl
2 , 0xd249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499244470t
2,oxe94a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a529294b9af5
2 , Oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6bOdbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d7015
2 , Oxca52a52g2g4a94aSa52952949 4a54a525294294a4a52a529294a94aSa529529494a54a526294294a4a52a529294a94a5a529529494a54a525294294a4a52a60L
2 , OxcOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoOOOOOOOOOOOOOOOOOOOOOOOOO00000000000000000o0000000000000000000000000000000000000002030b
2,0xd8c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c0c631631818c69107
2,oxf18c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c1907
2, OxfTbdTbdedefT6fTbTbdebdefefTbfTbdbd.efdefTfTbdTbdedefTefTbTbdebdeiefTbfTbdbd€fdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdS2S9
2 , 0xc4274270LO840842421021080842842121081084a4274270L0A4084242L02L0A0A42A42!270A70A4A42742rOIOA4O94242702108084284212108108484214369
MAT A BSI-1-6c_3.pdf, Blatt 201

019 6

14 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

2, OxefTbfTbalbclefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTblTbdbdefdefTfTbdTbdedefTeJTbTbdebdefefTbf969
1, Oxd4e682e94f1d6O18aO2O66cOdb85Oa74b3591bOf84OSr4ce4OL7b2fSd25925ba2429a66e384b5be96e6a0a03d4a11eba10416018de3b3e354477250037b6f813
1, OxcacO5be5c1eabfOc21f8e95ce5d3cO777gO4282d7tdOc7738d727eL97aOa32fda4cc59cc5Ob99d29f7faBd07c972402ab88573e255db6bab05505872c73c29L!
1 , 0xcf052499061243cd82cd1b2059446c963487834d929ac929d92b259245254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4d144e242dbd
7, Oxtag4ag72e2dctfO68ee1257e228b53egbgfcf46877t07da^a4d73c2bedf132d07730f549f4691f68553f84be8ff405f16a663d8fb8f82987bdge073a8108edc3
1 , OxefTbefbdbdefgef6fTbdTbdegefTefTbTbddgdcfefTb3Tbdgf€ddefTbTbdTbdede€6ef3bsbde3de7ed7bfa99adebdef7b7bd77d7cJf1ee7b7bdebdeeef79f8ab
1 , Oxeeb2919e1dcgce33c2aodge19O465b164a53c7cO3e9a3doO9ecfBfd6bdf743eO4444332b7ff4a0€8f53b5123a5422563a06a487cd6cbsf36cds411f0ae4dbc69
1, Oxf51576e53O188d5gbbcSf4f6ec9e824d7a9e7O142952b11c49a6f38188adgdbe3d29d1d9498b7a€ffc4d9b0420f71895f62e2a7b79d4887e45b6227e0b84tb97
1, Oxd83f22a49af67d7f196df58Od514464d6dbb88ObO3bea5Oddcc1f931ef7fO9af2f88Ode26d88cbf24567302aod6eed7c8eab859aaoc1cc18bd8efacdce194c13
1, Oxc1df3e8dbSf7b7f4E6edc1f6Od23f6O36O536565836ce37af6fO2e55de24a8dc373f3c5d49c93ba6fee0d44d08bc5fb0655781adee5c05777fdAda2bcd803dof
1 , 0xe279872638463a0a32a1412b13efccfa5ed68db44963c7f6955a3816bcaa33f94794c8b75298ddf4a8664e485ef99e6d9469J5187939e395cb1f09€666786741
1, Oxce73e73939ce9ce7e738739c9ce7ce73739c39cece73e73939ce9ce7e739739c9ce7ce73739c39cece73e73939ce9ce7e739739cgce7ce73739c39cece73ead7
1 , Oxdg2aeSc6453efec55c56142O7827de2b77bf3efO27t42g1tBaacltdgbOd69fdc61934132766f8dd1dgcb22ec38d834037effOd9dd3535bge582fbdd2327c9ce5
1 , Oxc08OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoOOOOOOOOOOOOOOOO2OOOOOOOO000000000000000O000000000000000000000000000000000000000000001003f
1, OxfffTfffffefffffffffffJffitftfffeTtfttft7f.ttff.fttfltttrtftffffdTfffffiblfffffTbfffbfcffffTfffffffffbf00000000O00000000000000000cl
1 , Oxeb6f8Off65b4a6d462cfa5961 t542t25e207667752b0482f5ac9dc091f4dc854de9c73b288aaa5das298a33929f7b2920t89b81e3635932bcgdb99a34e52b82b
1, Oxfdf7bgbffbffdebeb28592b76f6gbbffbffdafaeffd9f7bdf1ee7bfa6e2f33bb67d5a5b5676d2bf6a1d€3626f06be367ffde73db1e01f5d3855f21f0eda8b4db
L, Oxe6432O3b22b4048427210bd390d45a3a62ac132c0063990067686123d50128812e09411f27098400c841e09183400431018100a2b1ccO954c0405026420e8c7f
1, OxffefefTffde6ffffTfffffbfffffffbffeffbffdfffffffffffffffffflfffffffffffffflfcffff€f46fffdfdfffTfffffff.ffttlttttr.ttLfeef€fec€ffe8d
1, Oxf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbbOdbdb6ddb6d6db66b37b6db019a4697
1, OxcOOOb8OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO000006800000000000000000000000000000O000000000000000000000000251
1, OxcccSebfea2f4beb8b62dfef5429f97fO6afOaf8d08159d21df454OaO197ffdb8386cBebb18bd7ObOf46c9615d2fcdOea38a2cadbs22cf79f2c3ab27d9564a197
1, Oxedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6bOdbb6dadb6dgb6f6db66da6b6fbf6cb9b7ddb656d9e6d36a7dbb673ba6ddb6f6db66df6b5e5
1, Oxe7fa15abOc3d2c3d1396Of598cd2bbf74a68858O65fdc7OO64563a1O558f1dfd36dSe8aec88897c79d73ebdcbec1bSf0121175cBaae69e3a31a63f9e66e0bfcs
1 , OxfJb3O8867fee16267feb2b1af 272ttetttf.fa4g}8866rffsfJfefe13ffcf86gaff4bf907ff1f9393fff0fff3fffcfff7ff3ef703ftaaBc7ffffe491affetf3b1
1,0xc010208a48c18021210810848427423070a4OA4242006309ca468d2123081084a52043700Oc4}a425270210a084a8ce1290810cc84204a9011ac28424O1'O22el
7 , Oxa73g729cgc€7c€73539c29cec126e7383b8e89bd2207taad08428421318c1084c410631858c68c63e31035cc8c63ce31318810c64331231818c60e63623b32a3
1 , Oxfeb1b9efa29f64ed53628a1Oa924b5268163dd887f653a6b82edbO63b6874c2O39e4938O18ab949a3c28cdc785fe2be58872c0c8a9ec5171637eaOa82d5d46d7
1 , 0xc0100000000000000000000000009000004260400c00000000001800000000004020800000000020200001080000000000000000000000O000028000000002f3
1 , Oxf9d5834f918b673e1t7eaae3cc5d97dd27O6dd8de9cSb2fbef679b2c196933f€3Of62ac3f7fcc1c593fb63a0bbb8838b8486eac959cc3949ea9182c46396fbcb
1, Oxdac45d37aadacfec73b3184ef43d52d6314754abd38414dde03ade396bd8O9aa2811047f015c9c71f0cbb0a91028190adeacc36165b0e0e6fce64549f947eods
1,0xf49808713746a41a331625a7cb389611eaa3905984245f.99a828t77f867413cfae91230478715024db5ead44beb20fbc73a23t277d627a17747b5823f753eb03
1,0xd67a2b111c0401971f57806a2be12a174b8923fd3972ec64fe3de3ee96594a14207831d12f16f545851cad6356bb16221bee68eb2fee9427e0daoca5f98e5861
1,0xe83071df5288c373aSbc43fb20309e25e99fd85b61a9a4e6f3f71511b98f7ec87047fb32520d94cd7753dbe173304445ca648231f601dd19d9ca140c74790c71d
1,0xed4294bSa529529c94250ad.35394214a4a52a569a94a94a5e56b52948cd74a52529429524a5aa529294a9ca5e1295294d4a74a727394696a4a13a529236a968d
1, Oxd621eb6e5ab7992c6efba5f34a7b7b28O26tc93138998c113831dbaaaca1a15738a7b7a9d191bcd77955b92b75263ad9f6bbd4ce0b4edcalefd5f3€24b3a2889
1, Oxd9a43ffO58df6b8d55O85O28eac413a7439e1dc89eSd6e8b5deO9e7bc7483d762788ff9e36527ff67c39360cfc0d2a75986b7fb35614027cftb9326e1112ee8d
1 , Oxe4929249924949244925249224929249924949244924249224929249924949244924249224929249924949254924249224929249924949254925249224929341
1 , Oxf9cf9b29d7676db655b2f6bf964bce697f652fb669b322eb63dffb6e7a6c6gbb798396d284d85169883d42a6ec96b292761d6dcd7ab595b2adoa9aSdZe97fe41
1, dxfffefffefffffffffffefffefffefffefffffffefffffffefffefffefffffffffffefffefffefffefffefff€ffffffff000000000000000000000000000000bd
Oxf9ce9ce7e738738c9ce7ce73739cb9cece73e738398e9ce7e719739c9ce7ce7373dc39cece73e53839ce9ce7e7b9739c9ce7ce73739c39cece73e73839ce9d63
Oxd53bd2f 169ab7fb38abb7fOScb155Oe2OO914674b65ce176OO1ffeb29dbd1e9Oc2ia77e28c6dbfd6e6a782baaba532e2a98eff9€d8e924986af702c48504d0d1
Orc36e8f2addb6O2d9d18b2bO4Obc7aOObc7046b2O30c2d3e91c4c161ed562a31d2dO56afc759O42a46c28e278e25e7c7882fb1 cb2d66039ed961daceSea6gcSd7
Oxed15cbofde1567b273et2422ee}Led658173594bObcb7 1594a18df455fc75ca7cSb529bb6b9ec229be6ba977773eca917ac08a1e9f557adf079ab8bceb2bc01b
OxdOObOdd78fd35c88db31806803799deab89b8b36c39dcO321574801fb936f9Oe292Of3dd65400ddc00be90ebcefdd62d5c5c062c20obdb04aa6a5acf697€2a0d
oxdoo54c94o2o831e8oO45oeO581 1840i82088a906825002d9a0c340938dc0b20628072f800334102c08010309c020800710200c04a604083700aa44008841 1987
Oxc7592d7dc9ee1O31dcd3d3Of43O288583O5ac46ac981cafa164a8OOOa9c6eeb698181505242acgdfee9e51c92460b987dbc8161def71863d35ac18fa1235a903
Oxfffbf cfTf 7ff df3dfffef Sfff f ffbf ff ffgff ffffffdffTdffffffgf fff ffefTdffffffffbff fdff feffbfl f ftlttttfftlTTt tfdfffff ffffff 1f ffflffff3S
Oxf5ebOSd73ad4df3cdaf4fd2eaf41eBe405952b7a327479147fffa33eb829039e77ff 1 16f9e4958a3f604743ed2c55ba67b47631842905dbc2f 12c66fb6c4e40f
Oxc3ff4d3O4T4f4OdfOeTffffdfag2ffff 1 1d59d35d214ffff85c357cSc85ed72acaf.7fb7d.43f76d85ee6b4fb3ffdd60d5095ef 1f29odi4ff888e7e37efe4f9e8f
Oxcc7b18295347824ccb39sbed351993c598c7cf7f4e32dcb9ab7a5d7eObaa7626d1b8dc651b34f5€4f5d3f2530b52fbgbd10e75259b36d774f059141bf9ede911
Oxe675a7O59b1e6df2O198f8a75aOab28723iltTga67L59c7O49fd37d48128f3b3a9b69475b902f4bc854ca1deecbc€73cdab89b17a83c6401a9d43594775a926b
Oxef7b77bd3d.efdef7f7b47baledef76f7b7bdebdefef7bf7bdbdee7ef7b73d7b9edef7ef7b7b9e3deeef7bf7bgbdefd6ffffb97bdedef7ef7b7b9ebdafef3bf845
0f,fd23b110962000d598488c43407369898cd0086df780826dcfa14784f38388874362851b7711dc135644413s1335c71fbd7c564d5d5008f5de20d43f2476d715
Oxe918f 165879091 1a71a9ae1895cfe56db€d767816e3 37e2fg5}462atlb328Od8a8dcb124O62Oec8f 1d19c3750afcfe295c58cca117b36632414cd9e114fdb097
Oxffffaas5ffffffffff3cd9feAffff676fffffffffffeOOOOOOOOOOOOO0O0000000000000000000000000000000000O0000000000000000000000000000o0009d
OxcO21OOOO48O41OOOOO1OOO1OOO8O07ce2}64OO4242c81218625O154cOOOOOO88ba78O08a43a9713bc0abb849220e8362cc838b53cf88rcdbdd7fca83c8df8145
Oxe3 183 18c8c63 c63 13 1 8c 18c6c63163 18 18c68c6363 183 18c8c63c63 13 18c 18c6c63 1 631818c68c6363 183 18c8c 63c63 13 18c18c6c63163 1818c68c6363183 1d3
0xd501973162d4017f4€3b3c9d6803d4cc46a1d457c91tebSb6c2ae77423ba41c9cfbdsf4b9235667874507e9cafb4123e1992d1cSae75e629508701 1a822a6ccf
Oxe28ecce1d67aO326423O7646516Oc1bO3f8e721 181e046ef486Oae94d7BO2aO82f9f6OO7c0O11f20056de200677aa7d8a471 18e6692€e4b3f862c24e04b543bs
Oxda2f36d74bc2dc29de4de92f4b37bO3942173€15a2dfb67e8fO9e790ed1656af5aBaadef 14b696426f 1e929699da0ee3adgf21a9f66ede57d945fc765b27d2L7
Oxd2855Oa3a852Oa1c85Oaa1425Oa1 14ba0a144285a14228507428850a428550e128400a14850aa14250a11408OaL44285a1422851 1428852a4685d0a128500a2d
0xe79082499b094b2459266493608a9249b2411d9419242692a490824d934941254935265a3410861 19449d824691524922697926bb24949044027704a8c939aSd
Oxedfc3T3fTS3ffbfffTfefed3fffaJffefffd5fffffd€fffSffdffff3ffSffffefefd3fefTfbfSdfff6l3bbS9f9fbSfSbds2aefdTSebddf e6edeeffe3f3fb3dfS
OxfffTlfb6fbfffefffflffeeffffeefffefTfffebfffeffffffffefffgfffffcbfdbffOfaffffdfffTfTedffeeTadlffafffbfbTeffffdffdeTfadfdef63eS06b
Oxcaf67d473c 10f4e73d6678d4a27e 4eb}4a743g25d12c31f97efa51Oca68558b2c56d839acecbe75e935f86cec7da€7c95aa0b93065a3aa924594fdfb9f521535
OxfOb43e3bd52841756d1a27f22a859Oa8a1c43c1c36b95cc72dO1O2f26b6da1b238236856f7c6e6faa83cc70e84f2db44088487fd94a175f22a0d990cc1afea6b
Oxd2a2Od1b986de2152bgd93cf6Obf98f68e9f9eO5Ofeb982ObOO6eSdc581f 17a82f35a78d23fb34fab3962ae95bcf3a1e442ebSb1d72cd6956fa599483eee38c1
0xe52e529494a54a535294294a4a51a509294a96asa529529494a54a52529d29ea4a52a522298a94a5a522529494a44d525294294a4842a52e294at4a5a52f554b
0xc942c4644b1 169461581e0713ba400570237a55c9ae69e3fe58d189aa751d218208421934f2132a888e796bc1f0914a8c9b4f 116358cca22c69c35596bdg61e5
Oxed7f7e78afc7d3735f c1dJbOd13887cddcd7 15c9fe53O53OeOefceaa4bcaffbaebac9e601623db36fffef47fffffefffffff0000OO00O00O00000000000003ed
Ox{6db9b6dda6d.29b61dfe73dbba5bdb6ddead69beedf6a6dbf7dadb6ddfOc6cb66db6t6d3b6db9b64997c6dbe6cb4364b96dbdb6ddb6c67bs6da4b7cbaedadf35
OxcO8Oa1OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO3OO8OOO88OOOOOO26080200101200044080010042020800008000000500000O0100000000900e1
Oxe5335f76a97cSe29d.455717Ocd9ef3ed53efc819fda87a566a5efe247ef 1O2b85c7adg0c484ade030c7ebc23455e0dcbca2cec6afdf0eec978cb6fbod5733fa5
OxcOO0OOOOOOOOOOOOOOOOOoOOOOOOOOOOOOOOOOOOOOOoOOOOOOOOO00000400000000000000000000000o000000000000400000000000000000000000000O00165
0xc924249324929249b2cf4924492464926492!a4a92494936593320b93f 9292e992497dr449242492229293499249492449262493248e96fff3c9104432f4cdbb
O\c9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
0xc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000177
0xc000000410024000050800080210O004900000010O000002080000000001021005180000000000000000210080600040082000400000183001000000200020f 1

Oxcadoca7166b2aafOc82bOeadfeb134Ogda7c2679517d4fd96f89719659133e0492d2O9da600753dc5c2570ce128cf985332f944143204b706bf6e990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 202

01 97

Factoring RSA keys from certified smart cards: Coppersmith in the wild 15

1, Ox€739739c9c€7c€73739c39cece73673939ce9ce7e739739c9cE7ce73739c39cece73e73939c€9c€7s739739c9ce7ce73739c39cec€73s73939ce9ce7e73973df
!, 0xa0929249924949244924249a249292499249492449242493249292499a494924493424922492924992494924492424922492b249924949244924249224A2926,
1, OTcOOOIOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOIOOSO20OOcbo04OgOSSOgISOOOScSOOOOOOOIOcOOOI2IOIb2OOOOOOOOOiad
1,0xcec727009ef07418dc89e2c96a796d44bc22444a8a0bb8ca90Md661736b486b601d8352822a4e97cdd0702a3d8b7c4b23ada2285a24f09234a71346ba141796
1 , Oxc8dce72cOe38ecat2e3e11aefO7326e3431a92ad87ef296d3dOb5d4b3dO0646b€bd7b3af6c9e424e07461486d186d26997a4d9c1314cb62a1881aecace287c057
1, Or6EOgfObe62O14c7299e188527ab8cdOO48O9c631f1tdsoa2OO13331678ccad20631879842b8a122669eb18c4blddse4b11bc€7a14t4ae76973d€bf4ca768c4bd
1 , Oxd66cdaeef27sbfd3d1ee65df,43odd7aEO1sbdoe9a5e4389oe7835e2a2a0fb702703d6c3td50d5917f3ba77aeb851c016d26135d754c114adl303dO91500462bd
1 , Oxfa147ea58cddaaabe6dfao4ft891OOgalb3fl3?s1272d573b7a3da5334i24t9572tda7tt4f763a72482a0edffa9140001aae21l5a64tal330f93e819a968acafb7
1, Orf718cObc8c57cc318c99ra15236191a531828a95856d6ac833a7e3a211Odded2s226ea4344cabbb2fe19d€14863b8c46e31b44038c87€8c€4a€a42a10afabr91
1, Oxd86d99€183ba3cO87O238db37f1d3l673cd€c3112196acfaa1239657bcb3a3a7f6749f3229f550d5097510eSa5df0626a641E2112112f96080c6629973b1c975
1, Oxrc1tc95ee7482].42bccb71Obcscd674ad82€dca6!f.2653c78622ea673485cc11c993a4€6b15f77d9odfe1c6a945e239ab4765ca3eb2aeb702t2de36626868db
1, Oxf7c6bf218fcfadcba926ac5etaU6Ot97aeba8dsf7Oc€b27effOfSds7e763bfe86dcZa86€e76b8ba9d076bf1a8f4a7tctb0297a96sGc5a70ea7€563c38326ff83
1 , Oxc594391eBaAc24c8a7te977d78db784d43c96ba3gg4r}2ac17l.tc2606736c65f7c44ef6c3bbf7b05659b954c6b9cs96f648c900b56c5f3ca01€47384ad4lde577
1 , Oxdag7541o693d312ob32997c8c728tOgdo961of5tefO89a7cf63ft1dct673ffffb493c19c6416760467646aaba4f3409f9648ff7c390c25d4a8a3d7c9b2l16b2d
I, Oxf16fead9af03ctcb36571b8b3f,e3ct24s313a6ce858b7d4e800838329c9b729ecc6d691dl46e8547agfdb18debbca338af8214ta1e03ad53f8e3aO503blb6735
1 , Oxddfgbs6a7bb556afa1476addbs4aag56569c94ab62d5fa95cO54atO4bSa3b56adfl55e2dbb466ed1b56aad5a1629c5a93ads6bf5ad1s3ba46sabg722dat5d7bd
1 , Oxdg958fe3O334b89c8cO2ac21Oc4dc8s6€61Od1c958cb4d436el1aedeOl72e3b8a88e18b7c663533218c68ed560b031ad4ce38aa13bbc10b6c73fe3911acc8d€1
1 , OxfcbO663ef5€3c922936834039fd787aode9fdd178017021129ctb592570fd3c5€60787fc69128bceSbfcb38be0c064b08c087fd8fe6bg60207c93ca4cfgcEadd
MAT A BSI-1-6c_3.pdf, Blatt 203

0198

16 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange' N van Someren

B Appendix: FIPS-L40 certifcation


Searching for the term "FIPS" on MOICA's website (http://moica.nat.gov.tw/html/en/index.htrn)
returns the following entries in the FAQ section, all of which claim some security through FIPS
certification.

:,:ßG
g ,.' ,- Q:-\ E

--=-IEIE
il @lcM*.gd.h{

.§JrI Grtmcrtr lulhodty ot Fl

io

l.A'It is ro gakcydareton Cenilicate lC cild A Bivaae I

!e-v- pumele is oeied iD CrrlEEIaplri( ir{odrdes which ir mlires

idre RSA and rardon grnerato: A privaF ley is üsed to crede.


F{Q ;poteo. ard sroe br H§M. Betides. Th+ lC cad accordace with
IFIPS t u-t level 2 c*rifrable hl lt-. ctrd DoaBe[e[t .sIet md dre
i(&d posrßrs biEh saculry. A pril'are k(y is croated itrside ard &e
,pri1e !ie-y lig ! e.rgJT! !9m !C cad 9!et ke1 c1e13d
lrl:It e ligh risk to st6e cotificac ir ihe fl.oppy disl rhu cm nali§
:copv fl m:i titre fte Citüeir di8,itäl certificale p§t FIPS lJ&l
.adrorirv level 2 ad hn'e ligl *mity. Privets ket cil'l be rtopy i
FAQ
ifrou IC <ud afur generate kty pair qf irsids the IC cad. Ihis
icerrifirae lrvel is li 509 V.l The policy of citiror rliSjtal carificae

.n,-,rccodinf L irs or rtcitt,c. üre ii is high s(ris ild ir


''have "ad
TAQ beq acsedir«l to FIPS 140-I level 2 and tbt ra d we is u§ld I

lo s-e.ll9rpr,g!!!_(.-a1i_nol"-§.§Y, :
iA'The CA L?y paits ae Brnsated wiüir lEdrvae olpogaphic '

imodules ot pftwqerltadwae rrlqtographic Dodules rvitbin the IC


EAQ
lcad. deetürgreqrirereurs oI CPS ud FIPS 140-! level ?
icertificaim or coopa'Sle secuity strengü IC ro d.
'.L.n,. ö,c i"yr * ä e"t.a i, l. .oarie. ruingirs.r
".ijpmfi"lt
:algorithu md ra<bn utmb« generaor Creared within a lrrÄtsr
imodulc, üe private Ley is med ioside xitlrem lee*agp. Mossvtr.
rAQ
cstiöcate rübscribs's lC cüil i5 lntemally gersodui*§§ !(l-
I l{sel 2 certifi(auou ofüe Cad Csler The priv&
,ewgt after gemtatioo.
lliI*irig" r"pe-tli irydas täe cmis farir
ica be easily copied dd dE risk rs biSh
iandremicariou. the cstiEcate IC crd ll
F.{Q
§einggruuatod interaLly aic wüich
le:{rmed uor replicaed sobs(ribs'J hüai
juiagcotilirate promüor.T.509 lj hwl
-

Total6 Pagc l, l-- [ Ncr 20 I I Prw 20 I


file:lll
MAT A BSI-1-6c_3.pdf, Blatt 204 #1

Re: AW: lRenesasl unsichere RSA'Schtüssetgenerierung


Von: (BSI Bonn)
019
ili,,,r*mffi
Anhänge: r..11)

| ,:- sma rtf acts . Pdf

ursprüngliche Nachricht

Von: "Hessetmann, Thomas" <thomas.hessetman


Datum: Mittwoch . ?R 4,,^,'.+ 2013. 11 :78t)e,
An:
Kopie:
rause, Christian"
, "Kittian, Gereon"
<oe reon . ki[iantab
Betr.: Re: AW; IRenesas] unsichere RSA-Schtüssetgenerierung

Iweitere mündliche Informationen habe ich erhatten:


> - betroffene ToE: höchstwahrscheintich AE489, wobei das in der Draftversion
> des Papers (liegt mir nicht vor) nicht gesagt wird.
> - Schlüsset werden mittels der Smartcard erzeugt.
> - auf Grund Performanceprobteme hat man beim Post-Processing etwas gespart
> (was gespart wurde, habe ich nicht erfahren, meine Vermutung: den
> Ontine-Test)
> - Der betroffene Composite-Hersteller ist bereits dabei, das Probtem zu
lösen.
> - bei änderen Produkten des Smartcard-Herstetters hat man dieses Phänomen
noch
> nicht beobachtet
> Ich finde es kritisch, dass der Rauschgenerator überhaupt sotche
w.iede rhotba re
> patterns ausgibt es passiert aber woht nur recht selten, sonst wäre
das
>-Probtem öfters aufgetaucht.
Q.ou"
> Thonlas Hesselmann

> Unfortunatety I witt be out of the office in the weeks 4L-42, 52'02. During
> this time I witl be unabte to reply to your mail.

> Bundesamt für Sicherheit in der Informationstechnik


> Dr. Thomas Hessetmann
> Referat S22
> Godesberger Attee 185 -189
> 53175 Bonn
> Postfach 20 03 63
> 53133 Bonn
> Tetefon z +49 (91228 99 9582 5691
> Tetefax: +49 (0)228 99 10 9582 5691
> E-Mait: Thomas.Hessetmann@bsi.bund,de
> Internet: www.bsi.bund.de
> www. bsi-f uer-bueroer.de
tile:lll
MAT A BSI-1-6c_3.pdf, Blatt 205 #2

ursprüngliche Nachricht
0200
> Von: "Hessefmann, Thomas" < >
stao. 27 ust 2013, 16:3I-:34

"Krause, Chrlstian"
<christian.krause , "Kitlian, Gereon"
> <gereon,killianGb
> Betr.: Re: AW: IRenesas] unsichere RSA-Schtüsselgenerierung

> > Hatto


> > die Präsentationsfolien hiervon findet man unter
> > http : //c rypto . 2013 . rump .c r . yp . tol55e2988c4ed3c9f635c9a4c3f52fa0b1 . odf

> > Grüße


> > Thomas Hesselmann

-
>>

> > Unfortunately I witt be out of the office in the weeks 4L-47, 52-92.
During
> > this time I witl be unable to repty to your mai1,.

> > Bundesamt für Sicherheit in der Informationstechnik


> > Dr. Thomas Hesselmann
> > Referat S22
> > Godesberger Attee 185 -189
> > 53175 Bonn
> > Postfach 20 03 63
> > 53133 Bonn
> > Telefon: +49 (0)228 99 9582 5691
> > Tetefax: +49 (0)228 99 10 9582 5691
>:' E-Mait: Thomas.Hessetmann@bsi.bund.de
I rnternet: ffi. oti. bund.de
v ilä6ffirEi"ro"r.d"
ursprüngtiche Nachricht
> > Von: "Hessetmann, Thomas" <thomas.hessetmann6bsi.bund.de>
> > Datum Freitag, 23. August 2013, 17r18:15
> > An; ;
> > Kooie.
rause, Christian"
, "Kitlian, Gereon"
> > Betr.: Re: Al'l: IRenesas] unsichere RSA-Schtüssetgenerierung

gibt eine Vermutung,


>> dass
Nachricht für uns)
file:lll #3
MAT A BSI-1-6c_3.pdf, Blatt 206

0201
> > hrorden
> > > sein.

> During

185-18e
e : g3l;;HffirAltee

+49 (0)228 99 9582 5691


+49 (0)228 99 10 9582 5691
Thomas . Hessetmann@bsi. bund. de
www. bsi. bund, de
www. bsi- f uer-bue rger. de

ursprüngtiche Nachricht

Frei.tag, 23. August 2013, 10:53:09


>>> An:

Eetr.: AW: IRenesasl unsichere RSA-Schlüsselgenerierung


e:

> Renesas-Chips

vom

setbst

> soltten,
>>so

> integ rated


MAT A BSI-1-6c_3.pdf,
fitellll Blatt 207 #4

0202
uting Services & Sotutions (CSS)
§ecurity Consulting & Engineering

> Notice: thisFansm--Tt-t]EEä1-äHd,/or attachments may be priviteged or


-> confidential. If you are not the intended recipient, you are hereby
!,
notified
> dissemination,
> > error,
message
>>and

> > > > An:


> > > > Cc: JChristian; Kittian, Gereon
un§iche re RSA-Schlüsselgene rierung

einem

> Crypt
ent sp rechende

Chips

> > During


MAT A BSI-1-6c_3.pdf, Blatt 208 #5
flle:lll

> Hessetmann

i > > Thomas.HessetmannGbsi.bund.de<maitto:Thomas.Hesselmann@bsi.bund.de>

sma rtfacts. odf


MAT A BSI-1-6c_3.pdf, Blatt 209

ü20 4

Factoring FLSA keys from certified srnart cards:


Coppersmith in the wild

Daniel J. Bernsteinl,2, Yun-An Chang3, Chen-Mou Cheng3, Li-Ping Choua, Nadia Heningers,
Tanja Lange2, and Nicko van Someren6
I Department of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
djb@cr . yp. to
2 Department of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600M8 Eindhoven, the Netherlands
taaj a@hyperelliptic. org
3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{gm 3 ar<sr, aoug}Ocrypto . tw
a Department of Computer Science and Information Engineering
Chinese Culture University, Taipei, Taiwan
randonalg@gmail. corn
5 Microsott Research New England
One Memorial Drive, Cambridge, MA 02142, USA
uadiah@cs . princeton. edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
nicko@good, com

Abstract. This paper explains how to elficiently factor 183 distinct RSA keys out of more
than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that share primes and that are elficiently factored by a
batch-gcd computation. This is the same type of computation that was used last year by two
independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman;
Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to f'actor tens of thousands
of cryptographic keys on the Internet.
The remaining 80 keys do not share primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation fäilures: first using the shared primes as a springboard
to characterize the I'ailures, and then using Coppersmith-type partial-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys tbund in
the wild.
I{eywords: RSA, smart cards, integer l'actorization, Coppersmith' lattices
.

1 Introduction
In 2003, Taiwan introduced an e-government initiative to provide a national public-key infrastruc-
ture for all citizens. This national certificate service allows citizens to use smart-card ID cards to
digitally authenticate themselves to government services, such as fi.ling income taxes and modi-
fying car registrations online, as well as to a growing number of non-government services. RSA
keys are generated by the cards, registered with a government authority, and placed ilto an online
repository of "Citizen Digital Certifi.cates".
Unfortunately, the random-number generators used to generate many of these keys are fatally
fl.awed, and have generated real certificates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 210

0205

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange' N


van Someren

inspect repeated Primds,


batch gcd observe patterns,
generalize

Public-key 103
database secret keys
batch trial division

t2l
secret keys

725
secret keys
prlmes
primes

772
secret keys

183
secret keys

Fig. I-. Retrospective summary of the data flow lea.ding to successlui fäctorizations. After
successfully
t'acto.i.rg keys using a batch gä algorithm, we characterized the täilures, and used
trial division to check
extended the attack
lbr broader classes of specifieä prmies (input on the right) as exact divisors. We then
and applied coppersmith's method to check fbr the specified primes as approximate divisors'

This paper explains how we have computed the secret keys for 183 different certificates
in use by
real people.

1.1 Factorization techniques


bad ran-
Bad randomness is not new. Last year two independent research teams [8, 11] exploited
domness to 6nd secret keys for tens of thousands of SSL certif,cates on the Internet,
a similar
number of SSH host keys, and a few PGP keys.
poorly
Our starting point in this work is the same basic attack used in those papers against
generated RSA keys, namely scanning for pairs of distinct keys that share a common divisor (see

§ection 3). The basic gcd. ,tta"k, uppf"a to the entire database of Citizen Digital Certifi'cates,
shows that 103 keys factor into 119 different primes'
to
we go beyond this attack in several ways. First, the shared primes provide enough data
of
build a model of the prime-generation procedure. It is surprising to see ui,si,ble paLterns non-
randomness in the primes ginerated. by th""" smart card.s, much more blatant
non-randomness
than the ssIJ key-generatiÄ failures identified by [8, 11]. one normally expects smart cards to
be controlled environments with buitt-in random-number generators, typically certified to meet
to avoid such obvious patterns' For comparison' the
various stand.ards and practically guaranteed
year *u." typl"^Uy keys generated by low-power networked devices such as
SSL keys factored last
MAT A BSI-1-6c_3.pdf, Blatt 211

a2a6

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers and firewalls rünning the Limrx operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime factors: we hypothesize a particular model
of randomness-generation failures consistent with 18 of the common divisors. The same model is
actually capable of generating 164 different primes, and testing all of those primes using bdtch trial
division successfully factors further keys. One might also speculate that the cards can generate
primes fi.tting a somewhat broader model; this speculation turns out to be correct, factoring a few
ad.ditional keys and bringing the total to 125. See Section 4 for a description of the patterns in
these primes.
There are also several prime factors that are similar to the 164 patterns but that contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice.based partial-key-recovery attacks to efficiently find prime
divisors close to the patterns. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottom 40% of the bits of the prime. The bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes them particularly
susceptible to these attacks. These attacks produce dozens of additional factorizations, raising the
total to 183.
In the end nearly half of the keys that we factored dtd not share any cornmon divisors with other
keys; most of these were factored by the Coppersmith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersmith-style attack breaking keys in the wild.

1.2 Certification
The flawed keys were generated by government-issued smart cards that both the certifi.cation
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
It is clear from their externally visible behavior, as shown in this paper, that the random-
number generatois used to generate the vulnerable keys actually fall far short of these standards.
This demonstrates a failure of the underlying hardware and the card's operating system, both of
which are covered by certification. We have no explanation for the discrepancy.

L.3 Observed response and recommended response


When we reported the common-divisor vulnerabilities to government authorities, their response
was to revoke exactly the certificates sharing common factors and ask only those users to regeneräte
keys. See Section 7 for more details.
Our further factorizations demonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themselves as primes appearing twice, but sometimes
manifest themselves as primes that appear only once, .such as the primes that we found by
Coppersmith-type attacks. Both cases are vulnerable to attackers with adequate models of the
randomness-generation procass, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for common divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much more than an indication that those particular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system, replacing
it with a properly engineered system and to revoke all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the primes generated by these smart cards had been modified to inclucle a card serial number
as their top bits then the keys would have avoided colnmon divisors but the primes would still
have been reasonably preclictable to attackers. Our work illustrates severa,l methods of translating
different types of malfunctioning behavior into concrete vulnerabilities. There are many potential
MAT A BSI-1-6c_3.pdf, Blatt 212

0 207

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vulnerabilities resulting fröm bad ra,ndomness; it is important to thoroughly test every component
of a random-number generator, not merely to look for certain types of extreme failues.

2 Background
2.'L The Taiwan Citizen Digital Certificate program
Taiwan's Citizen Digital Certifi.cates (CDCs) are a standard means of authentication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certifi.cate Authority (MOICA), a level 1 subordi-
nate CA of the Taiwanese governmental PKI. Since the program's Iaunch in 2003, more than 3.5
million CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates form a basis for the Taiwanese government's plan to migrate to electronic
certificates from existing paper certificates for a range ofapplications including national and other
identifi.cation cards, driver's licenses, and various professional technician licenses.
Taiwanese citizens can already use the CDC to authenticate themselves to a number of govern-
ment agencies over the Internet, in order to file personal income taxes, update ca,r registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Certifi,cate registro,tion: In order to generate a CDC, a citizen brings their ID card to a government
registration office. A government official places the (smart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed. by MOICA. The certiflcate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Stand,arils certificati.ons; MOICA süates that these cards a^re "high security'', and'have been
accred.ited to FIPS l4}L level 2" , and also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For comparison, the SSL keys factored last year were generated
by software-hardware combinations that had never claimed to be evaluated for cryptographic
security, such as Linux running on a home router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID program. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly all, of the problems we havg identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS l4GL level 2 [14]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certificates


In March 2012, inspired. by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP d.irectory at ld,ap:/f moica.nat.gov.tw. Out of these RSA keys, 2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The i024-bit CDCs contain 2086177 distinct moduli, of which 771366 moduli appear more
than once. The repeated. moduli appear to all be due to expired certificates still contained in the
d.atabase which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 213

0208

Factoring RSA keys from certifred smart cards: Coppersmith in the wild

2.3 Random Number Generation

While generating high-quality random-numbers is critical to the security of crlptographic systems,


it is also notoriousladifficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial component of generating random numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, i, 6] .p""ify correct behavior for these types ofsystems. In general, software pseudo-
random number gänerators require a signiflcant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
,pp"u. to utilize a source of randomness that is prone to failing, they fail to perform any run-time
t""1ing before generating keys, and they clearly do not apply any post-processing to the randomness
stream. The lack of testlng or post-processing causes the initial ra.ndomness-generation failure to
be much more damaging than it would have been otherwise.

Analog RNG circuits.. An analog circuit is the standard choice when hardware designers have the
l,oury of desigrring dedicated ciicuits for random-number generation. An analog circuit allows the
designer to obtain randomness from simple quantum effects. While the use of radioactive decay is
.u."1, commercial products, the quantum noise exhibited by a current through a suitably biased
diode can be amplified and sa"rnpled to deliver an entropy source of very high quality'

On-chip RNG circu,its.. Mifng analog and digital circuits on the same die is costl$ so chip designers
often seek other sources of unpredictability. These sources can include väriation in gate propagation
d.elays or gate metastability, which exhibit inherent randomness. Designers can e.xplicitly harness
gate-delay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take ad.vantage of randomness in gate metastability, designers
build circuits that output bits based on the time it takes for the circuit to settle to a steady state,
a variable which should be hard to pred.ict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variatious, and subtle on-chip effects such
as inductive coupling or charge coupling between components can cause free-running oscillators
to
settle into synchronised patterns ,rrd *"t*trble eircuits to predictably land one way or the other
depending on other components nearby on the chip.

Hand,l,ing Entropy Sources: Even with perfectly unpredictable source of randomness' care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density, test the signal from the entropy source at run
time, and run the output through a compression function such as a cryptographically secure.hash
function. These practices a,re required by a number of security standards such as FIPS 140 [14]'

Batch gcd

This section reviews of [8, 11] for detecting common factors in a collection of RSA
the. approach
keys, and reports the resuG of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA mod.uli Nt : PQt and lüz : pq2 sharing exactly one prime factor
p, then the greatest common divisor of l( and I{z will be p. computing this gcd is fast, and
dividing it out of ly'r and lfz produces the other factors qL and q2.
Of course, this type of vulnerability should never arise for properly generated RSA keys. How-
ever, since [8, 11] h;ä observed weak random-number generators producing keys with repeated
factors in the wilcl, we began by checking whether there were repeated factors among the Citizen
Digital Certificates.
MAT A BSI-1-6c_3.pdf, Blatt 214

a2ae

D J Bernstein, Y-A Chang, GM Cheng, L-P Chou, N Heninger, T Lange, N van Someren

Instead of the naive quadratic-time method of doing this computation (checking each l[
against each .1y'2), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementation available aLhttps:f ffactorable.net/resources.html.
We ran this implementation on the 3192962 distinct RSA moduli and found that 103 moduli
were factored due to nontrivial common factors. This computation, parallelized across four cores
of a 3.1GHz AMD FX-8120, flnished in just 45 minutes.

4 Attacking patterned factors


A properly functioning random number generator would never generate identical 512-bit primes,
so the discovery of repeated prime factors described in the previous section immediately indicates
that the random-number-generation process producing these keys is broken. This section analyzes
the structure of the repeated factors generated by the flawed random-number generator and designs
a targeted attack against this structure.
The 103 moduli with repeated factors show a remarkable distribution of the shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appenclix A.
One prime factor, p110, appears a total of 46 times with different second primes. The hexadec-
imal representation of this factor is

c0000000000000000000000000000000000000000000000000000000000000o0
00000000000000000000000000000000000000000000000000000000000002f I
which is the next prime after 25Lr 4 2510.
The next most common factor, repeated 7 times, is
c9 24249 2249 29249 I 2 49 49 2 4492 424922 49 29249 I 2 49 492 449 24249 22 49 29 249
92 49 49 2449 24249 2249 29 249 9 249 49 2449 24249 22 4929249 I 249 49 2449 2 42 4 eS

which displays a remarkable periodic structure. The binary representation of this integer, excluding
a few most and least significant bits, is a repeated sequence of the string 001 with a "hiccup" every
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. We hypothesized that nearly every repeated prime factor had been generated using the
following process:

1.. Choose a bit pattern of length 1, 3, 5, or 7 bits, repeat it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the most significant two bits to 11.
4. Find the next prime greater than or equal to this number.
We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and tested divisibility with each modulus. This factored a total of 105 moduli, including
18 previously nnfactorecl moduli, for a total of 121.
None of the repeated primes exhibit a (minimal) period of length 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods typically appear
in fewer keys than patterns with shorter periods, and are thus less likely to appeax as divisors of
two or more keys, raising the question of whether there are primes with larger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extendecl
this test to include length-9 periods and length-11 periods. The length-9 periods factored 4 more
keys but the length-11 periods did not factor any new keys, leading us to speculate that 3, 5, and
7 are the only factors of the period length. We then ran a complete test on all length-15 patterns
but did not find any further factors. The total number of certificates broken by these divisibility
tests, together with the initial batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 215

421 0

Factoring RSA keys from certified sm §s: Coppersmith in the wild

P32
P42

*e
p7o

PR

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime läctors dividing the same modulus.

Sporad,ic eryors: The handful of shared prime factors in our sample of gcd-factored keys that did
not mätch the above form were differing from patterns in very few positions. We experimented with
flnding more factors using brute-force search starting from 0xc0. . ,0 and found a new factors, but
these factors are more systematically and efficiently found using LLL in Coppersmith's method,
as described in the next section.

5 UnivariateCoppersmith
Several of the factors computecl via the GCD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic errors. Coppersmith's
method [5,4] factors RSA moduli if the top bits of the primes are known, which matches our
situation if tüe errors appear in the bottom few bits of a factor. This section presents this method
following the variant by Ho*gru,roGraham [lO] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factorecl.
The idea is as follows: we assume that some prime factor p of lü is of the form

P: a+r
MAT A BSI-1-6c_3.pdf, Blatt 216

021 1

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

where a is a 512-bit integer known to us (one of the bit patüerns described in the previous section)
and r is a small integer error to account for a sequence of bit errors (and incrementing to next
prime) arnong the least significant bits of p.
In the Coppersmith/Howgrave-Graham method, we can write a polynomial

I(*):o+'
and we would like to fi.nd a root r of / modulo a large divisor of N (of size approximately NL /2 x 7) .
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new polynomial g(o) where g(r) :0 over the integers, and thus we can factor g to
discover it.
We construct the lattice .L as
lx2 xa ol
lo *"1
Lo o Nl
corresponding to the coefficients of the polynomials N, f (Xx),Xrf(Xc), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of a polynomial g(Xt). Then we compute the roots 16 of g@) and check if a + r, divides .l[. If so,
we have factored N.
Any lattice vector is a linear combination of / and l{ and is thus divisible by p. A prime p is
found by this method if g(ri) : 0 mod p holds not only modulo p but over the integers. The Iatter
is ensured if the coefficients of g are sufficiently small. The shortest vector u1 found by LLL is of
Iength
!u1 |< 2(ai*r-t)/a(det L)t/dimt ,
which must be smaller than p for the attack to succeed.
In our situation this translates to
,rtz 1yt N)l/t . yt/z <+ X < 2-1/21J7/6 ,
so for ltr - 2Lo24 we can choose X as large ß 2170, meaning that for a fast attack using dimension-
3 lattices up to the bottom third of a prime can deviate from the pattern a. In the following
we ignore the factor 2@\ml-t)/a since all lattices we deal with are of small dimension and the
contribution compared to l/ is negligible.

5.1 Experirnental Results


A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this method for one of the 164 patterns identified in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including all 105 keys derived from the patterns without error, and
found 39 previously unfactored keys.
It is worth noting that the 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000. ..0f . Including 0xd0000. . .0, 0xe0000...0, 0xf0000. . .0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation might set the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's method can find primes with errors in up to ll2 of their bits using lattices of
higher dimension. Getting close to this bound is prohibitively expensive, but trying somewhat
larger dimensions than 3 is possible. For dimension 5 we used basis

{N2, N y@x),1'@x),cx y2(rx),(rx)z y2@x)}


MAT A BSI-1-6c_3.pdf, Blatt 217

021 2

Factoring RSA keys tlom certified smart cards: Coppersmith in the wild

which up to LLL constants handles X < N1/5, i.e. up to 204 erroneous bottom bits in p for N of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
making it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe000. . . f (2ttt +2sto12sos1151 appeared as a common factor a,fter taking GCDs but
was not be found by the lattice attacks deseribed in this section starting from the basic patterns
described in Section 4. Coppersmith's attack also works to search for errors in higher bits ofp by
defining the polynomial / as l@) : a l2ta. Here t is the offset location of the errors we hope to
learn and the same method will find errors of the form 2tr with r I X.
However, since we hypothesize that the prime factors are generated by incrementing to the next
prime a.fter a sequence of bits output by the flawed RNG, we do not know the least significant bits
of o because they are modified in the prime generation process. This problem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for more strings o: For each of the 164 basic patterns include a7l 2 -t
variations of the bottom rn bits with the LSB fixed to 1. This will find factors if finding the next
prime from the base string did not require more than those bottom nz bits to change.
A brief analysis suggests that for this attack to have a 50% chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prime is approximately \f lnz. Spe [7] for an overview and more precise statements.
In our case of primes around 2512, each number has about all355 chance of beingprime. Since
1 - (1 - 1/355)256:0.514290, trying 128 patterns for the bottom eight bits for odd patterns has
a 50% chance of covering a sufficiently large interval to find a prime. For our implementation this
computation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be found with this search but the method presented in the following section is more
efficient at handling errors in top and bottom positions unless a very large portion of the top bits
a,re erroneous.

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring in the least signifi.cant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most signifi.cant bits of one of the factors,
without resorting to brute.forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of l/ has the form

P: a+2ts+r
where a is a 512-bit integer with a predictable bit pattern (as described in Section 4), t is a bit
offset where a sequence of bit errors s deviating from the predictable pattern in a occurred during
key generation, and r is an error at the least significant bits to account for the implementation
incrementing to the next prime.
To apply Coppersmith's method, we can define an equation f (r,y) : a*2tr*A and try to use
lattice basis reduction to find new polynomials Qi(c, y) with the property that if /(s, r) vanishes
modulo a large unknown divisor p of I[ and s and r are reasonably small, then Q;(s,r) :0 over
the integers. In that case, we can attempt to fi.nd appropriate zeros of Qa. The most common
method to do this is to look at multiple distinct polynomials Qi and, hope that their common
solution set is not too large.
These types of bivariate Coppersmith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's attack against RSA private key d < ,o'zs [3]. Our ap-
proach is very similar to that described by Herrmann and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 218

021 3

10 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

bits known [9], although for the application we describe here, we are less interested in optimal
parameters, and more in speed: we wish to find the keys most likely to be factored using very low
dimensional lattices.

Algebrai,c ,independence: Nearly all applications of multivariate Coppersmith methods require a


heuristic assumption that the attacker ca,n obtain two (or several) algebraically independent poly-
nomial ecluations determined by the short vectors in a LlLreduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of common solutions. Most theorem statements in
these papers include this heuristic assumption of algebraic independence as a matter of course,
and note briefly (if at all) that it appears to be backed up experimentally.
Notably, in our experiments, this assumption did not hold in general. That is, most of the
time the equations we obtained after lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because a,ll of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
v-anish at the d.esired solution, but without further information, there are an infinite number of
additional solutions that we could not rule out. However, we were often able to find the solution
using a simple method that we describe below.
Iferrmann ancl May [9] describe one case where the assumption of algebraic independence did
not hold in their experiments, namely when X and Y were signifi.cantly larger than the values of
s and r. Similar to our case they observed that the polynomials of small norm shared a co[rmon
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our case does vanish over the inüegers at (s, r) while / vanishes only modulo p.
We experimented with running smaller dimensional lattice attacks in order to generate this
sublattice more directly. The attack worked with smaller degree equations than theoreticaily re-
quired to obtain a iesult, but when we experimented with iattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a useful linear equation
in the sublattice instead of the useless factor /.

6.L Implementation details


Lattice corutr"uction: Our lattice is constructed using polynomial multiples of / and .f{ up to
degree A vanishing to degree 1 modulo p. Let X and Y be bouads on the size of the roots at r
and. gr we wish to find. Our lattice basis consists of the coefficient vectors of the set of polynomials

{ r{, rXN, f , (t x)2 N, (" X) f , . . ., @Y)* -' (r X) f , (sY)k - 1 f },

using coefficients of the monomials {1, r, A, t2 ,... ,gk-t x,Ak}.The determinant of this lattice is

det L : ryt+,1;r;('i').
and the dimension ir (*l') . Omitting the approximation factor of LLL, we want to ensure that

(det L)1/ai*r o
'
(lv'r+rxr(**')) "(';') < N,/2.

for,l{ = 27024, setting,t :3 should let us find XY < 2102 and k : 4 should let us flnd
So
XY 2128. The parameter choice k: 2 results in a theoretical bound XY < 1, but we also
<
experimented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 219

021 4

Factoring RSA keys i'rom certified sma.rt cards: Coppersmith in the wild 11

Soluing for solutions: After running LLL on our lattice, we needed to solve the system of equations
itgenerated over the integers to fi.nd our desired roots. The usual method of doing this in bivariate
Coppersmith applications is to hope that the two shortest vectors in the reduced basis correspond
to algebraically independent polynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in nearly all of our experiments, this condition did not hold, and thus
there were an infinite number of possible solutions.
However, a simple method sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose beeause the short vectors in the reduced basis corresponded to
a sublattice of multiples of the same degree-one equation, with seemingly random coefficients,
which vanished at the d.esired roots. (The coefficient vectors were linearly independent, but the
underlying polynomials were not algebraically independent.) The other polynomial factors of these
short polynomials did not vanish at these roots. This linear equation has an infinite number of
solutions, but in our experiments our desired roots corresponded to the smallest integer solution,
which we could obtain by rounding.
Let
ut*ua-tu:0
be an equation we want to solve for n and y. lf. u and u are relatively prime, then we can write
ctu + czu: 1, and parametrize an integer family of solutions

;:Z::';
withz: c2r-c1!.
In experiments with the already-factored moduli, we observed that the solution was often the
minimum integer value of r ot y among the solution family. So we searched for z among the
ronnded values of -c1wf o and c2wf u.
For the handful of cases where the lattice did result in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6.2 Experimentalresults
We ran our experiments using Sage 5.8 parallelized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, and Singular to factor polynomials and
compute Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear factors and looking for small solutions of the linear equations
as described abovä or using Gröbner bases.
We attempted to factor each of the 2,086,171 1024-bit moduli using several different parameter
settings. For ,k : 3, we had l}dimensional lattices, ancl attempted to factor each modulus with
the base pattern o:0 using Y --230, X:27o, and t: 442.We then experimented with,k:4
Y : 228 and X, - 210o, which gave us 15-dimensional lattices, and experimented with a base
pattern a : 2sLl t 2sro and five different error offsets: ü : 0 with Y - 2128 and X : 1, and
t :128,t :228,t: 328, and t : 428 with Y :2za and X : 2100. Finally, we experimented with
the choice k:2, X:4,Y :4 a.ndthe choices of t and o used inthe,t:4 experiments, which
used Gdimensional lattices and theoretically should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice k : 1 with
the same parameter choices as k:2 did not produce results.

6.3 Handling more errors


From these experimental settings, it seems likely that many more keys could be factored by different
choices of parameters and initial pattern valuesl one is limited merely by time and computational
resoürces. We experimented with iterating over all patterns, but the computation quickly becomes
very expensive.
MAT A BSI-1-6c_3.pdf, Blatt 220

0215

12 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T La.nge, N van Someren

k logr(XY) ff t $ tartored keys ff alg. indep. eqns. running time


245105 3 4.3 hours
31001 172 2 hours
41285 r09 4 20 hours
Table 1. Experime proarh, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all ofthe other cases were solved via the heuristic
methods described above.

Patterned factors.' MysteriouslS using the base patterns a: 0 and a:25t1 *25'0, the algorithm
produced factorizations of keys with other patterned factorizations. This is because the product
of the bit pattern of the relevant factor multiplied with a small factor produced an integer of the
form we searched for, but we are as yet unable to characterize this behavior in general.

Higher powers o/p; Similar to the univariate case rre can construct higher:dimensional lattices in
which each vector is divisible by higher powers of p, e.g. using multiples of N2, N/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of XY only for
lattices of dimension at least 28.

More uariables.' More isolated errors can be handled by writingp : a+»;:l2tts; with appropriate
bounds on the s; I Xa so that the intervals do not overlap. The asymptotically optirnal case is
described in [9] and reaches similar bounds for fli=, X, as in the univariate and bivariate ease.
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottom bits to generate a prime, the condition (dettr)dht/r < p holds
only for Iattices of dimension at least 35 at which point X1X2Xy < Ivrl/l4 can be found. A lattice
of dimension 20 leads to the condition X1X2X3 < 1. A sufficiently motivated attacker can n-n
LLL on lattices of these dimensions but we decided that factors found thus far were sufficient to
prove our point that the smart cards are fatally flawed.

7 Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the system for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each ofthe affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they informed us that they were not issued new
cards.
Severa,l of the more recently factored keys described in this paper are still valid. This means
that MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart cards.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
longer responds to our queries. However, it is still possible to download Citizen Digital Certifi.cates
from MOICA through a web-based interface under "Query of Certification" of "Certificate Ser-
viöes" on http://moica.nat.gov.tw/html/en/index.htm. InterestinglS the Chinese version of the
web interface requires much less information to query a certificate than the English version.
We emphasize that the random-number generators used in these cards obviously do not meet
even minimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problems until all of the cards a.re replaced.

References
1. ANSI. ANSI X9.31:1998: Digital Signatures Using Reaersible Public Keg CryptographgfortheFinan-
cial Seruices Industry ODSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 221

0216

Factoring RSA keys liom certified smart cards: Coppersmith in the wild 13

2. Daniel J. Bernstein. How to find the smooth parts of integers, May 2004.
http: / / cr.yp.to/papers.htmlf smoothparts.
3. Dan Boneh and Glenn Durf'ee. Cryptanalysis of RSA with private key d less thu, n0'292.In Jacques
Stern, editor, EUROCRYPT, volume 1592 of Lecture Notes in Computer Sciencel pages 1-11. Springer,
1999.
4. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. "L
Cryptologg, 10(4) :233-260, 1997.
5. Don Coppersmith. Finding a smali root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, edilor, ETJROCRYPT, volume 1070 of Lecture Notes in Computer Sci.ence, pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Infbrmationstechnik. Evaluation of random number generators, 2013.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-aumbergent
and https://www.bsi.bund.de/DE/Themen f ZertlfizierwrgundAnerkenn\rn1f ZertifrzierungnachCcundlTSEC/Anwendungshi
7. Andrew Granville. Harald Cram6r and the distribution of prime numbers. Scand. Actuarial J.'
1995(1):12-28, i995.
8. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex l{alderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. ln Proeedings of the 21st USENIX Securitg
Symposium, August 2012.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYP?, volume 5350 of Luture Notes in Computer Sc'ience,
pages 406-424. Springer, 2008.
10. Nick Howgrave.Graham. Approfmate integer common divisors. In Joseph H. Silverman, editor,
CaLC, volume 2146 of Lechrre Notes in Computer Science, pages 51-66. Springer' 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh SafaviNaini and Ran Canetti, editors, CRYPTO,
volume 7417 of Lecture Notes in Computer Scien&, pages 626-642. Springer, 2012.
12. Arjen K. Lenstra, Hendrik W. Lenstra jun., and Läszl6 Loväsz. Factoring polynomials with rational
coefficients. Math. Ann., 261:515-534, 1982.
13. MOICA. Saf'ety questions, 2013. http://moica.nat.gov.tw/htrri/en!12/f.acl22-066-090.htm.
14. National Institute of Standards and Technology (NIST). Security requirements tbr crypto-
graphic modriles. Federal Intbrmation Processing Standards Publication (FIPS PUB) 140-
2, tr4ay 2OOl. http://csrc.nist.gov/publications/fips/fips14}-2/fips7402.pdf, updated 2002'12-03.
See http://csrc.nist.gov/publications/nistpubs/80G29/sp80G29.pdf lbr differences between this and
FIPS-14G.1,
15. National Institute of Standards and Technology (NIST). Recommendation fbr random number gen-
eration using deterministic random bit generators. NIST Special Pubiication (NIST SP) 80G'90A'
January 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime was found.
46, OxcOOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOOOOO2fg
7, Oxc924249224929249924949244924249224929249924s4s244s24249224929249924s4924492424922492924992494924492424922492924992494924492424e5
7, 0xc0o00oooo0oooooooooooooooooooo0oooooooooooooooooooooooooooooooooooooooo0oooooooo000o000oo0o0o000oo00000ooo0ooo0ooooo0oo0ooololff
6, oxd24s4si44s2424s224s29249924949244s2424s224929249924949244924249224929249924949244924249224929249924949244924249224929249924949d7
4, oxf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbab6ddb6d6db66db6b6dbb6dbdbBddb6d6dM6db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbc1
4, Oxdb6d6db66db6b6dbb6dbdb6ddb6id6db66db6b6dbb6dbdb6ddb6d6db6&b6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbGddb6c6e23
4, 0xedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6dtrb66db6b867
3,0xd0840842421O21080842842121081084842142107OA4OA42427021O8084284212108108484214210108408424210210808428421210810848421421010840985
2, OxeoOOOOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOO000000000000000000000000000000000000000000000000f
2, OxfSad5ad6d6b56b5a5ad6ad6b6bSabsadad6bd6b5b5adSad6d6b56b5aSad6ad6b6bsabsadad6bd6b5bSadSad6d6b56b5a5ad6ad6b6b5absadad6bd6b5bSadSdl}9
2,0xc28550a128500a14850aa14250a11428Oa144285a142285O1428850a424550a128500a14850aa14250a114280a744285a74228501428850a428550a128500a6f
2, OxfdEfdefTfTbdTbdedefTefTbTbdehdefefTbfTbdbdefdefTfTbd7bdedefTefTbTbdebdefefTbfTbdHefdefTfTbdTbdedefTefTb7bdebdefefTbfTbdbdaf60bl
2, Oxd24s4s244s24249224s2s24992494924492424s224929249924s4924492424922492s24992494924492424922492924992494924492424922492924992484aot
2, oxe94a94aSa529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a32a529294a94aSa529529494a54a525294294a4a52a529294b9afs
2, 0xdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbbGdbdb6ddb6d701s
2, Oxca52a529294a94a5a529529494a54a525294294d4a52a529294a94aSa529529494a54a525294294a4a52a529294a94aSa529529494a54a525294294a4a52a601
2, 0xcooooo0000ooooooooooooooooooooooooooooooooooooooooooo0oooooooooooooooooooooooooooooooo00000000000000000000000000000000000002030b
2,0xd8c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c69107
2,oxf18c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c536318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c1907
2 , OxfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbd7bdedefTelTbTbdebdefefTbfTMbdefdEfTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefd€f7f7bd8289
2, Oxc42742107084084242102108084234212108108484214210108408424270270A0A428421210810848421421010840842421021080842842121081084a4214369
MAT A BSI-1-6c_3.pdf, Blatt 222

021 7

14 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

2, Ox€fTbfTbdbdefdefTfTbdTbdedefTefTbTbd€bdefEfTbfTbdbdefdefTfTMTbdedefTefTbTbdebd€fefTbJTbdbd6fdefTfTbd7bdedefTefTbTbdeMefefTbf969
1,0xd4e682e94f1d6018a02056c0db850a74b3591bOf840514c641017b2fSd25925ba2429a66e384b5be96e6a0ao3d4a11eba10416018de3b3e354477250037bGf813
1, OxcacO5be5c1eabfOc21f8e95ceSd3cO777904282d1ldOc1738d727e197aOa32fda4cc59cc50b99d29f7fa8dO7c972402ab88573e255db6bab05505812c73c2911
1 , 0xcf052499061243cd82cd1b2059446c963487834d929ac929d92b259245254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4d144e242dbd
7, Oxla94a972a2dcffO68e_e1257E228b53e9b9fcf46a77fO7daaa4d13c2b€df132dO7730f549f4691f68553f84be8ff4O5f16a663d8fb8f82987bd9e073a81OBedc3
1, OxefTbefbdbdefgef6fTbdTbdegefTefZb7bddgdcfefTb3Tbdgfeddef?bTM7bdedee6ef3bsbde3deTed7bfa99adebdEfTbTbdTTdTcfflee7bTbdeMeeefTgfBab
1, Oxeeb2919e1dc9ca33c2aOdge1901165b164a53c7cO3ega3dOO96cf8fd6bdJ74:|eO4444332bruf4aOe8f53b5123a5422563a06aal87cd6cbSf36cd5411f0ae4dbc69
1,0xf51576e530188d59bbcSf4f6ec9e824d7a9E?0142952b11c49aGf38188adgdb€3d29d1d9498b7aeffc4d9bO42Of77895L62e2a7b79d4887e45b6227eOb84fb97
1, Oxd83f22a49af67d7f196df58Od514464d6dbb880bO3bea6Oddcc1f931ef7f09af2f88ode2&88cbf24567302a0d6eed7cBeab859aa0c1cc18bd8eiacdce194c13
1 , Oxc1df3e8db5J7b7f456edc1f6Od23f60360536565836ce37af6fO2e55de24a8dc373f3cSd49c93ba6fee0d44d08bcSfbO655781adoESc05777fd4da2bcd803dof
1 , 0xe279872638463a0a32a1412b13efccfased68dM4963c7f6955a3816bcaa33f94?94c8b75296ddf4a8664e485ef99e6a9469f5187939e395cb1109e666786741
1 , oxce73e73939ce9ce7e738739c9ce7ce73739c39cece73E73939ce9ce76739739c9ce7ce73739c39c€c€73e73939ca9c€7e739739c9ce7ce73739c39cEcE73eadz
Oxdg2aeSc6453ef ec55c567420?827ds2b77bf3EfO27f423OfBaac1fd9b0d69fdc61934132766f8dd1d8cb226c38d834037eff6d9dd353sbgg582fbdd2327 c9ces
OxcO80OOOOOOOOOOOOOO00O0O0oO00O000ooOOO0OO000000OOOO00O02O0O00O00000OO0000000O000O00O000000000000O00000000000000Oo0000O00000O1OO3f
oxfffTfffff€fffffffffffffffffffffeTffffffTffff.ftf,f.f,fftfffttfJffdTffffffbffftffTbfffbfcffffTffftfffffbfo00O00000000000O0000OO0OO0cl
.Oxeb6f80ff65b4a6d462cta5961f542f25e20766775l2bo482f5ac9dcog1f4dc8Sds9c73b288aaasda5298a33928f7b2920f89b81e3635932bc9db99a34e52b82b
OxfdfTbgbffbffdeb€b28592b76f69bbffbffdafaeffd9f7bdf1ee7bfa6E2f33bb67d5asbs676d2bf6a1de3626fO6be367ffda73db1e0lfSd3855f21f0€daSbaldb
0xe6432O3b22b4048427210bd390d45a3a62ac 132c0063990067686123d5O72AA72aO947!f2709840Oc841e09183400431018100a2b1cc0954c040502il20e8c7f
oxffeiefTffde6fff.fTf.ffffbfl.fff ffbffeffbffdfffffffffffffffffffftfffffffffJfflfcffffeJ46fffdfdfffTfffffffffffffffffffffeefefeceffeSd
Oxf6dbdb6ddb6dOdb66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb&ldb6ddb66db6Mdbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66b37b6dbo19a4697
0xc000b€l0ooOOOoO000000000000O0000OO0OOOO0O00OO00000OOo0O0o0oo0O00000000680o00oOO0OoO00O00O00O0oo0O000000ooo00000O00000000oo00«)251
0xccc56bfea2f4b€b8b62dfef5429f97fO6aJ0af8d08159d21dJ4540a0197ffdb8386c8ebb18bd7ohof46c9615d2fcdooa38a2cadb522cf.79f2cgab27d9564a197
0xedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb5dadb6d9b6f6db66da6b6fbf6cb9b7ddb656d9e6d36a7dbb673ba6ddb6f6db66df6b5e5
0xe7fa15ab6c3d2c3d1396Of598cd2bbf74a688580e5fdc7OO64563a1O558f 1dfd36d5e8aec88897c79d73abdcb€c1b5f0121175cBaaE69e3a31a63f9e66eobfc5
Oxffb308867fee 16267feb2b7af272ffafffffa4308866fffSfffefe13ffcf86gaff4bf907ff 1f9393fff0tff3l.l.rcff.f7tf.3ef7O3ffaa8c7ffffo491aJfeff3b1
OxcO 10208ar18c1802727087Oa48427423O1Oa4o84242006309ca468d2123081o84a520431000c40a425210210a084a8ce1290810cc84204a9o!7ac28424o1022e1
0xe739729c9ce7ce73539c29c€c126e7383b8e89U2207ra€dO8428421318c1O84c41063 1858c68c63e31035cc8c63ce31318810c64331231818c60e63623b32a3
oxfeb1b9€fa29f64ed53628a10a924b5268163dd887f653a6b82edto63b6874c2039E4938018ab949a3c28cdc785fe2be58872c0c8agec5171e37ea6a82d5d46d7
0xco1OOOOOOOOOO0O0O00000ooo0o090O000426040Oc0000000000 1800000000004020800O0000OO20200O01080O00000O0000000000000000000280000O0002f3
Oxf9d5834f918b673e1f7oaae3ccSd97dd2706dd8de9cSb2rb€f679b2c 19693ilfe3oI62ac3f7fcc1c593fb63aObbb8838b8486eac959cc3949ea9182cat6396fbcb
0xdac45d37aadacfec73b3184ef43d52d6314754abd:l8414dde03ade396bd809aa2811047f015c9c71focbboa9102819Oadeacc36165b0e0e6fcE64549f947eOds
oxf498O8713746a41a331625a7cb389611eaa3905984245f99s828f17f867413cfae91230478715024db5ead44b€b20fbc73a23a271 d627tl7747b5423f753Eb03
Oxd67a7b11 1c040197 1f57806a2be12a174b8923fd3972ec64fe3de3ee96594a14207831d12f 16f54l5851cad6356bb1622l.bEe68Eb2fee9427e0da0caEf98e5861
oxe83071dJ5288c373a5bc43fb20309e25€99fd85b61a9a4e6f3f71511b98f7ec87047fb32520d94cd7753dbe1733011445ca6r18231f601dd19d3cd40c74190c71d
0xed4294b5a529529c9425Oadi}5394214a4a52a559a94a94a8e56b52948c a7 4a62529429524aSaas29294a9ca5e7295294d4a74a7 27394696a4a13a529236a968d
0xd621eb6ESab7992c6efbasf,34a7b7b28026fc93138998c113831dbaaaca1a15738a7b7agd191bcd77955b92b75263adgf6bbd4ce0b46dca1efd5f3€24b3a2889
0xd9a43ff058dJ6b8d55085028eac413a7439eldc89eSd6e8b5d609e7bc7483d762788ffgs36527ff67c3936OcfcOd2a75986b7rb35614027cffb932eE1 112ee8d
0xe492924992494924492524922492924992494924492424922492924992494924492124922492924992494925492424922492924992494925492524922492934f
oxf9cf9b29d767edb655b2f6bf964bce697f652fb669b322eb63dffb6e7a6c69bb798396d284d851698a3d42a6Ec96b292761d6dcd7ab595b2adoa9a5d7e97fe41
0xfffefffefffffffffffaftrefffefffefffffffefffffffefffafffefffffffffffefJfefffefffefffefffeffffffff00000O0OO00000000000000OOOOOOObd
0xf9ce9c€7e738738c9ce7ce73739cb9cece73e738398e9ce7a7 19739c9c€7ce7373dc39c€ce73853839ce9c€7e7b9739c9cE7ce73739c39cece73e73839cegd63
0xd53bd2f169ab7fb38abb7fO5cb1550e2O0914674b65ce176o01ffeb2gdbd1e90c21a77e28c6dbfd6e6a782baaba532e2a98eff9ed8e924986af702c48504ld0d1
0xc36eBf2addb6O2d9d18b2b040bc7aOObc7O46b2030c2d3e91c4c161ed562a31C2d056afc759O42a46c28e218e25e7 c78B2Lb7cb2d66039ed961daie56a69cSd7
oxed15cb0fdE1567b278e12422eeolsd658173594bobcb71594a18di455fc75ca7c5b529bb6b9ec229be6ba977773ecag 17ac08a1egf557adfO79abgbc6b2bcO1b
0xd0obodd78fd35c88db31806803799deab89b8b36c39dc0321574801fb936f90€2920f3dd654ooddcO0be9Oebcefdd62d5c5c062c200MbO4aa6a5acf697e2a0d
OxdOO54c94O2O831e8O045OE0581 1840242088a906825OO2d9a0c340938dc0b20628072f8003341O2c0801O309c02080071O200c04a60«)83700aa4aIO088411987
0xc7592d7dcge€ 1031dcd3di}0f43O28858305ac46aq981cafa164a8000a9c6eeb698181505242ac9df6€9e51c92460b987dbc8161def71863d:15ac18fa1235a903
oxfffbfcfTf?ffdr3dfffefSfiffffbfffffgffffffffdffTdffffffgffffffefTdJfffffffbfffdfff€ffbfffff f.ffttfftl.TTtffdffffffffffflffffJffff3S
oxf5Eb05d73ad4dJ3cdaf4fd2Eaf41eBe405952b7a327479147fffa33eb829O39e7Iff 116f9e4958a3f604743ed2c55ba67M7631842905dbc2f12c66fbGc46'4Of
Oxc3ffatd3o4T4f40dfOeTffffdfag2fJff 11d59d35d214ffff85c357cSc85ed72acaf1fb7d43f76d85€E6b4fbgffdd6Od5095€f 1f290df4ff888e7e37efe4f9e8f
0xcc7b14295347824ccb395bed351993c598c7cf7f4€32dcb9ab7a5d7eObaa7626d1b8dc651b34fSe4fSd3f2530b52fbgbd10e75259b36d774f059141bf9edE91 1
0xe675a7059b166df2O198J8a7saoab28123fff79a67f59c7049fd37d48128f3b3a9b69475b902f4bc854ca1deecbc€73cdab8gb17ae3c6401a9d43594775a926b
0xef7b77bd3defdef7f7b47bdEdef76f7b7bdsM6fef7bf7bdbdee7ef7b73d7bgEdEf7ef7b7b9e3deeef7bf7b9bdefd6ffffb97bdedef7ef7b7b9ebdafef3bf845
oxfd23b1 109620O0d5984t18c43407369898cdo086df?80826dcfa14784f38388874362851b7711dc13564441351335c71fbd7c564dSd50O8fSde20d43f2476d715
0xeg 18f165879091 1a71a9ae1895cfe56dbed767816e337€2f950462aJfb3280d8a8dcb1240620€c8r1d19c3750aJcfe295c58cca1 17b36632414cdgE114fdbo97
Oxffffaa5sffffJfffffScd9fe3ffff676fffffffffffe000o00oO00000O00O0@O0O000000O0O00o0o00000000000OO000O00000000000000O0o00000OOO0OO9d
0xc021000048041000001O0010008OO1ce20640O4242c812186250154c0000O088ba78008a43a9713bcOabb849220e8362cc838b53cf88fcdbdd7fca83c8df8145
oxe318318c8c63c631318c18c6c63163 1818c68c636318318c8c63c631318c18c6c631631818c68c6363183 18c8c63c631318c18c6c631631818c68c63631831d3
0xdsO1973162d4017f4e3b3cgd68Ogd4cc46a1d457c91feb5b6c2ae77423ba41 c9cfM5f4b9235667874507e9cafb4123e1992d1c5aE75ee29508701 1a822a6ccf
oxe28EccE1de7a0326423076465160c1bO3f8e721181eo4166f11860ae94d7802a082f9f6007c0011f2OO56dE200677aa7d8a47!.18€6692ee4b3f862c24e04b543bs
0xda2f36d74bc2dc29ds4de92f4b37bo3942173e15a2dfb6708f09e790ed1656af5a8aadef14b696426f1e929699daO6E3adgf21a9f66edos7d945fc165b27d277
Oxd2a550a3a852Oa1c850aa14250a114baoa144285a1422850142AA50a428550E128400a14850aa14250a1 1408Oa!442ASa14228511428852a4685d0a12850Oa2d
0xe79082499b094b2459266493608a9249b241Od3409242692a49O824d934941254935265a341086119449d824691524922697926bb24949044027108a8c939a5d
0xedfc373f783ffbfff7fefEd:lfffafffefffdsfffffdefffsffdffff3ffSfJfferefdgfEfTfbfSdJff6l3bb59f9fbSf5bd52aefdTSebddf66edeeff63f3fb3dfs
OxfftTlfb6fbfffefffJtft6effffeefffefTfffebfffeffffffffefffgfffffcbfdbffOfaJfffdfffTfT€dffeeTadJftafffbfbTefffldffdeTfadfdef63eS06b
7c95aa0b93065a3aa924594ldf b9f 521535
oxf6b43e3bd52847756d.1a27722a859oa8a1c43c1c36b95cc72dO102f26b6da1b238236856J7c6€6faa83cc70e84f2dM40884a7fd94a175f22a0d990cc1af6a6b
0xd2a2od1b98tre2152b9d93cf6obf98f68e9f9e05Ofeb982ObO06eSdc581f17a82f35a78d23fb34fab3962ae95bct3a1e442eb5b1d72cd6956fa599483ee638c1
0xe52e529494a54a535294294a4a51a509294a96a5a529529494a54a82529d29oa4a52a5.22298a94a5a522529494a44a525294294a4842a526294af4a8a52f554b
0xc942c4644b116946 1581e0713ba400570237a55c9a669e9fe58d189u751d218208421934f2132a888e796bc1JO914a8c9b4f 116358cca22c69c35596bd961es
0xsd7f7e78af c7d3735fc1dfbod13887cddcd715c9fe530530€Oefceaa4bcaffbaebac9e601623db36lff€f47fffff€fffffffO000OO000000000000O0O0OO03ed
Oxf6db9b6dda6d29b61dfe73dbbaSbdb6ddead69beEdf6a6dbj7dadbGddf6c6cb66db6f6d3b6db9b64997c6dbe6cb4364b96dbdb6ddb6c67b66da4b7cbaedadf35
0xc080a100000o0000000000O00000O000O0OOOO0O0O0O0OOO0O3OO800O880000002608020010120004408001O042020800008000O005000000010O0000O09O0e1
0xe5335f76a97cSe29d4557170cdgef3ed53efc819fda87a566a5efe247ef 1O2b85c7ad90c484adg030c7ebc23455a0dcbca2cec6aJdf0s8c978cb6fbEd5733fas
0xc000oOO0O000OO0000O0O000O000O00OOO0O0O000O00000O00OO0OO0OO4O0000O0OO00O000000O000oo000000O000o040O00000000000000O000000000000165
Oxc924249324929249b2ct49244924649264927a489249493659332ob93t9292e992497d7449242492229293499249492449262493248096fff3c9104432f4cdbb
0xc9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
0xc00OO0OoO0OOOO0Oo0OoOO0Oo0OOOOOOO0OOOOOOOOOOOoo00O000OOOO000OOO00O00o00000o0OOO0OOO0000000O000000O0000o000000o00o00000010O00O177
0xc0O0O004100240000508O0O80210O004900OO0O100O00O02080Oo0000001O21005180000000O0000O0002100806000400820004000001830010000002OO02Of 1

0xcadOca7166b2aaf6c82b0eadfsb13409da7c2679517d4fd96f89719659133eO492d209da600753dcSc2570ce128cf985332f944143204b706bf6e990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 223

0218

Factoring R§A keys from certified smart cards: Coppersmith in the wild 15

Ox6zg9739c9ca7c€73739c39c8cä73673939c69ce7e739739cgce7c€73?39c39ceco73€73939c69ce7e?39739c9ce7ce73739c39cece73e73939ce9co7e73973df
oxeo92924992494g244g2424ga24y2g24gg24g4g244g242493249292499a494924499424922492924992494924492424922492b24992494924492424922442926f
oxcooolooooooooooooooo«)ooooooooooooooooooooooooooooooooooooooooooooo1oo8o20oocboorlogo8809180008c8000000010c00012101b20000000002ad
0xcEcz27oo9Ef07418dc89€2c96€T96d44bc2244d88aobb8cagob4d661736brl{t6b6e1d8352822a4697cddo702a3d8b7c4b23adä2285a2af09234a713t16ba141795
Oxc8dce72coe38ecaJ2egettaefOZg26e3llli1a92ad87et29fr3dob6d4b3doo646bebd7b3al6cg a424a0?4e14AGd786d26997a4d9c131acb524881a€cace287c057
oxe609f,0b662014c7299s188527ab8cdo0rt809c631f1td50a200133316?8ccad2o631879842b8a122569eb18c4b1dd5e4b11bce7a14f4ae76973debf4ca768c4bd
Oxd66cda6ef2Z6bfd:td1ee6S(U4ilodd7aeO1sbdoe9a5e43890s7835e2a2aofb702703d6c3fd50d5917f3ban aeb851c0t6d26135d7Rlcl 14adf303dO916OO462bd
Oxtal4TeaSScddaaabe6<ua04ff891OO9db3ff37e1272d573b7a3da5334f24f9512fda7ff4t163a72482aOedffa9140001ae21fSa64fd330f93s819a968acafb7
oxf718cobc8c57cc318c99fa15236191a531828a9585ü6ac833a7e3a2110d ded26226ea4g44cabbb2fe19dE14863b8cal6631bAl4038c8768ce4aea42a1oafabfg1
Oxd86d99e183bagc08zo23Bdbs71ld3f673cdEc3112196acfaal239667bcb3a3a7f6749f3229I66Od5O9751065aEdJ0626a641€21121 12f95080c5629973b1c975
oxfc 1fc95ee7at82142bccb7fObc5cd6:l4ad82adca61fe2663c7A622Eo673,4{l5cc1 1c993aaeeb15I?7d90dfe1c6a9tl5e239ab47e5ca3sb2aob702l2d636626858db
orf7c6bf218fcfadcbag26acsefdf6of97aeba8dsf70ceb27effof5d57E?63bf68&tc7a866€76b8ba9do76bf 1a8f4a7fGfbo297a96c6c5a70ea765€3c38326tf83
OxcS94391e8E8c24c8a7fe971d78db78ald43c96ba3384l O2acfr71c25f,6736c65l?crt4ef6c3bbf7bO5659b954c6bgce96t648c900b56cSf3cao1e47384ad4dE577
Ordag75410693d3 72}bg2gg7c€,cr2gfO9dO961Ot5fefO89a7cf63ff1dcf673ffffb493c19c64167eO457646aaba4f3ato9f9648ff7c390c25d4a8a3d7c9b2f16b2d
oxf,16f6ad9af03cfcb36571b8b3le3cf246313aece858b7dato800838329c9b?29ecc6d69ldf4ee8547a9fdb18debbca338af8214ta1603ad53f8e3a0503bfb6735
O(ddfgbs6a7bb556afa1476addb5rlaa95e569c94ab62d5fa95c054af04bSaBb56adlf66e2dbb466Ed1b56aad6a1629cEa93ads6bf5ad163bazl65ab9722daJ5d7bd
Oxdggs8f€3Ogg4ba9c8c02ac21Oc4dc8s6€6lOd1c958cb4d4:!6e11aEdeof72e3b8a88618b7c663533218c68Ed66ObO31ad4ce38aa13bbc1ob6c73fe3911acc8de1
Oxfcbo66gefSa3c9229368A4099fd?87aOalegfdd178O1?O2l72gctbig2'7ofditc5e60787fc59128bceEbfcU|8bE0cOilbOBcO87fdtlfe6b9602o7c93ca4cf3cSadd
MAT A BSI-1-6c_3.pdf, Blatt 224

421 e

16 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N vqn Someren

B Appendix: FIPS-140 certifcation


Searching for the term UFIPS' on MOICA's website (http://moica.nat.gov.tw/htrnl/en/index.htm)
returns the following entries in the FAQ section, all of which claim some security through FIPS
certification.

+ g i,'r molcanalgoutw::, .1.,:,

.i
Irii1,;.
.i search Fitrt---l m *I'*ttt ,,," ;"0

.1,.!9!,1!-. , ,-ulgj$3!qt j_stlrti9-qts 9ryi!9§ ße!.a§q L?.r§-q.Egsulillgns- :fs!.lic-q!l!!-,.-Faq

ti:.:ti:)\:''''
§-.e-a rq.h

j no^"

.-\.li ir !*llq::il.l" rr i,,j !:!\: .iar fron Ctltiiic;rq iC crrd'. 1:rirarr,


k:'1 p.lrrueter r\ ir i ,illri i,r t-.rr1*ogrphir: ,\;Iodrrlr, \!hi(h !, rfili.e' ,
,,he li5.l. .rrrrj r $liloQ
fIrlpratoi: .1. jjrjvür i.:e,,- is itscil tc <r,:ati. .

f.i J !r'ül.ii. dnJ iiFit ri, iI5i\r. P.!1i.1e5. lbt lil t:i.l a.<ordri,ie r"itL :

lfPS .l 10-i I er rl r .:er ti lj..{rle bi' lil catd ru""}aBtrr eut icrllr üti tlx.'
r-rril f':1;11y, !,1';,,"cuii1'. :L pri':tr 1..,t1 is i:reatt,j rrrriri;: srd ,1..'
!,rir.rip ler',::ir, r e.rport h tn IC ca: l altet lt',' treated
.i:lr : iiilih r:sl, !-, r:ir! fei[ificaG iJr thr flip,p'y i[sL ttrat tiL! tt;il;ioq
rop!' .u {l} ii$ri l he {:irired digital (-.rlilicat+ Fass F,PS l,lil-!
I l(] lrtlr+riri. i*eJ : ar,i ilat? hldr serf,{iiy. Prilnte kel car't br (:eDt
ftoa ir r*C ater 3ererare ke-i pair rrf iuside üe lC ra d. Tiis
;rrrilrrrre Isr of rs I.lrll \'.-'. The p0li(l ot.iri;en di&iril (fl tih( itr
tlrnt .rr tiiir,rt. rirriili(l lond i*o I{: ilard
,r,.r i,:oraing G cp-s ci rrcill.\ ihe {C cara ii iii g}i ieciu:ir': ana il
FAQ lrlt b*cn rrrretliiod tn FIPS i.tO-l lavel ? mdtlie car.l use is ur,rd
ro (r !rr(,t. !irüi, r l. a'rtl stor e iu.HS\i
.

.\: The ti.{ Ler. p.rirs are gererated rrithil lnr:cirvarr crypto ig aphi c I

*orhrirs o; :oltr'*t.irarr'lware tryptcgraphic aroduies rr'rihir tle i(-


F-\Q
crd. utetilgrtrlureoenti ofCPS.ald FIPS 140-I kvcl : :

tatif:caticE or rom!,toble sicruitii sg1:1$t !C iur{, I


i l lic (-ir. l+r'9 ;ue rrc.lied ir . tJtp[og rphiu uoclule. usiug R§.\ :
r

rlgor ithu erl r {rlon ftruber gelir Ä(or. i:reiled',iiihix d hn,li.;are,


srori[io. the priraic !.:eI is sror{!1 iusids sirhorr iealiage. i\,loia.,fcl.
c+riihraie rrh:crih.er's if-: (ad is irlrernillX B€neriti,l itiCr ai!-c i ril'
I ie"il .l cnüifi(iiür ,f tl)i Cird (l{nrer. Tile lritnr. }:er r'.ili sar

i:liirvitrg, i nrprctic ,:rtC rs dic clrrrtt ior rii* (er i;[i(ii!. darr itxiLlr
rrr !r+ r.rsill rr-rirlcrl *d tlr,Lisii ir higlr iirargir FIPS tl0-l I-?1cl i
rülcrni.nrirs. 1ir. icrtriicatc i,.l catd is highl; :ecrre. r\ 1:riLlir: licl, ir
bri;;g pl+rrr:r;+J rrvcrikllli. .rftr)r rr,hi(lr n p r§,11§ liel ciirürol tre
l:xpir ie,l uu r +irlicaieri $rhscl rbei's illlel eit inD oEiI br, lrtllraled
urirs 1r{dfi.,nir ir ortidou .1:.509 :! lcvrl
"
TotalS Page l, l--- [ ],rr:.r l! j I Fter 10 .l
MAT A BSI-1-6c_3.pdf,
file;lll Blatt 225 #t

Ueak RSA keys

Von: a22
An: thomas . hessetmanntabsi. bund . de
Datum: 30,08.2013 12:03
Anhänge: (§J

Comments on the Präsentation on Crvoto 2013 Ramp-Session about Certficatesv2.odt.ooD

Hatlo Herr Hesselmann,

ich habe im anliegenden Dokument meine Kommentare zusammen gefasst. Es enthält keine vertrauliche
Informationen, die gern auf direktem Weg.

Mit freundtichen Grüßen / Best regards

rroduction, Computing Services & Sotutions


Consultins & Ensineerins
i.ffi
. rai'!. :
Tel:
E -Maii:
I nt e rnet

Geschäftsführung:
Handels registe r :
Sitz der Gesellschaft:
xil;;äl}il,ffith/orattachmentsmaybeprivi1egedorconfident1at.Ifyouarenotthe
intended recipient, you are hereby notified that you have received this transmittat in error; any
review, dissemination, or copying is strictly prohibited. If you received this transmittal in
error, please notify us immediately by reply and immediatety delete this message and all its
attachments. Thank you.

-. Comments on the Presentation on Crvpto 2013 Ramo-Session about Certficatesv2.odt.ooD


MAT A BSI-1-6c_3.pdf, Blatt 226

022t

Comments on Crypto 2013 Ramp-Session


Presentation about Weak Taiwan Citizen Digital
Certificates
Wolfgang Killmann, 28.08.201 3

The lssue

Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja
Lange and Nicko van Someren gave a presentation on Crypto 2013 ramp-session "Factoring
RSÄ feys from certified smart cards: Coppersmith in the wild" available on []. The authors
analyzeä Taiwan Citizen Digital Certificates issued for government-issued smart cards (slide
2 shows the MOICA card). They discuss a hypothesized key generation process for weak
primes (slide 9) and hypothesized reasons (failure) why government-issyed smartcards
generating weak keys liiide 16). On the 2d slide is a statement'FIPS-140 and Common
Öriteria Level 4+ certified", where it is unclear what component is meant: the smartcard
application, the operating system (OS) or the integrated circuit (lC). Unfortunately, the vocal
presentation is not available for additional information.

The following comments discuss the key generation for Taiwan Citizen Digital Certificates
and whether Common Criteria certified components might cause the weakness discussed in
this presentation.

The term 'RSA key generation" refers to the generation of the two prime numbers p and q,
which product builä the modulus n and if a fixed public exponent e is assumed also define
the private exponent d.

Summary of the presentation about RSA generation used for Taiwan Gitizen Digital
Certificates

The authors of the presentation analyzed 3,002,000 certificates for RSA keys available from
Taiwan national LDAP directory and found 2.3 million distinct 1024-bit RSA moduli, 700,000
2148-bitmoduli (cf. slide 3). Note The Certificate Authority of Ministry of lnterior (MOl) issued
a total number of 3733239 certificates (2013108128).

They apply an algorithm finding common prime numbers in different moduli and found
commonly shared factors (cf. slides 7, 8):

(1) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000002f 9

(2) c92424s224s2924g924949244g24249224g2924g92494g24492424g224g2g24g9
24g4 g2 4 4 g2 42 4922 4 g2g2 49 92494 92 4 492 42 4922 4 929 2 49 92 49 4 92 4 492 42 4e5

Based o these primes they assume a hypothesis about the prime number generation
algorithm (cf. slide 9) and äpply factorization algorithms based on hypothesis on specific
types of prime numbers in the moduli (cf. slides 11 and 14):

09,05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 227

0222

(3) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000101f f
(4 ) c 000000O000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000100000177

(5) ffffaa55ffffffffff3cdgfe3ffff6T lfffffffffffe000000000000000000000


00000000000000000000000000000000000000000000000000000000000009d

(6)c000b800000000000000000000000000000000000000000000000000000000000
000068000000000000000000000000000000000000000000000000000000251

Based on their findings the authors conclude hypothesized failure

(1)a weak algorithm were used for generation of the prime numbers (cf. slide 9) and

(2)possibly weak random number generator was used (cf. slide 16), especially

a) hardware ring oscillator gets stuck in some conditions,

b) card software not post-processing RNG output.

Key Generation for Taiwan Citizen Digital Certificates

This chapter analyzes public available information about the key generation for the Taiwan
Citizen Digital Certificates.

1.1.CSP of Ministry of the lnterior Gertification Authority

The slides of the presentation do not provide details about the certificates with found weak
RSA keys like issuer, validity of the certificates, Certification Policy or Certification Practice
Statement (CPS).
O
The CSP of Ministry of the lnterior Certification Authority (MOICA) is issued as version 1.0 in
2003-04-03 and last updated asversion 1.6 in
2013-06-1 1 (cf.
http://moica.nat.gov.tw/htmlien/cps.htm). Only the versions 1.2 issued in 2003-11-26 was
found in English translation. The CPS Version 1.6 in Chinese is available from the website
http://moica.nat. gov.tw/download/MOICA_CPS_V1 .6. pdf.

The CPS, version 1 .2, states in chapter 6.1 .1 Key pair production:

,,Based on the provision of section 6.2.1, this authority will produce key pair within the
software cryptographic module and will adopt true random number generator and RSA key
calculation method. After the production of private key within the hardware cryptographic
module, it will be stored there all along and will not be leaked out."

"The token utilized by the subscriber is lC card. For its key pair, after the card management
center has driven the lC with the safety control system, it will be produced on its own within
the lC card. ln addition, after the key pair production is completed, its private key cannot be
transmitted from the lC card."

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 228

0223

Further statements are in chapter 6.1.7 Key parameter quality inspection:

"This authority adopts ANSI X0.31 calculation method to generate the prime number required
by RSA calculation method. That method can guarantee that the prime number is strong
prime.

Subscriber's key can generate the required prime number in the RSA calculation method
inside the lC card or other software and hardware cryptographic module. However, it is not
guaranteed that such prime number is strong prime."

The descriptions of key generation in chapter 6.1.1 and 6.1.7 in CSP version 1 .2 are contra
dictionary. Therefore, few detected weak RSA keys might be produced by software and
hardware cryptographic module, not by lC card.

Note, Google translation of CSP, version 1.6, section 6.1.7 seems requiring that "the user is
using the security level through F|PS140-2 Level 2 certification the user smartcard Security
lC card hardware cryptographic modules". [2] refers to the MOICA FAQ that cards are "high
security", and "have been accredited to FIPS 140-1 level 2" (cf. chapter 4.1 below).

1.2.MO!CA Smartcard

Suppose the weak RSA keys, i.e. the prime numbers p and q of the module n are generated
by the smartcard used as subscriber token. What is known about security assessrnents of
the MOICA smartcard?

MOICA states on his homepage [3]:

"lf än applicant loses his/her/its lC card, and the card is picked up by someone, can the card
information be stolen out?

A: The CA keys are created in a cryptographic module, using RSA algorithm and random
number generator. Created within a hardware module, the private key is stored inside without
leakage. Moreover, certificate subscriber's lC card is internally generated with FIPS 140-1
level 2 certification of the Card Center. The private key will not export after generation."

MOICA does not provide technical information about the subscriber lC card product itself.

The company lDpendant GmbH, a member of the TRÜB Group, informs on its website [4]
about a reference project [5] for the MOICA card. The described solution is based on the
SafeSign ldentity Client of AET. AET provides the SafeSign ldentity Client with JCOP. smart
card. lDpendant provides other smartcards as well, cf. Bl (2008) including

. IBM Java card OS JCOP21 v2.3.1 (CC EAL4+) on NXP chip P5CC036/72,
P5CD036/72 andPSCTOTZ (all CC EALS+),

. Giesecke&Devrient Sm@rtCafe Expert FIPS 64 (FIPS140-2 level 3) and Sm@rtCafe


Expert 64 Bio on Renesas chip AE46C1 (CC EALS+),

. i-COS 36 on ST Microelectronic chip ST19XT34

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 229

0224

and other smartcards. JCOP v2.3.1is evaluated by TÜVIT and certified by BSl. Sm@rtCafe
Expert FIPS 64 is F|PS140-2 level 3 accredited. The Sm@rtCafe ver9io1s. provided by
lDpendant are not CC evaluated, but Sm@rtCafe version 5.0 ia evaluated by TÜVIT. All NXP
and Renesas mentioned chips are CÖ EALS+ (including AVA-VAN 5) evaluated by
T-Systems and certified by BSl. The chip ST19XT34 is according to fl EAL41 evaluated but
the torresponding certificäte was not published t8l I9l The OS |-COS 36 is neither evaluated
nor accredited.
(probably lDpendant
[10] refer to private communication with a supplier of MOICA card
bninHl that his MOICA cards are EAL4+ certified and accredited to FlPS140-2 level 2. This
does not fit with [11].

Based on the referenced public available information one cannot concluded about the
concrete MOICA card implementation which could have generated weak RSA keys.

RNG used in MOIGA smartcard chips and their successors

[12] states in chapter 2.1:

"lt is clear from our results that the random-number generators used in these cards are in
fact awed, and that any keys generated using these cards should be considered insecure."

The hardware random number generator (RNG) of the chip is an important but not the only
smartcard component involved in RSA key generation. The OS of many state of the art
smartcards is räsponsible for online testingl and post-processing of the generated random
numbers. Even the current state of the art smartcard chips do not generate RSA keys. Only
the combination of hardware RNG of the chips and OS generates RSA keys. Therefore the
weak RSA key generation may be caused by errors in the usage of the hardware RNG
output and key generation as well.

This chapter discusses generation and use of random numbers for RSA key generation.

1.1.RNG of FIPS 140-2 accredited smartcards

Chapter 2.3 discusses random number generation and states:

"As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
,pp"rr to utilize a source of randomness that is prone to failing, they fail to perform any
runtime testing before generating- keys, and they clearly do not apply any post-processing to
the randomness streäm, The lack of testing or post-processing causes the initial
randomness-generation failure to be much more damaging than it would have been
otherwise."

They authors refer to standards (NIST SP 800-90A, ANSI X9.31:1998) and evaluation criteria
(FIP-S 140-2, BSI AIS for CC evaluation / certification) for RNG. They missed the fact that
tftsf Sp 800-9OA and ANSI X9.31:1998 describe deterministic RNG only. FIPS 140-2
require approved RNG but only deterministic RNG are approved so far.
1 Note the newest NXP chips implement online tests in hardware.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 230

0 225

FIPS 140-1 level 2 smartcards are required to implement statistical power-on tests. The
power-on test will not effectively protect against failure during operation and perturbation.

FIPS 140-2, chapter 4.9, requires acontinuous random number generator test, which
requires to compare any new'generated n bit block (n>15) with the previous generated block
and the test fails if bit blocks are equal. lf the length of any repeated pattern does not divide
the output length of the compared pattern the test will not detect the bad random numbers
(e.9. if the pattern has odd length and the compared pattern has even length the consecutive
blocks may be different and the test fails).

lf the MOICA card is FIPS 140-2level 2 accredited the continuous random number generator
test should detect the patterns causing the weak keys by repeating short bit sequences in
the prime numbers shown above and in the Annex A of fl 3].

1.z.CC evaluated RNG according to AlS20 / AlS31

The BSI requirements for Common Criteria (CC) RNG evaluation laid down in AIS 20 / AlS31
address

(1) the generation of entropy,

(2) the post-processing if implemented,

(3) the quality of the RNG output,

(4) the health test (tot test and online test) detecting failure after start-up and during RNG
operation.

The requirements shall prevent the weaknesses discussed in [4]:

. The T0 test (disjointness test) as part of test procedure A of PTG1 and PTG.2 class
RNG will detect repeated patterns in the RNG output during the evaluation. The
PTG.3 class RNG prevents such patterns by means of
cryptographic
post-processing.

. The tot test shall detect break-down of the entropy source and prevent bad random
numbers output for PTG.1, PTG.2 and PTG.3:

"A total failure fesf defecfs a total failure of the entropy source immediately when the
RNG has started. When a total failure is detected, no random numbers will be
output.

. The online test shall detect non-tolerable statistical defects of the raw random number
sequence immediately when the RNG has started, and while the RNG is being
operated. lt is a quality check of the generated random numbers usually realized by
hardware by physical measurements, or by OS as statistical test or a test procedure

2 The first n bit block generated after power-up, initialization or reset is only stored and compared
with the next n bit block.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 231

0226

that applies several statistical tests. lt shall detect bad random numbers output for
PTG.2 and PTG.3

Roughly speaking the tot test shall detect very bad random numbers very quick (short
sequences) and the online test other non-tolerable weak random numbers slowly.

Some RNG prevent with high probability repeated short patterns in the RNG output
additionally by design. The post-processing with internal memory may reduce the probability
of repeated patterns and stores some internal entropy to mitigate temporary low entropy
output of the source of randomness. E.g. the BSI CC certified Renesas chips are AIS 31
compliant and provide post-processing by linear shift registers (LFSR). Some chips allow the
OS to enable / disable the post-processing.

The RNG of smartcards under evaluation may be implemented completely in hardware or as


combination of hardware and software (OS) components. lf the RNG is implemented as
combination of lC and OS components the OS components shall be precisely described in
the guidance documentation and are subject of the lC evaluation. lf the OS developer
implements the certified software components the RNG evidence of the lC evaluation are
applicable for the smartcard. lf the OS developer deviates from the guidance documentation
the OS developer shall provide additional evaluation evidence and the composite evaluation
shall analyze the modified RNG.

The failure of the hardware RNG is not the only possible source of failure of the RSA key
generation. The OS using the hardware RNG shall obey the guidance documentation
describing the method of use of the hardware RNG which is CC evaluated. lf the guidance is
not obeyed the operating developer cannot rely on the certified security functionality of the
RNG.

Typical errors of hardware RNG usage are:

The OS may read the hardware RNG output register before the start-up tests after
power-on, sleep mode or soft-reset are completed. The RNG output register may
contain undefined or constant values (e.9. zeros or short patterns as seen in the
weak prime numbers).

The OS does not implement and run online tests even if required by the guidance
documentation of the certified lC. This might speed up the key generation process but
with bad random numbers.

The OS does implement and run RNG tests different from those described in the
guidance documentation of the certified lC. These tests might not be non-appropriate
for the hardware RNG used.

The OS read the hardware RNG interface in short intervals not obeying the time for
generation of fresh random numbers in the output register of the hardware RNG
described in the guidanee documentation. Note the hardware RNG may generate the
shorter internal random numbers and sequentially fill the output register. ln this case
the output register will contain fresh and old random numbers if read before
refreshing the whole output register.

09.05.201 4T-Systems GE I GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 232

0227

Summary

The available information is not sufficient do decide about the reasons for generation of weak
RSA prime numbers in the RSA moduli in some Taiwan Citizen Digital Certificates. The
conclusion made in [15] and [16] about failure of hardware random generator of the MOICA
smartcards is only one of possible reasons.

The reason for the detected weakness shall be analyzed by (i) checking whether the weak
RSA keys were generated by the MOICA cards or no( and (ii) if smartcard key generation is
confirmed by analysis of RNG implementation and usage in the MOICA smartcard.

References

[17] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger,
Tanja Lange, Nicko van Someren: Factoring RSA keys from certified smart cards:
Coppersmith in the wild, slides of ramp-session presentation at Crypto 2013,
http ://crypto. 20 1 3. rump. cr yp.to/55e2988c4ed3c9f635c9a4c3f52fa0b 1 pdf.

[18] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger,
Tanja Lange, and Nicko van Someren: Factoring RSA keys from certified smart cards:
Coppersmith in the wild, paper to be presented at ASIA Crypt 2013

[1 9] http:/lvrrrrrnv. ldpendant.de/loesungen/egovernment. html

[20] http.//www.idpendant.de/fileadmin/pdfsi2007-04%20MOlCA%20Fallstudie-dt.pdf

[21] http://www.idpendant.delfileadmin/pdfs/2009-1 1_DS-Chipkarte-DE pdf

[22] http://www. commoncriteriaportal. org/products/

[23] http://www. ssi. gouv.frlen/oroducts/certified-products/

O [24] http:i/moica.nat.gov.tw/html/en/index.htm, FAQ 0502

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf,
file:lll Blatt 233 #1

Al{: Unsichere RSA-Schlüssel

Von:
An: 022
Kopie:

<oe reon . kitlian@bsi . bund . de>


Datum: 30 . 08 . 2013 15 :01

Halto Herr Hesselmann,

Als einzige Hardware aus der Liste der M0ICA-Karten sind bei uns die Chips der 66er Serie von
Infineon evaluiert worden.
Das diese schon uratt sind, spiett das keine Rolte mehr. Außerdem sind die 0S darauf meines Wissens
sowieso nicht evatuiert.

Zu den JCOP Produkten kann ich so adhoc nichts zu sagen, da muss ich erst mit den Kottegen
sp rechen.

Best reoa rds

I
Product Manager Hardware Evatuation
IT Security
Evaluation & Vatidation

PGP Fingerprint: 89F9 A056 E366 888D 79D5 CF9C 61FB C49A 7D0E F22A

--- --Ursprüngliche Nachricht- -- --

u,Hi:"lHl;,
\n:
', Stefan; Pingel,
'
Cc: Susanne; Kitlian, Gereon
Betreff : Unsichere RSA-Schtüsset
* PGP Decrypted Message

Halto
seit einigen Tagen beschäftigen wir uns mit dem fotgenden Sicherheitsvorfal.t eines TRNG:

- htto: ' rvoto.2013. rump. c r. vo. to 're2988c4ed3c9f635c9a4c3f52faOb1. odf


- Paper- im Anhang (in Draft-Version, bitte nur intern benutzen)
Es scheint so, dass die Guidance (Tot- und Online-Test) r"roht nicht beachtet wurde, aber dies sind
nur Spekutationen von unserer Seite,
Bei den ü,eiteren Nachforschungen erschien uns zunächst, dass nur die Renesas-Chips betroffen sind.
Entsprechendsind-säwieHiervoninformiertwordenundumSte1I.ungnahmen
gebeten urorden, Aktuett-aber können wir nic5t ganz ausschtießen, dass vietleicht auch Karten
anderer Herstelter betroffen sein könnten.
Auf der fnternetseite von IDpendant GmbH findet man, dass diese Firma ebenfalts mit der Ministry of
the Interior Certification Authority (M0ICA) in Taiwan zu tun haben:
fiteill
MAT A BSI-1-6c_3.pdf, Blatt 234
#2

htto: //r,rww. idpendant; de/loesungen/egove rnment . html


http : r/www. idoendant . de rfiteadmin zpdfs /2007-04t20M0ICA%20Faltstudie-dt . odf
022e
Auf der Seite
http : /rwww. idpendant. de/fiteadmin/odf s/2009 11 DS-Chipka rte DE' pdf

werden Karten aufgetistet, die woht ats M0ICA-Karten genutzt werden, Hier findet man auch

- JC0P v2.3.1
- Sm@rtCafe Expert .. . anscheinend nicht die evatuierte Version ?

Wie ist Ihre Einschätzung? Liegen Ihnen vietteicht mehr Informatiönen vor?
Sind bei uns zertifizierte Produkte (inbs. die von TÜViT evatuierten) betroffen?
G rüße

Thomas Hessetmann

out of the office in the weeks 41-42, 52-92. During this time I will be

fE[:'l:'::l.i ä']":: mait.

Bundesamt für Sicherheit in der Informationstechnik Dr. Thomas Hessetmann Referat S22 Godesberger
Attee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Telefon: +49 (01228 99 9582 5691


Tetefax: +49 (0)228 99 10 9582 5691
E-Mait.: Thomas.HessetmannGbsi.bund.de
Internet : wr,ry. bsi. bund. de
m.rrr. bsi - f ue r- bue roe r . de

Sitz der Geseltschaft/Headquarter:

ffr
Geschäf tsf üh rung/ttanä§eD€lr t

Exceltence for your Business

Please visit our website:


Besuchen Sie unseren Internetauftritt:
MAT A BSI-1-6c_3.pdf, Blatt 235
fitelll #t
Unsichere RSA-Schtüsset
Von: (BSI Bonn)
An: 023
Kopie:
,
<oereon. kitlian@bsi. bund . de>
Datum: 30.08.2013 13:32
Anhänge: ($
.: smartf acts. odf

Harlo
seit einigen Tagen beschäftigen wir uns mit dem fotgenden Sicherheitsvorfall
eines TRNG:
-,
- htto:/,/crvoto.2013. rumo.cr.vo.to,/55e2988c4ed3c9f635c9a4c3f52fa0b1.pdf
- Paper im Anhang (in Draft-Version, bitte nur intern benutzen)
Eg scheint so, dass die Guidance (Tot- und 0nline-Test) woht nicht beachtet
aber dies sind nur Spekulationen von unserer Seite,
O",
,ei den weiteren Nachforschungen erschien uns zunächst, dass nur die
Renesas-Chips betroffen slnd. Entsprechend sind T-Systems sowie Brightsight
hiervon informiert worden und um Stellungnahmen gebeten worden. Aktuell aber
können wir nicht ganz ausschließen, dass vietleicht auch Karten anderer
Hersteller betroffen sein könnten.
Auf der fnternetseite von IDpendant GmbH findet man, dass diese Firma
ebenfalts mit der Ministry of the Interior Certification Authority (MOICA) in
Taiwan zu tun haben:

htto: //www. idoendant , delloesunoen/eoovernment. html


httn://r^ruw-idnendant.dp lfilcadminlndtcl)Gr07 O4*TOMOTCAgT?OFaIlstrrdie dt.ndf

Auf der Seite


http : //www. idoendant. de/fileadmin/pdf s/2009-lL DS_Chiokarte_DE. odf

werden Karten aufgelistet, die wohl als M0ICA-Karten genutzt werden. Hier
man auch
O"t
JCOP v2.3, 1
- Sm@rtCafe Expert . . , anscheinend nicht die evatuierte Version ?

Wie ist Ihre Einschätzung? Liegen Ihnen vielleicht mehr Informationen vor?
Sind bei uns zertifizierte Produkte (inbs. die von TÜViT evatuierten)
bet roffen?

G rüße
Thomas Hesselmann

Unfortunately I will be out of the office in the weeks 4\-4?,52-02. During


this time I will be'unable to reply to your mait.

Bundesamt für Sicherheit in der Informationstechnik


Dr. Thomas Hesselmann
Referat 522
Godesberger Allee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn
MAT A BSI-1-6c_3.pdf, Blatt 236 #2
file:lll

Tetefon: +49 (0)228 99 9582 5691


Telefax t +49 (g)228 99 10 9582 5691
E -Mail : Thomas . Hesselmann@bsi . bund . de 0231
Inte rnet : www, bsi ' bund ' de
www. bsi-f uer-buerqer. de

F.rrrtfacts.odf
MAT A BSI-1-6c_3.pdf, Blatt 237

0 232

Factoring RSA keys from certified smart cards:


Coppersmith in the wild

Daniel J. Bernstein1,2, Yun-An Chang3, Chen-Mou Cheng3, Li-Ping Choua, Nadia Heningers,
Tanja Lange2, and Nicko van Somereno
1 Department of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
djb@cr.yp.to
2 Department of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600M8 Eindhoven, the Netherlands
ta:rja@hyperelliptic. org
3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{ghf jdks1, doug}@crypto. tw
a Department of Computer Science and Information Engineering
Chinese Culture University, Taipei, Taiwan
raadoualg@gu.ai1. cou
5 Microsoft Research New England
One Memorial Drive, Cambridge, MA 02142, USA
nadiah@cs . princeton. edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
nicko@good, coro

Abstract, This paper explains how to efficiently factor 183 distinct RSA keys out of more
than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that share primes and that a.re efficiently factored by a
batch-gcd computation. This is the same type of compuüation that was used last year by two
independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman;
Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands
of cryptographic keys on the Internet.
The remaining 80 keys do not share primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation failures: first using the sha.red primes as a springboard
to characterize the failures, and then using Coppersmith-type partial-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys found in
the wild.
I(eywords: RSA, smart cards, integer factorization, Coppersmith, lattices

1 Introduction
In 2003, Taiwan introduced an e-goyernment initiative to provide a national public-key infrastruc-
ture for all citizens. This national certificate service allows citizens to use smart-card ID cards to
digitatly authenticate themselves to government services, such as filing income taxes and modi-
fying car registrations online, as well as to a growing number of non-government services.'RSA
keys are generated by the cards, registered with a government authority, and placed into an online
repository of "Citizen Digital Certificates".
Unfortunately, the random-number generators used to generate many of these keys are fatally
flawed, and have generated real certificates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 238

0233

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

inspect repeated primes,


batch gcd observe patterns,
generalize

Public-key 103
database' secret keys
batch trial division

L2t
secret keys
batch trial division

t25
secret keys
pnmes
primes

172
secret keys

183
secret keys

Fig. 1. Retrospective summary of the data flow leading to successful factorizations. After successfully
factoring keys using a batch gcd algorithm, we characterized the failures, and used trial division to check
for broader classes ofspecified primes (input on the right) as exact divisors. We then extended the attack
and applied Coppersmith's method to check for the specified primes as approximate divisors.

This paper explains how we have computed the secret keys for 183 different certificates in use by
real people.

1.1 Factorization techniques


Bad randomness is not new. Last year two independent research teams [8, 11] exploited bad ran-
domness to find secret keys for tens of thousands of SSL certificates on the Internet, a similax
number of SSH host keys, and a few PGP keys.
Our starting point in this work is the same basic attack used in those papers again§t poorly
generated RSA keys, namely scanning for pairs of distinct keys that share a common divisor (see
Section 3). The basic gcd attack, applied to the entire database of Citizen Digital Certificates,
shows that 103 keys factor into 119 different primes.
We go beyond this attack in several vraJrs. First, the shared prirnes provide enough data to
build a model of the prime-generation procedure. It is surprising to see u'i,s'ible patterns of non-
randomness in the primes generated by these smart cards, much more blatant non:randomness
than the SSL key-generation failures identified by [8, 11]. One normally expects smart cards to
be controlled environments with built-in random-number generators, typically certified to meet
various standards and practically guaranteed to avoid such obvious patterns. For comparison, the
SSL keys factored last year were typically keys generated by low-power networked devices such as
MAT A BSI-1-6c_3.pdf, Blatt 239

0234

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers and firewalls running the Linux operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime factors: we hypothesize a particular model
of randomness-generation failures consistent with 18 of the common divisors. The same model is
actually capable ofgenerating 164 different primes, and testing all ofthose primes using batch trial
division successfully factors further keys. Otre might also speculate that the cards can generate
primes fitting a somewhat broader model; this speculation turns out to be correct, factoring a few
additional keys and bringing the total to 125. See Section 4 for a description of the patterns in
these primes.
There are also several prime factors that are sirnilar to the 164 patterns but that contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice-based partial-key-recovery attacks to efficiently find prime
divisors close to the patterns. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottom 40% of the bits of the prime. The bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes thern particularly
susceptible to these attacks. These attacks produce dozens of additional factorizations, raising the
total to 183.
In the end nearly half of the keys that we factored did not share any common divisors with other
keys; most of these were factored by the Coppersmith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersmith-style attack breaking keys in the wild.

1.2 Certification
The flawed keys were generated by government-issued smart cards that both the certification
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
It is clear from their externally visibie behavior, as shown in this paper, that the random-
number generators used to generate the vulnerable keys actually fali far short of these standards.
This demonstrates a failure of the underlying hardware and the card's operating system, both of
which are covered by certificatiou. We have no explanation for the discrepancy.

1.3 Observed response and recommended response


When we reported the common-divisor vulnerabilities to government authorities, their response
'was
to revoke exactly the certificates sharing common factors and ask only those users to regenerate
keys. See Section 7 for more details.
Our further factorizations demonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themselves as primes appearing twice, but sometimes
manifest themselves as primes that appear ouly once, such as the primes that we found by
Coppersmith-type attacks. Both ca,ses are vulnerable to attackers with adequate models of the
randomness-generation process, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for common divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much rnore than an indication that those particular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system; replacing
it with a properly engineered system and to revoke all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the primes generated by these srrart cards had been rnodified to include a card serial number
as their top bits then the keys would have avoided common divisors but the primes would still
have been reasonably predictable to attackers. Our work illustrates several methods of translating
different types of malfunctioning behavior into concrete vulnerabilities. There are many potential
MAT A BSI-1-6c_3.pdf, Blatt 240

023s

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vulnerabilities resulting from bad randoriness; it is important to thoroughly test every component
of a random-number generator, not rnerely to look for certain types of extreme faiiures.

2 Background
2.L The Taiwan Citizen Digital Certificate program
Taiwan's Citizen Digital Certificates (CDCs) are a standard tneans of authentication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certificate Authority (MOICA), a level 1 subordi
nate CA of the Taiwanese governmental PKI. Since the program's launch in 2003, more than 3.5
miliion CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates form a basis for the Täiwanese government's plan to migrate to electronic
certificates from existing paper certificates for a range of applications including national and other
identification cards, driver's licenses, and various professional technician licenses'
Taiwanese citizens can already use the CDC to authenticate themselves to a number of govern-
ment agencies over the Internet, in order to file personal income taxes, update car registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Certi,fi,cate reg,istration: In order to generate a CDC, a citizeu brings their ID card to a governtnent
registration office. A government official places the (smart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed by MOICA. The certificate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Stand,ard,s certi,fications: MOICA states that these cards are "high security", and "have been
accredited to FIPS 140-1 level 2", and also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For'comparison, the SSL keys factored last year were generated
by software-hardware combinations that had never claimed to be evaluated for cryptographic
security, such as Linux running on a hotne router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID prograrn. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly all, of the problems we have identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS 140-1 level 2 [1a]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certificates


In March 2012, inspired by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP directory at ldap://moica.nat.gov.tw. Out of these RSA keys,2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The i024-bit CDCs contain 2086177 distinct moduli, of which 171366 moduli appear rlore
than once. The repeated rnoduli appear to all be due to expired certificates still contained in the
database which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 241

4236

Factoring RSA keys from certified smart cards: Coppersmith in the wild

2.3 Random Number Generation

While gelerating high-quality random-numbers is critical to the security of cryptographic systetns,


it is also notoriously difficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial component of generating random numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, 1,6] specify correct behavior for these types ofsystems. In general, software pseudo-
iandom number generators require a significant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any run-time
testing before generating keys, and they clearly do not apply any post-processing to the randomness
stream. The lack of testing or post-processing causes the initial randomness-generation failure to
be much more darnaging than it would have been otherwise.

AnaLog RNG circui,ts: An analog circuit is the standard choice when hardware designers have the
luxury of designing dedicated circuits for random-number generation. An analog circuit allows the
designer to obtain randomness from simple quantum effects. While the use of radioactive decay is
rare in commercial products, the quantum noise exhibited by a current through a suitably biased
diode can be amplified and sampled to deliver an entropy source of very high quality.

On-chi,p RNG circu'its: Mixing analog and digital circuits on the same die is costly, so chip designers
often seek other sources ofunpredictability. These sources can include variation in gate propagation
delays or gate metastability, which exhibit inherent randomness. Designers can explicitly harness
gate-delay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take advantage of randomness in gate metastability, designers
build circuits that output bits based on the time it takes for the circuit to settle to a steady state,
a variable which should be hard to predict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variations, and subtle on-chip effects such
as.inductive coupling or charge coupling between components can cause free-running oscillators to
settle into synchronised patterns and metastable circuits to predictably land one way or the other
depeuding on other components nearby on the chip.

Hand,ling Entropy Sources: Even with perfectly unpredictable source of randomness, care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density, test the signal from the entropy source at run
time, and run the output through a compression function such as a cryptographically secure hash
function. These practices are required by a nurnber ofsecurity standards such a§ FIPS 140 [14]'

3 Batch gcd
This section reviews the appröach of [8, 11] for detecting common factors in a collection of RSA
keys, and reports the results of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA moduli Nt : pQt and Iü2 - pq2 sharing exactly one prime factor
p, thel the greatest common divisor of -lür and Nz will be p. Cornputing this gcd is fast, and
dividing it out of I[l and Iü2 produces'the other factors q1 arrd Q2.
Of course, this type of vulnerability should never arise for properly generated RSA keys. How-
ever, since [8,11] had observed weak random-number generators producing keys with repeated
factors in the wiid, we began by checking whether there were repeated factors among the Citizen
Digital Certificates.
MAT A BSI-1-6c_3.pdf, Blatt 242

a 237

6 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

Ilstead of the naive quadratic-time method of doing this computation (checking each N1
against each AI2), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementation available af lrttpsllfactorable.net/resources.html.
We ran this implementation on the 3192962 distinct RSA moduli and found that 103 moduli
were factored due to nontrivial common factors. This computation, parallelized across four cores
of a 3.1GHz AMD FX-8120, finished in just 45 minutes'

4 Attacking patterned factors


A properly functioning random number generator would never generate identical 512-bit primes,
so the discovery of repeated prime factors described in the previous section immediately indicates
that the random-number-generation process producing these keys is broken. This section analyzes
the structure of the repeated factors generated by the flawed random-number generator and designs
a targeted attack against this structure.
The 103 moduli with repeated factors show a remarkable distribution of the shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appendix A.
One prime factor, p110, appears a total of 46 times with different second prirnes. The hexadec-
imal representation of this factor is
c000000000000000000000000000000000000000000000000000000000000000
oooooooooooooooooooooooooo000000000000000000000000000000000002f 9

which is the next prime after 25rt 1 2510.


The next most common factor, repeated 7 times, is
c924249 2249 2924gg24g 49 2449 24249 2249 29 2 49 I 2 49 492449 242492249 29 249
9249 49 2449242492249 29 249 I 249 49 2449 2 42 49 2249 29249 I 249 49 24 492424 e 5

which displays a remarkable periodic sLructure. The binary representation of this integer, excluding
a few most and least significant bits, is a repeated sequence ofthe string 001 with a "hiccup" every
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. We hypothesized that nearly every repeated prime factor had been generated using the
following process:

1. Choose a bit pattern of length 1, 3, 5, or 7 bits, repeat it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the most significant two bits to 11.
4. Find the next prime greater than or equal to this number.
We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and tested divisibility with each modulus. This factored a total of 105 moduli, including
18 previously unfactored moduli, for a total of 121.
None of the repeated primes exhibit a (minimal) period of length 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods typically appear
i1 fewer keys than patterns with shorter periods, and are thus less likely to appear as divisors of
two or more keys, raising the question of whether there are primes with larger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extended
this test to include length-9 periods and length-11 periods. The length-9 periods factored 4 more
keys but the length-11 periods did not factor any new keys, leading us to speculate that 3, 5, and
7 are the only factors of the period length. We then ran a complete test on all length-l5 patterns
but did not fi1d any further factors. The total number of certificates broken by these divisibility
tests, togebher with the initial batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 243

0238

Factoring RSA keys from certified sm ;ds: Coppersmith in the wild

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime factors dividing the same modulus.

Sporad,ic errors: The handful of shared prime factors in our sample of gcd-factored keys that did
not match the above form were differing from patterns in very few positions. We experimented with
finding more factors using brute-force search starting from 0xc0. . .0 and found a new factors, but
these iactors are more systematically and efficiently found using LLL in Coppersmith's method,
as described in the next section.

5 UnivariateCoppersmith
Several of the factors computed via the GCD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic errors' Coppersmith's
method [5,4] factors RSA rnoduli'if the top bits of the primes are known, which matches our
situation if the errors appear in the bottorn few bits of a factor. This section presents this method
following the variant by Howgrave-Graham [f0] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factored.
The idea is as follows: we assume that some prime factor p of N is of the form
P: alr
MAT A BSI-1-6c_3.pdf, Blatt 244

023e

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

where a is a 5i2-bit integer known to us (one ofthe bit patterns described in the previous section)
and r is a small integer error to account for a sequence of bit eirors (and incrementing to next
prime) among the least significant bits of p.
In the Coppersrnith/Howgrave-Graham method, we can write a polynomial

l@):o+*
and we would like to find a root r of / modulo a large divisor of lü (of size approximatel y Nr/2 x p) -
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new polynomial g(r) where g(r) :0 over the integers, and thus we can factor I to
discover it.
We construct the lattice .L as
lxz xa ol
I o x al
Io o N.l
corresponding to the coefficients of the polynomials N, f (Xr), Xrf (Xr), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of'a polynornial g(Xr). Then we compute the roots ri of g(r) and check if a* ra divides N. If so,
we have factored .lü.
Any lattice vector is a linear combination of / and N and is thus divisible by p. A prime p is
found by this method if g(ra): 0 rnod p holds not only modulo p but over the integers. The latter
is ensured if the coefficients of g are sufficiently small. The shortest vector u1 found by LLL is of
length
>t) / a ([et L)L / dim r',
lu1 | < 2(ai-

which must be smaller than p for the attack to succeed.


In our situation this translates to
,rtz 1y3X)t/z a yr/z <+ X < 2-7/2yJl/6,
so for ly' - 2ro2a we can choose X as large ffi 2170, meaning that for a fast attack using dimension-
3 lattices up to the bottom third of a prime can deviate from the pattern a. In the following
we ignore the factor 2GimL-L)/a since all lattices we deal with are of small dimension and the
contribution compared to N is negligible.

5.1 Experimental Results


A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this method for one of the 164 patterns identified in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including all 105 keys derived from the patterns without eruor, and
found 39 previously unfactored keys.
It is worth noting that the 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000. ..0f. Including 0xd0000...0, 0xe0O0O...O, 0xf0000. ..0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation might set.the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's method can find primes with errors in up to 1/2 of their bits using lattices of
higher dimension. Getting close to this bound is prohibitively expensive, but trying somewhat
Ia.rger dimensions than 3 is possible. For dimension 5 we used basis

{.^,r2, N/ (ox ), f' (* x ), r x f2 (r x), (n x)2 f2 @ x ))


MAT A BSI-1-6c_3.pdf, Blatt 245

0240

Factoring RSA keys from certified smart cards: Coppersmith in the wild

wlrich up to LLL constants handles X < Nr/s, i.e. up to 204 erroneous bottorn bits in p for N of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
making it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe00O. . .f (251'+2510+250e+ 15; appeared as a common factor after taking GCDs but
was not be found by the lattice attacks described in this section starting frorn the basic patterns
described in Section 4. Coppersmith's attack also works to search for errors in higher bits ofp by
defining the polynomial / as f (") : a + 2tr. Here t is the offset location of the errors we hope to
learn and the same method wilt find errors of the form 2tr withr < X.
However, since we hypothesize that the prime factors are generated by incrementing to the next
prime afüer a sequence of bits output by the flawed RNG, we do not know the least significant bits
of a because they are modified in the prime generation process. This problem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for rnore strings a: For each of the 164 basic patterns include all 2*-7
variations of the bottom rn bits with the LSB fixed to 1. This will find factors if finding the next
prime from the base string did not require more than those bottom rn bits to change.
A brief analysis suggests that for this attack to have a 50% chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prime is approximately lllnz. See [7] for an overview and more precise statements.
In our case of primes around 2512, each number has about a L1355 chance of being prime. Since
1 - (i - LlZSSlzsa:0.514290, ürying 128 patterns for the bottorn eight bits for odd paüterns has
a 50%o chance of covering a sufficiently large interval to find a prime. For our implementation this
computation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be found with this search but the method presented in the following section is more
efficient at handling errors in top and bottom positions unless a very large portion of the top bits

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring in the least significant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most significant bits of one of the factors,
without resorting to brute-forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of lü has the form
p: a+2tslr
where o is a 512-bit integer with a predictable bit pattern (as described in Section 4), t is a bit
offset where a sequence of bit errors s deviating from the predictable pattern in a occurred during
key generation, and r is an error at the least significant bits to account for the implementation
incrementing to the next prime.
To apply Coppersmith's method, we can define an equation f (*,a) : a*2tr1-A and try to use
Iattice basis reduction to find new polynomials Q1(r,g) with the property that if /(s,r) vanishes
modulo a large unknown divisor p of I/ and s and r are reasonably small, then Qi(s,r) :0 over
the integers. In that case, we can attempt to find appropriate zeros of Qt. The most comrnon
rnethod to do this is to look at multiple distinct polynomials Q.; and hope that their common
solution set is not too large.
These types of bivariate Coppersmith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's attack againsi RSA private key d < N0'2e [3]. Our ap-
proach is very similar to that described by Herrmann and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 246

02 41

10 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

bits known [9], although for the application we describe here, we are less interested in optimal
parameters, and more in speed: we wish to find the keys most likely to be factored using very low
dimensional lattices.

Algebrai,c independence: Nearly all applications of multivariate Coppersmith methods require a


heuristic assumption that the attacker can obtain two (or several) algebraically independent poly-
nomial equations deterrnined by the short vectors in a Lll-reduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of common solutions. Most theorem statements in
these papers include this heuristic assumption of algebraic independence as a matter of course,
and note briefly (if at all) that it appears to be backed up experimentally.
Notably, in our experiments, this assumption did noC hold in general. That is, most of the
time the equations we obtained after lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because all of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
vanish at the desired solution, but without further information, there are an infinite number of
additional soiutions that we could not rule out. However, we were often able to find the solution
using a simple method that we describe below.
Herrmann and May [9] describe one case where the assumption of algebraic independence did
not hold in their experiments, namely when X and Y were significantly larger than the values of
s and r. Similar to our case they observed that the polynomials of small norm shared a common
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our case does vanish over the integers at (s,r) while / vanishes only modulop.
We experimented with running smaller dimensional lattice attacks in order to generate this
sublattice more directly. The attack worked with smaller degree equations than theoretically re-
quired to obtain a result, but when we experimented with lattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a useful linear equation
in the sublattice insüead of the useless factor /.

6.1 Implementation details

Latti,ce construction: Our lattice is constructed using polynomial multiples of / and .lü up to
degree /c vanishing to degree 1 modulp p. Let X and Y be bounds on the size of the roots at r
and 3r we wish to find. Our lattice basis consists of the coefficient vectorö of the set of polynomials

{rü, rXl{, f , (r X)2 N, (* x) f ,.. ., (sy)o-' (r X) !, (yY )k-1 f ),


using coefficients of the monomials { 1, z, A,r2,. .. ,Ak-! n,ge}. the deterrninant of this lattice is

det.L : pt+t 176f ;(&1").


and the dimension ir (ul') .Omitting the approximation factor of LLL, we want to ensure that

(dei L)L/ ai^t . O


(rt')
(l*,t+rxr(-ä'))'' < Nvz

So for .l{ x 2t024, setting k : 3 should let us find XY < 2102 un6 k : 4 should let us find
XY < 2128. The parameter choice k : 2 results in a theoretical bound XY < 1, but we also
experimented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 247

4242_

Factoring RSA keys from certified smart cards: Coppersmith in the wild 11

Solu'ing for solut'ions: After running LLL on our lattice, we needed to solve the systera of equations
it generated over the integers to find our desired roots. The usual method of doing this in bivariate
Coppersrnith applications is to hope that the two shortest vectors in the reduced basis correspond
to algebraically independent polynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in nearly all of our experiments, this condition did not hold, and thus
there were an inflnite number of possible solutions.
However, a simple method sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose because the short vectors in the reduced basis corresponded to
a sublattice of multiples of the same degree-one equation, with seemingly random coefficients,
which vanished at the desired roots. (The coefficient vectors were linearly independent, but the
underlying polynomials were not algebraical.ly independent.) The other polynomial factors of these
short polynomials did not vanish at these roots. This linear equation has an infinite number of
solutions, but in our experiments our desired roots corresponded to tire smallest integer solution,
which we could obtain by rounding.
Let
ur*aY-w:0
be an equatiou we want to solve for o and g.lf u and o are relatively prime, then we can write
clu + c2u: 1, and parametrize an integer family of solutions

r:cru+uz
A: c2w - uz
withz:czfi-ctA.
In experiments with the already-factored moduli, we observed that the solution was often the
minirnum integer value of fr or A alnong the solution family. So we searched for z arnoug the
rounded values of -c1wf u and c2wf u.
For the handful of cases where the lattice did resuit in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6,2 Experimental results


We ran our experiments using Sage 5.8 parallelized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, and.Singular to factor polynomials and
compute Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear factors and looking for small solutions of the linear equations
as described above or using Gröbner bases.
We attempted to factor each of the 2,086,171 1024-bit moduli using several different parameter
settings. For k : 3, we had 10-dimensional lattices, aud attempted to factor each modulus with
the base pattern a:0 using Y :230, X :27o, and t: 442.We then experimented with k:4
Y : 228 and X - 2too, which gave us 15-dirnensional lattices, and experimented with a base
pattern a : 2517 + 2510 and five different error offsets: t : 0 with y - 2128 and X : 1, and
t:128,t:228,t:328, and t:428 with Y:2za and X :2700. Finally, we experimented with
thechoicele:2,X:4,Y:4andthechoicesoftandausedinthek:4experiments,which
used 6-dimensional lattices and theoretically should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice & : 1 with
the same parameter choices as & :2 did not produce results.

6.3 Handling more errors


Flom these experimental settings, it seems tikely that many more keys could be factored by different
choices of parameters and initial pattern values; one is limited merely by time and computational
resources. We experimented with iterating over all patterns, but the computation quickly becomes
very expensive.
MAT A BSI-1-6c_3.pdf, Blatt 248

0243

12 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

k logr(XY) ff t ff fastorcd keys f alg. indep. eqns. running time


245105 3 4.3 hours
31001 t12 - 2 hours
4 r28 5 109 4 20 hours
Table 1. Erperi-e pproach, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all of the other cases were solved via the heuristic
methods described above.

Patternedfacrlors: Mysteriously, usir.rg the base patterns a:0 and a:257r t25'0, the algorithrn
produced factorizations of keys with other patterned factorizations. This is because the product
of the bit pattern of the relevant factor multiplied with a small factor produced an integer of the
forrn we searched for, but we are as yet unable to characterize this behavior in generai.

Higher powers o/p; Sirnilar to the univariate case we can construct higher-dimensional lattices in
which each vector is divisible by higher powers of p, e.g. using multiples of .l{2,Iü/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of XY only for
lattices of dimension at least 28.

More uariable.s.' More isolated errors can be handled by writing p : a*Df:r 2t'st with appropriate
bounds on the si I Xi so that the intervals do not overlap. The asymptotically optimal case is
described in [9] and reaches similar bounds for lli:, & as in the univariate and bivariate case.
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottom bits to generate a prime, the condition (det,L)di't/r < p holds
only for lattices of dimension at least 35 at which poinL X1X2Xy 1 Nl/r+ can be found. A lattice
of dimension 20 leads to the condition X1X2Xa < 1. A sufficiently motivated attacker can run
LLL on iattices of these dimensions but we decided that factors found thus far were sufficient to
prove our point that the smart eards are fatally flawed.

7 Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the systern for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each of the affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they informed us that they were not issued new
cards.
Several of the more recently factored keys described in this paper are still valid. This means
that MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart cards.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
longer responds to our queries. However, it is still possible to download Citizen Digital Certificates
from MOICA through a web-based interface under "Query of Certiflcation" of "Certificate Ser-
vices" on hitp://moica.nat.gov.tw/html/en/index.htm. Interestingly, the Chinese version of the
web interface requires much less information to query a certificate than the English version.
We emphasize that the random-number generators used in these cards obviously do not rneet
even minimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problerns until all of the cards are replaced.

References
1. ANSI. ANSI X9.31:1998: Di.gital Si,gnatures Using Reuersible Public Key Cryptographg for the Finan-
cial Ser"ui,ces Industry (rDSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 249

4244

Fartoring RSA keys from certified smart cards: Coppersmith in the wild 13

2. Daniel J. Bernstein. How to find the smooth parts of integers, May 2004.
http: I I cr.yp.to/papers.htmlfsmoothparts.
3. Dan Boneh and Glenn Durfee. Cryptanalysis of RSA with private key d less 17rn n0'292.In Jacques
Stern, editor, EUROCRYPT,volume 1592 of Lecture Notes in Computer Science, pages 1-11. Springer,
1999.
4. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. J.
Cryptologg, 10(4) :233-260, 1997.
5. Don Coppersmith. Finding a small root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, editor, EUROCRYPT, volume 1070 of Lecture Notes'in Cornputer Science,pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Informationstechnik. Evaluation ofrandom number generators, 2013.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-number-gener
and https://www.bsi.bund.delDElThemenf ZertifizierungundAnerkennrngf ZertifrzierungnachCCundlTSEC/Anwendungshin'
7. Andrew Granville. Harald Cram6r and the distribution of prime numbers. Scand. Actuari,al J.,
1995(1):12-28, 1995.
8. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. In Proceed.,ings of the 21st USENIX Securi,ty
Symposium, August 2012.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYP?, volume 5350 of Lecture Notes in Computer Science,
pages 406-424. Springer, 2008.
10. Nick Howgrave-Graham. Approximate integer common divisors. In Joseph H. Silverman, editor,
CaLC, volume 2146 of Lecture Notes'i,n Computer Science, pages 51-66. Springer, 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh Safavi-Naini and Ran Canetti, editors, CRYPTO,
volume 7417 of Lecture Notes in Computer Science, pages 626-642. Springer, 2012.
12. Arjen K. Lenstra, Hendrik W. Lenstra jun., and L6szl6Lovdsz. Factoring polynomiais with rational
coefficients. Math. Ann., 261:515-534, 1982.
i3. MOICA. Safety questions, 2013. http://moica.nat.gov.tw/html/etT2/faq22-066-090.htm.
14. National Institute of Standards and Technology (NIST). Security requirements for crypto-
graphic modules. Federal Information Processing Standards Publication (FIPS PUB) 140-
2, May 2001. http://csrc.nist.gov/publications/fips/fipsl4}-2/fipsl402.pdf, updated 2002-12-03.
See http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf for differences between this and
FIPS-140-1.
15. National lnstitute of Standards and Technology (NIST). Recommendation for random number gen-
eration using deterministic random bit generators. NIST Special Publication (NIST SP) 800-90A,
January 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime was found.
46, 0xc000000000000000000O0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002f9
7, 0xc92424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424es
7, 0xc00000000000O0000000000000000000000000000000000000000000000000000000O000000000000000000000000000000000000000000000000000000101ff
6, O\d24949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949d7
A oxf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbc 1
4,
4,

0xe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f
0xfSad5ad6d6b56b5aSad6ad6b6b5ab5adadobd6bSbsad5ad6d6b56b5a5ad6ad6b6b5abSadad6bd6b5bSadSad6d6b56b5a5ad6ad6b6bSabsadad6bd6bSbSadsd39
0xc28550a128500a14850aa14250a1 14280a744285a14228501428850a428550a128500a14850aa14250a1 14280a744285a7422850142885Oa428550a128500a6f
2, oxfdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbd€bdefefTbfTbdbdefdefTfTbdTbdedefT6iTbTbdebdefefTbfTbdbdefe0bl
2, 0xd2494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992484a0f
, 0xe94a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a529294a94aSa529529494a54a525294294a4a52a529294b9af5
0xdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbOddb6d7015
0xca52a529294a94aSa529529494a54a525294294a4a52a529294a94aSa529529494a54a525294294d4a52a529294a94a5a529529494a54a525294294a4a52a601
0xc0000000O0000000000000000000O00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002030b
0xd8c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c0c631631818c68c636318318c8c63c631318c18c6c631631818c69107
2, 0xf 18c 18c6c63 1 63 1818c68c6363 183 18c8c63c631318c 1 8c6c63 1 631818c68c6363 183 18c8c63c63 1 3 18c 18c6c63 1631818c68c6363 183 1 8cBc63 c63 13 18c 1907
2, 0xfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdeiefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdS2S9
0xc421421010840A42427O27OAOA42A42L2|081084842742707OA4O842421021080842842121081084842142101084084242102108084284212108108484214369
MAT A BSI-1-6c_3.pdf, Blatt 250

0245

14 D J Bernstein, Y-A Chang, C-M Cheng, L.P Chou, N Heninger, T Lange, N van Someren

2, 0xefTbfTbdbdefdefTtTbdTbdedefTefTbTbdebdefetTbfTbdbdefdefTfTbdTbdedefTelTbTbdebdefefZbfTbdbdefd€f7f7bd7bdedef7ef7b7bdebdefet7bf969
1,0xd4e682e94f1d6018a02056c0db850a74b3591b0f840514c€4017b2f5d25925ba2429a66e384bSb€96e6a0a03d4a11€ba10416018de3b3e354477250037b6f813
1 , 0xcac05be5c1eabf0c21f8egSceSd3c07779O42A2d1fd0c1738d727e197a0a32fda4cc59cc50b99d29f7ra8d07c972402ab88573e255db6bab05505812c73c2911
1 , 0xcf052499061243cd82cd1b20s9446c963487834d929ac929d92b25924s254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4d144e242dbd
7 , oxta94a972e2dcff068ee1257€228b53e9b9fcf46877f07daaa4d13c2bedf132d07730f549f4691f68553f84be8rf405f16a663d8fb8f82987bd9e073a8108edc3
1 , 0xefTbefbdbdef9ef6fTbdTbdegetTefTbTbddgdcfefTb3TbdgfeddefTbTbdTbdedEe6ef3bSbde3d€7ed7bfa99adebdefZb7bd77d7cff 1e€7b7bdebd€6€f79f8ab
1, Oxeeb2919e1dc9ce33c2a0d9e190465b164a53c7c03e9a3d009ecf8fd6bdf743e04444332b7ff4a0e8l53b5123a5422563a06a487cd6cb5f36cd5411f0ae4dbc69
1,0xf51576e530188d5gbbc5f4f6ec9e824d7a9e7OL42952b11c49a6f38188ad9dbe3d29d1d9498b7aeffc4d9b0420f71895f62e2a7b79d4887e45b6227eob84tb97
1,0xd83f22a49af67d7f196dt580d514464d6dbb88ob03bea50ddcc1f931ef7f09af,2f880de26d88cbf24567302a0d6eed7c8eab859aa0c1cc18bd8€facdce194c13
1 , Oxc1df3eBdb5f7b7f466edc1f6Od23f6O36O536565836ce37af6fO2e55de24a8dc373f3c5d49c93ba6teeOd44d08bc5fb0655781ade€5c05777fd4da2bcd803dof
L , Oxe279872638463a0a32a1412b13efccfa5ed68db44963c7f6955a3816bcaa33f94794c8b75298ddf4a8664e485ef99e6d9469f5187939e395cb1f09e666786741
1 , Oxce73e73939ce9ce7e738739cgce7ce73739c39cece73e73939c€9ce7e739739c9ce7ce73739c39cece73e73939ce9ce7e739739cgce7ce73?39c39cece73ead7
1 , 0xd92ae5c6453efec55c6614207827de2b77bf3ef027f4230fBaac1fdgb0d69fdc61934132766fBdd1d8cb22ec38d834037eff6d9dd3535b9e582fbdd2327c9ces
1, 0xc080000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000001003t
1, OxfffTfffffeffffffffffffffffflllleTf.tfftfTfffftfftJffffffffffffdTffffffbffffffTbfffbfcftttTttftlttttbto0000000000000000000o00000cl
1,0xeb6f80ff65b4a6d462cfa5961f542125e2O7667752b0482fSac9dc091f4dc854de9c73b288aaasda6298a33928f7b2920f89b81e3635932bc9dbg9a34e52b82b
1, OxfdfTbgbffbffdebeb2ESg2bT6f6gbbffbffd.afaoffdgfTbdfl€e7bfa6e2f33bb67d5a5b5676d2bf6a1de3626fo6be367fide73db1eO1f5d3855f21fOeda8b4db
1,0xe643203b22b4O48427270bd390d45a3a62ac132c0063990067686123d50128812e09411f27098400c841e09183400431018100a2b1cc0954c0405026420E8c7f
l,oxffefefTftde6tttlTftf.ttbttfffffbffeffbffdfffflfllfffffffffftfffffffffffffflfcffffef46tfrdrdiftTfffftltffffffffffffffe€f,efeceffeSd
1 , Oxf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66b37b6dbo19a4697
1 , 0xc000b80000000000000000000000O000000000000000000000000000000000000000068000000000000000000000000000000000000000000000000000000251
1,0xcccSebfea2f4beb8b62dfef5429f97f06af0af8d08159d21df4540a0197ffdb8386cBebb18bd70b0f46c9616d2fcd0ea38a2cadb522ct7912c3ab27d9564a197
1 , 0x€db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dadb6d9b6fOdb66da6b6lbf6cb9bZddb656d9e6d36a7dbb673ba6ddb6f6db66df6b566
1,0x€7fa15ab6c3d2c3d13960f598cd2bbt74a688580eSfdc70064563a10658f1dfd36d5eBaec88897c79d73ebdcbec1bsf0121175c8aae69e3a31a63f9e66eobfc5
1,0xffb308867fee16267feb2b1af2t2fiet!1l.f.a4308866tffSfff€fe13ffcf869af,f4bf907ff1f9393fft0Jff3fffcfff7ff3ef703ffaa8c7ffffe491affeff3b1
1, 0xc010208a48c1802121081084842142307Oa4O84242006309ca468d2123081084a520431000c40a425210210a084a8ce1290810cc84204a9011ac2842407022a7
!, 0xe739729c9ce7ce73539c29c€c126e7383b8e8gbd2207taed,8428421318c1084c410631858c68c63e31035cc8c63ce31318810c64331231818c60e63623b32a3
1, 0xfeb1b9efa29f64ed53628a10a924b5268163dd887f653a6b82edb063b6874c2039e4938018abg49a4c28cdc785fe2be58872c0c8a9ec5171e37ea6a82d5d46d7
1, 0xc0100000O000000000000000000090O0004260400c00000000001800000000004020800000000020200001080000000000000000000000O0000280O0000002f3
1, 0xf9d5834f918b673e1f7eaa63ccSd97dd2706dd8de9cSb2fbef679b2c196933fe30f62ac3f7icc1c593fb63a0bbb8838b8486eac959cc3949ea9182c46396fbcb
1,0xdac45d37aadacfec73b3184ef43d62d6314754abd3841Adde03ade396bd809aa2811047f015c9c71f0cbboa91028190adEacc36165b060e6fce64549f947e0d5
1, Oxt49808773746a41a331625a7cb389611eaa3905984245t99ei2gil7f867413cfae91230478715024db5€ad44bEb20fbc73a23a27Ld627aL!747b5823f753eb03
1,0xd67a7b111c0401971f57806a2be12a174b8923fd3972ec64f€3de3ee96594a14207831d12f16t545861cad6356bb16221bee68eb2f€€9427e0da0ca5f98e5861
1,oxe83071df5288c373asbc43fb20309e25e99fd85b61a9a4e6f3f71511b98f7ec870471b32520d94cd7753dbe173304445ca648231f601dd19d:!cd40c74190c71d
1 , 0xed4294bSa629529c94250ad353942!4a4a52a569a94a94aSe56b52948c474a52629429524a5aa529294a9ca5e1295294d4a74a727394696a4a73a529236a968d
1, Oxd621ab6€5ab7992c6efba5f34a7b7b28O26fc93138998c113831dbaaaca1a15738a7b7a9d191bcd77955b92b75263ad9f6bbd4ceOb4qdca1efd5f3e24b3a2889
1, Oxdga43tfO58df6b8d55O85O28eac413a7439e1dc89e5d6e8bSde09e7bc7483d762788rf9e36527ff67c3936OcfcOd2a75986b7fb35614O27cffbg32€€1112eegd
I , Oxe492924992494924492524922492924992494924492424922492924992494924492424922492924992494925492424922492924992494925492524922492938f
1 , 0rf9cf9b29d767€db655b2f6bf964bce697f662fb669b322eb63dfrb6e7a6c69bb798396d284d85169883d42a6Ec96b292761d6dcd7ab596b2adoa9aSd7697f,e41
1 , 0xfffefffeffffffffftfEfffelffEftfetffff,ffefffffffefffefffeffffflfffffefffeftfefff€tffefff€fffftfff00000000000000000000000000000obd
1 , 0xf9ce9ce7e738738cgce7ceT37 39cb9cece73€738398e9ce7e719739cgce7ce7373dc39cece73e53839ce9ce7eZb9739c9ce7ce73739c39c€ce73e73839c€9d63
1,0xd53bd2f169ab7fb38abb7t05cb1550e200914674b65ce176O01ffeb29dbd1e90c21a77e28c6dbfd6E6a782baaba532€2a98effged8e924986af702c48504d0d1
1 , 0xc36e8f2addb602d9d18b2b040bc7a00bc7046b2030c2dgE91c4c161ed562a31d2d056af c759O42a46c28e218€2567c7882fb1cb2d66039ed961daceSea69c5d7
1,oxed15cb0rde7567b278et2422ee01ed658173594b0bcb71594a18df455fc75ca7cSbs2gbb6b9ec229be6ba977773aca977aco8a1e9f557adf079ab8bceb2bc01b
1, 0xd00b0dd78fd35c88db31806803799deab89b8b36c39dc0321674801fb936f90e2920f3dd65400ddc00be90ebcEfdd62d5c5c062c200bdb04aa6a5acf697e2a0d
1,0xd0054c94020831e800450e05811840282088a906825002d9a0c340938dc0b20628072f800334102c08010309c020800710200c04a604083700aa440088411987
0xc7592d7dc9ee1031dcd3d30f43028858305ac46ac981cafa164a8000a9c6e€b698181505242acgdfee9e51c92460b987dbc8161def71863d35ac18fa1235a903
OxfffbfcfTfTffdJ3dfJfefSffffffbfffff9ffffffffdffTdfflfff9ffffffefTdffffffffbffldffleffbffrffll.tttttfl7Tttldfffffffffff liffffffff3S
0xf5eb05d73ad4df3cdaf4td2eaf41eOe406952b7a327479147fffa33Eb829039e77ff1 16t9E4958a3f604743ed2c55ba67b4763184290sdbc2f12c66fb6c4e40f
0xc3ff4d30474f40df0€Tffffdfa92ffff 11d59d35d214ffff85c357c5c85ed72acaf 1rb7d43J76d85ee6b4fb3ffdd60d50966f1l290df4ff888€7€37efe4f9e8f
0xcc7b18295347824ccb395bed35t993c598c7cf7f4632dcb9ab7a5d7oobaa7626d1b8dc651b34f5e4fSd3f253Ob52fbgbd10e76259b36d774f059141bfgedEg1 1
ore675a7059b1e6df20198f8a75a0ab2a723ttf79a67t59c7049fd37d48128f3b3a9b69475b902f4bc854ca1deecbce73cdab89b17a€3c6401a9d43594776a926b
0xef7b77bd3defdef7f7b47bdedef,76t7b7bdebdefef7bf7bdbd€e76f7b73d7b9edef7ef7b7b9e3deeef7bf7b9Hefd6ffffb97bdedef7et7b7b9ebdafef3bf845
0xfd23b1 10962000d598488c43407369898cd0086df780826dcfa14784f38388874362851b77 11dc13564441351335c71fbd7c564dSd50O8f5de20d43t2476d775
oxe918f165879091 1a71a9ae1895cfe56dbEd767816e337e2f950462affb3280d8a8dcb1240620ecBf 1d19c3750afcfe295c58cca117b36632414cd9e114fdbo97
oxffffaaS5ffifffffff3cdgfe3ffff6T6fffffffffff€00O0000000000O000O000000000000000000000000000000000000O0000000000000000000000000009d
0xc021000048041000001000100080O1cs2O64OO4242c812186250154c00000088ba78008a43a9713bc0abb849220e8362cc838b53cf88fcdbdd7tca83c8dr8145
0x€318318c8c63c631318c 318c1ac6c631631818c68c636318319c8c63c631318c18c6c631631818c68c63631831d3
0xd501973162d4017f4e3b3c9d6803d4cc46a1d457c91feb5b0c2ae77423ba41c9cfbdsf4b9235667874507e9cafb4123e1992d1c5aE75ee29508701 !a822a6cct
0x828ecce1de7a0326423076465160c 1b03f8e721181e046ef4860a694d7802a082f9f6007c0011f20066d€200677aa7d8a471 18e6692ee4b3f862c24e04b543b6
0xda2f36d74bc2dc29de4de92f4b37b03942173e15a2dfb67eBf09e790Ed1656af5aBaadef 14b696426f1e929699daoee3ad9f21a9f66€de57d945fc165b27d277
0xd28550a4a8620a1c850aa14260a114ba0a144285a14228501428850a428550e128400a14860aa14250a1 1408Oa144285a7422B51 1428852a4685doa128500a2d
oxe79082499b094b2459266493608a9249b24rod34o9242692a490824d934941254935265a341086119449d824697s24922697926bb24949O44O27LO8a8c939a5d
OxedfcaT3fTS3ffbfffTfefed3fftafffefffdSfifffdefffSffdftll3ffSffffef€fd3fefTfbfSdfff6l3bbSgfgfbSfEbds2aEfdTSebddfe6edeeffeSf3lb3df6
0xfffTlfb6fbfff€fffffffe€frf,feEfffefTfffebfff€ffffffff€tff9fffffcbldbff0faffifdflfTfT€dffeeTadfffafffbfbTeffffdffd€7fadfdef63e806b
0xcaf67d473c10f4e73d6678d4a27e4eb04a743925d12c31f976fa510ca68558b2c56d839acecbe75€935f86cec7dae7c95aaob93065a3aag24594fdfb9f521535
0xf6b43e3bd52847756d1a27r22a8590a8a1 c43c1c36b95cc72d0102t26b6da1b238236856J7c6e6faa83cc70e84f2db44088487fd94a175122a0d990cc1afea6b
Oxd2a2Od1b986ale2152bgd93cr6Obf98f68e9f9€OSOfeUgaZOtOOOeSacSSlf 17a82f35a78d23fb34fab3962ae95bcf3a1e442ebsb1d72cal6956fa599483ee€38c1
0xe52e529494a54a535294294a4a51a509294a96a8a529529494a54a52529d29aa4a52a522298a94a5a522529494a44a525294294a4842a52e294at4a5a52f554b
0xc942c4644b1L69461581e0713ba400570237a55c9ae69e3fe58d189aa751d218208421934f2132a888e796bc1f0914a8c9b4f 116358cca22c69c35596bd961e5
0xed7t7€78af c7d3735fc1dfb0d13887cddcd715c9fe530530e0elceaa4bcaffbaebac9e601623db36fftef47fffff€fffffff00000000000000000000000003ed
0xf6dbgb6dda6d29b61dfe73dbba5bdb6ddsad69be€df6a6dbf7dadb6ddf6c6cb66db6f6d3b6db9b64997c6dbe6cb4364b96dbdb6ddb6c67b€6da4b7cbaedadf35
0xc080a100000000000000000000000000O000000000000000003008000880000002608020010120004408001004202080000800000050000000100000000900e1
0xe5335f76a97cSe29d4557 170cd9ef3ed53€fc819fda87a566aSefe247ef102b85c7adg0c484ade030c7ebc23455e0dcbca2cec6afdf0e8c978cb6fbed5733fa5
0xc0000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000400000000000000000000000000000165
Orc924249324929249b2cf49244924649264927a4A92494936593320b93f 9292a992497dL449242492229293499249492449262493248e96fff3c9104432f4cdbb
Oxc9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
0xc0000000O000O000000000000000O00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000O177
0xc00000041002400005080008021000049000000100000002080000000001021005180000000000000000210080600040082000400000183001000000200020f1
0xcadoca7166b2aaf6c82b0eadfeb13409da7c2679517d4fd96t89719659133e0492d209da600753dcSc2570ce128cf985332f944143204b706bf6€990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 251

4246

Factoring RSA keys from certified smaxt caxds: Coppersmith in the wild 15

1 , Oxe739739c9c€7ce73739c39cece73e73939c€9c07e739739c9c€7c€73739c39ceca73e73939ce9cE76739739cgce7ce73739c39cece73e73939cegce7€73973dJ
7 , 0xe0929249924949244924249a249292499249492449242493249292499a494924493424922492924992494924492424922492b249924949244924249224829261
1, 0xcOoO1ooOOOOOOOOOoooooOOooOOOOOOOOOOOOOO0OOOooOOoOOOOOOOOOOOOOOOOOOOroo8o2OOOcboO4o908809180008c8000000010c00012101b20000000002ad
1, 0xcec727009€t07418dc89e2c96e796d44bc2244d88a0bbec890b4d661736b486b0e1d8352822a4697cddo7 02a3d8b7c4b23ada2286a2al.09234aT 1346ba141795
1 , 0xc8dce72c0638ecaf,2e3e11a€f07326e3431a92ad87ef296d3dob5d4bgd00646bebd7b3afOcge424e074e7486d186d26997a4d9c131acb524881aecace287c057
1, OxeeO9fObE62O1,4c7299e188527ab8cdo048O9c631t1fd5Oa2OO13331678ccad20631879842b8a122569€b18c4b1ddSe4b1lbce7a14f4ae76973debf4ca768c4bd
1 , oxd66cdae6f27sbfd3d1ee6sdf43Odd7aeO16bdos9a5e4389067836o2a2aofb7O27O3d6c3fd50d5917fgba77aeb851c016d26136d754c114aau303d091500462bd
1 , Oxfa147€a68cddaaab66dfa04ff891009db3lf37€1272d573b7a3da6334124f95721da7f.t41!63a72492a0edffa9140001aae21fEa64fd330f93e819a968acafb7
1, Oxf718c0bc8c57cc318c99fa15236191a631828a95856d6ac833a7ega211Odded25226ea4344cabbb2fe19de14863bBc46e31b44038c87s8ce4aea42a10afabt91
1,0xd86d99e183ba3c0870238db37t1d3f673cd€c3112196acfaa1239657bcb3a3a7f6749f3229f650d5097510e5a5df0626a641e2112112f95080c5629973b1c975
1, Oxfc1rc956e7482142bccb7fObc5cd674ad82€dca61fe2663c78622€€673485cc11c993aa€€b15f77dgodfe1c6a9456239ab47eSca3eb2äeb702f2d€36626858db
7, 0xr7c6br2]-8t ctadcba926acEefdf60f97a€ba8d5f70ceb27eff0fSd67e763bfe86dc7a86€E76b8bt9d076bf1a8f4a7fcfb0297a96c6c5a70oa7e5€3c38326ff83
1, 0rc594391a868c24c8a7fe977d78db784d43c96ba3384f02ac17Lic2606736c65f7c44ef6c3bbf7b05659b954c6b9ce96f648c900b56cSf3ca01e47384ad4de577
1,0xdag75410693d312Ob32997c8c728f09d09610f6fef089a7ct63tt1dcf673ftffb493c19c64167e0457646aaba4f3409f9648ft7c390c25d4a8a3d7c9b2f16b2d
1,0xf16f€ad9af03cfcb36571b8b3lE3ct24€313aece858b7d4E800838329c9b729ecc6d691df4ee8547a9fdU18debbca33Bal8214fa1€03ad53f863a0503btb6736
1 , oxddfgbs6a7bb566afa1476addbs4aag5e669c94ab62d5fa95c064af04bSa3b56adff55e2dbb466ed1b56aadsa1629c5a93adssbf5ad1eAba4€5ab9722dafSd7bd
1,0xd9958fe30334b89cAc02ac210c4dcBeOe610d1c958cb4d436e11aed€0f72e3b8a88e18b7c663533218c68ed560b031ad4ce38aa13bbc10b6c73t€3911accBde1
1,oxfcb0663ef5€3c922936834039fd787aode9fddl78017021129c1b592570fd3c5s60787tc59128bce5bfcb38be0c064b08c087fd8fe6b960207c93ca4cf3cSadd
MAT A BSI-1-6c_3.pdf, Blatt 252

02 47

16 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

B Appendix: FIPS-140 certifcation


Searching for the term UFIPS" on MOICA's website (http://moica.nat.gov.tw/html/en/index.htm)
returns the following entries in the FAQ section, all of which claim some security through FIPS
certification.

1ffi
mkrnat.gwär.' ,., i.. a{: ä

o Crttflcetr Auttndty o,t rcl

rA lt it to ßtrkay date üoü IC cild A pri\'*e


,key praDerq i5 (re.lred in Clypto8taphit i\'loddes rihitt ir uritizcr
lüre RSA aud rmdon gefla'afor A private key is rsed lo uean.
FAQ jprotect, rud store iri HSfvl. Besides, 'l'he lC" ratl ar<ordaare rvidr
IFIPS l{0" I levrl 2 certifiah}e by [C rud narugemeut r:erra ud de
ica'd possess higfr secur(y. A privare key is (reated i[side ild *le
ülllare !e]l iillllxpol1toq IC rqd !g" .tg!g{
{g
:!t:It's hilü risL to srfle cerüficate i! üo Bopp!' dist üd (a oddD!,
;roFy d ey tine. Th€ cifzen ögtal cerüficate pas FIPB ld&l
;ar*hori$ level 2 ard have hlg! reoritg. Prvce key cu t be cqry
F.IQ
ifiou IC cad afier gpneiile L?y pair ot ir»ide rlre tC cad. Ihir
lcerificarc level is X 509 L3 lte policl of citirri ditital .Brürcile
&s :s$err :!g-43 l99d"rq1l! -ca! -
i-A:Accordiilg(o CPS of MOICA, the lC cild i5 higb 5«uiry sd i(
FAQ jhave bcea accedited to Fm 140-l lal'el. 2 ad irs crd ua is ued
iro create,J)rorecl.il-d.191." p H-SÄ4
A:Ihe CA key pairs ue gemated rilhiuhadrvle ol?toeapüit
-
:moduhr or softwrelludwae qyrtogrqrhic ooduler widrin tle IC
rAQ
cxrl. oeetiog rcquiremqrrs oI CPS ad EIPS I ,t0- I lqvsl 2
!g!ti-:i4g:gt-.,19ry41"-1:1{E:g*g[Ic$3. .
:A:The C-A l€J'J ee created in a c4ptographic no&ile, üsir6 RS,\
;algoridrn ad rador mDber gmrata'. crtacd Nithi[ a lrihca r
lnodule, üe private Ley is srored iuside widrout leahagr. Moreover,
rAQ lcqtificde stbsaiber's IC cad is intcrmlly geacro4r*}ffi,M
,l l€vel 2 certificatiou of tln Cad C*ffe . The priv*
'e-y-grt
4a.s.!39t1!q... .
,Ä*liriru ,-igrä" c*ä i" the caric 6ä
"
:car be erily copied od ilre risk ts hig!,
,ardrmication, the cerificerc IC red ir bi$Hri
rAQ
lbeing g,euuated lnterually aftu r*üich
,ereofied tror replicated. Subsdabu'r &rt
lusiuggS$$c-1,e_.ry9lectiorX.S09Y3lgti}-.."

Total6 Palr l,l-- I NGn 20 I I Prrv 20 I


MAT A BSI-1-6c_3.pdf, Blatt 253
tilelll #1

Schvache RSA-Keys

Von: x (BSI Bonn)


02 B
An:
Kopie: , "Kittian, Gereon"

Datum: 30.08,2013 15:33


Anhänge: §)
--" smartf acts. odf

Hat to
zur Zeit wird zwischen Hhl-Prüfstelten und BSI über das folgende Thema
dls kutie rt :

- htto://crvpto.2013. rumo.cr.vo,to/55e2988c4ed3c9f635c9a4c3f52fa0b1.odf
- Paper im Anhang (in Draft-Version, bitte nur intern benutzen)
Auf der Internetseite von IDpendant GmbH findet man, dass diese Firma
elenfalls mit der Ministry of the Interior Certification Authority (MOICA) in
zu tun haben:
Oh,",
htto: //www. idpendant . delloesunoen/eoovernment. html
http: //r^rv,\"r, idpendant . delf ileadmin,/pdf s/2007_04t20M0ICA%20Faltstudie-dt. pdf

Auf der Seite


htto : //www. idoendant . delf ileadmin/pd f s/2009_11 DS_Chioka rte-DE. odf

werden Karten aufgelistet, die wohl a1s MOICA-Karten genutzt werden.

hlirhaben bislang nicht den Eindruck, dass ein von SRC evaluiertes Produkt
betroffen ist ... vielleicht aber haben Sie hierzu dennoch h,eitere
Hinte rg rundinfo rmationen ?

G rüße

Thomas Hesselmann

o
Unfortunately I will be out of the office in the weeks 4l-42, 52-02. During
this time I witl be unabLe to reply to your mait.

Bundesamt für Sicherheit in der Informationstechnik


Dr. Thomas Hessetmann
Referat S22
Godesberger Atlee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefonz +49 (0)228 99 9582 5691


Telefax: +49 (0)228 99 10 9582 5691
E-l4ait: Thomas , Hessetmann@bsi. bund. de
Internet: www. bsi. bund. de
www. bsi - fuer- bueroer. de

F rrr..racts.odr
MAT A BSI-1-6c_3.pdf, Blatt 254

a2 4e

Factoring RSA keys from certified smart cards:


Coppersmith in the wild

Daniel J. Bernsteinl,2, Yun-An Chang3, Chen-Mou Cheng3, Li-Ping Chou4, Nadia Heningers,
Tanja Lange2, and Nicko van Somereno
I Department of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
dj b@cr . yp . to
2 Department of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600MB Eindhoven, the Netherlands
tanj a@hyperellipt ic . org
3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{ghf j dksl, doug}@crypto . tw
a Department of Computer Science and lnformation Engineering
Chinese Culture University, Taipei, Taiwan
randonalg@goai1. com
5 Microsoft Research New England
One Memorial Drive, Cambridge, MA 02142, USA
nadiah@cs . princeton' edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
. nicko@good.con

Abstract. This paper explains how to efficiently factor 183 distinct RSA keys out of more
than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that share primes and that are efficiently factored by a
batch-gcd computation. This is the same type of computation that was used last year by two
independent teams (USENIX Security 2012: Heninger, Durumeric, Wustrow, Halderman;
Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands
of cryptographic keys on the Internet.
The remaining 80 keys do not sha.re primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation failures: first using the shared primes as a springboard
to characterize the failures, and then using Coppersmith-type partiai-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys foünd in
the wild.
Keywords: RSA, smart cards, integer factorization, Coppersmith, Iattices

1 Introduction
In 2003, Taiwan introduced an e-government initiative to provide a national public-key infrastruc-
ture for all citizens. This national certificate service allows citizens to use slnart-card ID cards to
digitally authenticate themselves to government services, such as filing income taxes and modi-
fying car registrations online, as well as to a growing number of non-government services. RSA
keys are generated by the cards, registered with a government authority, and placed into an online
repository of "Citizen Digital Certificates".
Unfortunately, the random-number generators used to generate many of these keys are fatally
flawed, and have generated real certiflcates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 255

0250

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

inspect repeated primes,


batch gcd observe patterns,
generalize

Public-key 103
database secret keys

l2t
secret keys

125
secret keys

L72
secret keys

183
secret keys

Fig. 1. Retrospective summary of the data flow leading to successful factorizations. After successfully
factoring keys using a batch gcd algorithm, we characterized the failures, and used trial division to check
for broader classes ofspecified primes (input on the right) as exact divisors. We then extended the attack
and applied Coppersmith's method to check for the specified primes as approximate divisors.

This paper explains how we have computed the secret keys for 183 different certificates in use by
real people.

l.L Factorization techniques


Bad randomness is not new. Last year two independent research teams 18, 11] exploited bad ran-
domness to find secret keys for tens of thousands of SSL certificates on the Internet, a similar
number of SSH host keys, and a few PGP keys.
Our starting point in this work is the same basic attack used in those papers against poorly
generated RSA keys, namely scanning for pairs of distinct keys that share a common divisor (see
Section 3). The basic gcd attack, applied to the entire database of Citizen Digital Certificates,
shows that 103 keys factor into 119 different primes.
We go beyond this attack in several ways. First, the shared primes provide enough data to
build a model of the prime-generation procedure. It is surprising to see uisible patterns of non-
randomness in the prirnes generated by these smart cards, much more blatant non-randomness
than the SSL key-generation failures identified by [8, 11]. One normally expects smart cards to
be controlled environments with built-in random-number generators, typically certified to meet
various standards and practically guaranteed to avoid such obvious patterns. For comparison, the
SSL keys factored last year were typically keys generated by low-power networked devices such as
MAT A BSI-1-6c_3.pdf, Blatt 256

0251

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers and firewalls running the Linux operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime factors: we hypothesize a particular model
of randomness-generation failures consistent with 18 of the common divisors. The same model is
actually capabie ofgenerating 164 different primes, and testing all ofthose primes using batch trial
division successfully factors further keys. One might also speculate that the cards can generate
primes fitting a somewhat broader model; this speculation turns out to be corect, factoring a few
additional keys and bringing the total to L25. See Section 4 for a description of the patterns in
these primes.
There are also several prime factors that are similar to the 164 patterns but that'contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice-based partial-key-recovery attacks to efficiently find prime
divisors close to the patterns. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottom 40% of the bits of the prime. The bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes them particularly
susceptible to these attacks. These attacks produce dozens of additional factorizations, raising the
total to 183.
In the end nearly half of the keys that we factored did not share any common divisors with other
keys; most of these were factored by the Coppersrnith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersmith-styie attack breaking keys in the wild.

L.2 Certification
The flawed keys were generated by government-issued smart cards that both the certification
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
It is clear from their externally visible behavior, as shown in this paper, that the random-
number generators used to generate the vulnerable keys actually fall far short of these standards..
This demonstrates a failure of the underlying hardware and the card's operating system, both of
which are covered by certification. We have no explanation for the discrepancy.

1.3 Observed response and recommended resPonse


When we reported the commori-divisor vulnerabilities to government authorities, their response
was to revoke exactly the certificates sharing common factors and ask only those users to regenerate
keys. See Section 7 for more details.
Our further factorizations demonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themseives as primes appearing twice, but sometimes
rnanifest themselves as primes that appear only once, such as the primes that we found by
Coppersmith-type attacks. Both cases are vulnerable to attackers with adequate models of the
randomness-generation process, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for common divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much more than an indication that those particular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system, replacing
it with a properly engineered systerrr and to revoke all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the primes generated by these smart cards had been modified to include a card serial number
as their top bits then the keys would have avoided common divisors but the primes would still
have been reasouably predictabie to attackers. Our work illustrates several methods of translating
different types of malfunctioning behavior into concrete vulnerabilities. There a.re many potential
MAT A BSI-1-6c_3.pdf, Blatt 257

0252

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vulnerabilities resultirg from bad randomness; it is irnportant to thoroughly test every cotnponent
of a random-number generator, not merely to look for certain types of extreme failures.

2 Background
2.L The Taiwan Citizen Digital Certificate program
Taiwan's Citizen Digital Certificates (CDCs) are a standard means of authentication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certificate Authority (MOICA), a level I subordi-
nate CA of the Taiwanese governmental PKI. Since the program's launch in 2003, more than 3.5
million CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates form a basis for the Taiwanese governmeut's plan to migrate to electronic
certificates frorn existing paper certificates for a range of applications including national and other
identification cards, driver's licenses, and various professional technician licenses.
Taiwanese citizens can already use the CDC to authenticate themselves to a uumber of govern-
ment agencies over the Internet, in order to file personal income taxes, update car registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Certif,cate registration: In order to generate a CDC, a citizen brings their ID card to a government
registration office. A government official places the (srnart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed by MOICA. The certificate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Standards certificati;ons; MOICA states that these cards are "high security", and "have been
accredited to FIPS 140-1 level 2", ard also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For comparison, the SSL keys factored last year were generated
by software-hardware combinations that had never claimed to be evaluated for cryptographic
security such as Linux running on a home router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID program. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly all, of the problems we have identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS 140-1 level 2 [14]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certificates


In March 2012, inspired by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP directory at ldap://rnoica.nat.gov.tw. Out of these RSA keys, 2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The 1024-bit CDCs contain 2086177 distinct moduli, of which 171366 moduli appear more
than once. The repeated moduli appear to all be due to expired certificates still contained in the
database which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 258

0253

Factoring RSA keys from certified smart cards: Coppersmith in the wild

2.3 Random Number Generation

While generating high-quality random-numbers is critical to the security of cryptographic systems,


it is also notoriously difficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial component of generating rahdom numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, 1,6] specify correct behavior for these types ofsystems. In general, software pseudo-
random number gererators require a significant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any run-time
testing before generating keys, and they clearly do not apply any post-processing to the randomness
stream. The iack of testing or post-processing causes the initial randomness-generation failure to
be rnuch more damaging than it would have been otherwise.

Analog RNG circu,its: An analog circuit is the standard choice when hardware designers have the
luxury of designing dedicated circuits for random-number generation. An analog circuit allows the
designer to obtain randomness from simple quantum effects. While the use of radioactive decay is
rare in commercial products, the quantum noise exhibited by a current through a suitably biased
diode can be amplified and sampled to deliver an entropy source of very high quality.

On-chip RNG ci,rcuits: Mixing analog and digital circuits on the sarne die is costly, so chip designers
often seek other sources ofunpredictability. These sources can include variation in gate propagation
delays or gate metastabiliüy, which exhibit inherent randomness. Designers can explicitly harness
gate-delay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take advantage of randomness in gate metastability, designers
build circuits that output bits based on the time it takes for the circuit to settle to a steady state,
a variable which should be hard to predict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variations, and subtle on-chip effects such
as inductive coupling or charge coupling between components can cause free-running oscillators to
settle into synchronised patterns and metastable circuits to predictably land one way or the other
depending on other components nearby on the chip.

Hand,ling Entropg'Sources.' Even with perfectly unpredictable source of randomness, care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density, test the signal from the entropy source at run
time, and run the output through a compression function such as a cryptographically secure ha§h
function. These practices are required by a number of security standards such as FIPS 140 [14].

3 Batch gcd
This section reviews the approach of [8, 11] for detecting common factors in a collection of RSA
keys, and reports the results of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA moduli Nr : pet and I[2 - pq2 sharing exactly one prime factor
p, then the greatest common divisor of Nt and Nz will be p. Computing this gcd is fast, and
dividing it out of I[ and N2 produces the other factors qr arrd q2'
Of course, this type of vulnerability should never arise for properly generated RSA keys. How-
ever, since [8,11] had observed weak random-number generators producing keys with repeated
factors in the wild, we began by checking whether there were repeated factors among the Citizen
Digital Certiflcates.
MAT A BSI-1-6c_3.pdf, Blatt 259

0254

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

Instead of the naive quadratic-tirne method of doing this computation (checking each l[r
against each N2), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementation available at https:f f factorable.net/resources.html.
We ran this implernentation on the 3L92962 distinct RSA moduli.and found that 103 rnoduli
were factored due to nonirivial common factors. This computation, parallelized across four cores
of a 3.1GHz AMD FX-8120, finished in just 45 minutes.

Attacking patterned factors


A properly functioning random number generator would never generate identical 512-bit primes,
so the discovery of repeated prime factors described in the previous section immediately indicates
that the random-number-generation process producing these keys is broken. This section analyzes
the structure of the repeated factors generated by the flawed random-number generator and designs
a targeted attack against this structure.
The 103 rnoduli with repeated factors show a rernarkable distribution ofthe shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appendix A.
One prime factor, p110, appears a total of 46 tirnes with different second primes. The hexadec-
imal representation of this factor is
c 000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000002f 9

which is the next prime after 2571 a 2510 .


The next most common factor, repeated 7 times, is
c9 24249 2249 29 249 I 249 49 2449 2 42 49 224929 2 499249 49 2449 2424922 49 29 249
9 2 49 49 2449 2 4249 2249 29 249 9249 492 4 4924249 2249 29 2499 249 49 24492 424 e 5

which displays a remarkable periodic structure. The binary representation of this integer, excluding
a few most and least significant bits, is a repeated sequence of the string 001 with a "hiccup" every
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. We hypothesized that nearly every repeated prime factor had been generated using the
following process:

1. Choose a bit pattern of length 1, 3, 5, or 7 biüs, repeat it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the most significant two bits to 11.
4. Find the next prime greater than or equal to this number.

We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and tested divisibility with each modulus. This factored a total of 105 moduli, including
18 previously unfactored moduli, for a total of. l2l.
None of the repeated primes exhibit a (minimal) period of length 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods typically appear
in fewer keys than patterns with shorter periods, and are thus less likely to appear as divisors of
two or more keys, raising the question of whether there are primes with larger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extended
this test to include length-9 periods and length-11 periods. The length-9 periods factored 4 more
keys but the length-l1 periods did not factor any new keys, leading us to speculate that 3, 5, and
7 are the only factors of the period length. We then ran a complete test on all length-15 patterns
but did not find any further factors. The total number of certificates broken by these divisibility
tests, together with the initial batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 260

0255

Fa,ctoring RSA keys from certified sm, Coppersmith in the wild

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime factors dividing the same modulus.

Spomd,i,c eryors: The handful of shared prime factors in our sample of gcd-factored keys that did
nät match the above form were differing from patterns in very few positions. We experimented with
flnding more factors using brute-force search starting from 0xc0. . .0 and found a new factor§, but
these factors a,re more systematically and efficiently found using LLL in Coppersmith's method,
as described in the next section.

5 UnivariateCoppersmith
Several of the factors computed via the GCD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic errors. Coppersmith's
method [5,4] factors RSA moduli if the top bits of the primes a.re known, which matches our
situatiorrif tLe errors appear in the bottom few bits of a factor. This section presents this method
following the variant by Howgrave-Graham [10] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factored'
The idea is as follows: we a§suule that some prime factor p of N is of the form
P= o'+r
MAT A BSI-1-6c_3.pdf, Blatt 261

0256

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lairge, N van Someren

where a is a 512-bit integer known to us (one ofthe bit patterns described in the previous section)
and r is a small integer error to account for a sequence of bit errors (and incrementing to next
prime) among the Ieast significant bits of p.
In the Coppersmith/Howgrave-Graham metirod, we can write a polynomial

l@):a+r
andwewouldliketofindarootrof /moduioalargedivisorof 1[ (of sizeapproximately N1/2 xp).
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new poiynomial g(c) where g(r) :0 over the integers, and thus we can factor g to
discover it.
We construct the lattice 1, as
fxzxaol
lo *0 nl"l
L0
corresponding to the coefficients of the polynomials ly', f(Xx),Xrf(Xr), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of a polynomial g(Xr). Then we compute the roots ri of g(r) and check if a * r.i divides I{. If so,
we have factored ly'.
Any iattice vector is a linear corabination of / and N and is thus divisible by p. A prime p is
found by this method if g(r): 0 mod p holds not only modulo p but over the integers. The latter
is ensured if the coefficients of g are sufficiently small. The shortest vectolu1 found by LLL is of
length
lal < 2@i^r'-t)/a(det L)t/dimr',
which must be smaller than p for the attack to succeed.
In our situation this translates to
Ytz 1Ye N)r/' . *',' <+ X < 2-t/2 Y\/6 ,
so for N - 2Lo24 we can choose X as large as 2170 , meaning that for a fast attack using dimension-
3 lattices up to the bottom third of a prime can deviate from the pattern a. In the following
we ignore the factor 2@inL-t)/4 since all lattices we deal with are of small dimension and the
contribution compared to N is negligible.

5.1 ExperimentalResults
A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this rnethod for one of the 164 patterns identifled in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including all 105 keys derived from the patterns without error, and
found 39 previously unfactored keys.
It is worth noting that ühe 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000...0f. Including 0xd0000...0, 0xe0000...0, 0xf0000...0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation might set the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's rnethod can find prirnes with errors in up to 112 of their bits using lattices of
higher dirnension. Getting close to this bound is prohibitively expensive, but trying somewhat
larger dimensions than 3 is possible. For dimension 5 we used basis

{N2, N f @x),1'btx),rx f2(rx),(rx)2 72(rx)}


MAT A BSI-1-6c_3.pdf, Blatt 262

0 257

Factoring RSA keys from certified smart cards: Coppersmith in the wild

which up to LLL constants handles X < N1/5, i.e. up to 204 erroneous botüom bits inp for Iü of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
making it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe000. . .f (2511 +2510a250e+15) appeared as a common factor after taking GCDs but
was not be found by the lattice attacks described in this section starting from the basic patterns
described in Section 4. Coppersmith's attack also works to search for errors in higher bits of p by
defining the polynomial / as f (") : a + 2t r. Here t is the offset location of the errors we hope to
learn and the same method will find errors of the form 2tr with r 1 X.
However, since we hypothesize that the prime factors are generated by incrementing to the next
prime after a sequence of bits output by the flawed RNG, we do not know the least significant bits
of o because they are modified in the prime generation process. This probiem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for more strings a: For each of the i64 basic patterns include all 2m-1
variations of the bottorn rn bits with the LSB fixed to 1. This will find factors if finding the next
prime frorn the base string did not require more than those bottorn rn bits to change.
A brief analysis suggests that for this attack to have a 50% chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prime is approximately lllnz. See [7] for an overview and more precise statements.
In our case of primes around 2572 , each number has about a 1 /355 chance of being prime. Since
1 - (1 - I/355)256:0.514290, trying 128 patterns for the bottom eight bits for odd patterns has
a 50% chance of covering a sufficiently large interval to find a prime. For our implementation this
computation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be found with this search but the method presented in the following section is more
efficient at handling errors in top and bottom positions unless a very large portion of the top bits
are erroneous.

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring in the least significant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most significant bits of one of the factors,
without resorting to brute-forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of lü has the form

P:a+2tslr
where a is a 512-bit integer with a predictable bit pattern (as described in Section 4), t is a bit
offset where a sequence of bit errors s deviating from the predictable pattern in a occurred during
key generation, änd r is an error at the least significant bits to account for the implementation
incrementing to the next prime.
To apply Coppersmith's method, we can define an equation l@,y) - a+2trlA and try to use
Iattice basis reduction to find new polynomials Q6(r,y) with the property that if /(s,r) vanishes
mödulo a large unknown divisor p of lü and s and r are reasonably small, then Qa(s,r) :0 over
the integers. In that case, we can attempt to find appropriate zeros of Qt. The most common
method to do this is to look at multiple distinct polynomials Q6 and hope that their common
solution set is not too large.
These types of bivariate Coppersrnith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's attack against RSA private key d < N'0'2e [3]. Our ap-
proach is very similar to that described by Herrmann and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 263

0258

10 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

bits known [9], although for the appiication we describe here, we are less interested in optimal
pararneters, and more in speed: we wish to find the keys most likely to be factored using very low
dimensional ]attices.

Algebrai,c independence: Nearly all applications of multivariaüe Coppersmith methods require a


heuristic assumption that the attacker can obtain two (or several) algebraically independent poly-
nomial equations determined by the short vectors in a Lll-reduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of common solutions. Most theorem statements in
these papers include this heuristic assumption of algebraic independence as a matter of course,
and note briefly (if at all) that it appears to be backed up experimentally.
Notably, in our experiments, this assumption d,'id not hold in general. That is, most of the
time the equations we obtained afber lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because all of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
vanish at the desired solution, but without further information, there are an infinite number of
additional solutions that we could not rule out. However, we were ofte.u able üo find the solution
using a simple method that we describe below.
Herrmann and May [9] describe one case where the assumption of algebraic independence did
not hold in their experiments, namely when X and Y were significantly larger than the values of
s and r. Similar to our case lhey observed that the polynomials of small norm shared a common
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our case does vanish over the integers at (s, r) while / vanishes only modulo p.
We experimented with running smaller dimensional lattice attacks in order to generate this
sublattice rnore directly. The attack worked with smaller degree equations than theoretically re-
quired to obtain a result, but when we experimented with lattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a useful linear equation
in the sublattice instead of the useless factor /.

6.1 Implementation details

Lattice constr.ucti.ou Our lattice is constructed using polynomial multiples of / and Iü up to


degree k vanishing to degree 1 modulo p. Let X and Y be bounds on the size of the roots at r
and gr we wish to find. Our lattice basis consists of the coefffrcient vectors of the set of polynomials

{-t[, rXt{, f , (r X)2 N, (* x) f , . . ., @y)o-' (r x) f , (yY )k-t f ),

using coefficients of the monomials {1, r, a,x2,. . . ,Uk-Lfr,gk}. The determinant of this lattice is

det L : 11t+r 176r; ('I').

and the dimension ß (*I') . Omitting the approximation factor of LLL, we want to ensure that

(detLl/ai^r.o
(-j')
(nt+rxr(*t'))'u < Nr/z

So for Iy' Zt0z{,setting k : 3 should let us find XY < 2ro2 arrd k


x : 4 should let us find
XY < 2128. The parameter choice k : 2 results in a theoretical bound XY < 1, but we also
experimented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 264

0259

Factoring RSA keys from certified smart cards: Coppersmith in the wild 11

Soluing for solutions: After running LLL on our lattice, we needed to solve the system ofequations
it generated over the integers to find our desired roots. The usual rnethod ofdoing this in bivariate
Coppersmith applications is to hope that the two shortest vectors in the reduced basis correspond
to algebraically independent polynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in nearly all of our experiments, this condition did not hold, and thus
there were an infinite number of possible solutions.
However, a simple method sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose because the short vectors in the reduced basis corresponded to
a sublattice of multiples of the same degree-one @uation, with seemingly random coefficients,
which vanished at the desired roots. (The coefficient vectors were linearly independent, but the
underlying polynomials were not algebraically independent.) The other polynornial factors of these
short polynomials did not vanish at these roots. This linear equation has an infiuite number of
solutions, but in our experiments our desired roots corresponded to the smallest integer solution,
which we could obtain by rounding.
Let
utluA-w:0
be an equation we want to solve for r and y.If u and tr are relatively prirne, then we can write
cru + c2u: 1i änd parametrize an integer family of solutions

n-c7w+Dz
A:c2u-uz
withz: c2r-c1!.
In experiments with the already-factored moduli, we observed that the solution was often the
minimum integer value of r or A among the solution family. So we searched for z among the
rounded values of -c1wf u and c2wf u.
For the handful of cases where the lattice did result in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6.2 Experimental results


We ran our experiments using Sage 5.8 parallelized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, aud Singular to factor polynomials and
compute Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear facüors and looking for small solutions of the linear equations
as described above or using Gröbner bases.
We attempted to factor each of the 2,086,171 1024-bit moduli using several different parameter
settings. For k : 3, we had l0-dimetrsional lattices, and attempted to factor each modulus with
the base pattern o:0 using Y :230, X:27o, and t: 442.We then experimented with k:4
Y : 228 and X - 2100, which gave us l5-dimensional lattices, and experimented with a base
pattern o - 2517 * 2sto and five different error offsets: t : 0 with y - 2t28 and X : 1, and
t:128,t:228,t:328, and t : 428 with Y :228 and X - 2100. Finally, we experimented with
the choice k:2, X:4,Y:4 and the choices of t and o used in the,t:4 experiments, which
used 6-dimensional lattices and theoreticallf should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice k : 1 with
the same parameter choices as k: 2 did not produce results.

6.3 Handling more errors


Flom these experimental settings, it seems likely that many more keys could be factored by different
choices of parameters and initial pattern values; one is limited merely by time and computational
resources. We experimented with iterating over all patterns, but the computation quickly becomes
very expehsive.
MAT A BSI-1-6c_3.pdf, Blatt 265

0260

12 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

k logr(XY) S t ff farlored keys f alg. indep. eqns. running time


245 r05 3 4.3 hours
31001 112 - 2 hours
47285 109 4 20 hours
Table 1. Expe.im pproach, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all of the other cases were solved via the heuristic
methods described above.

Patterned factors: Mysteriously, using the base patterns a : 0 and a:2577 *25'0, the algorithm
produced factorizations of keys with other pattemed factorizations. This is because the product
of the bit pattern of the relevant factor multiplied with a small factor produced an integer of the
form we searched for, but we are as yet unable to characterize this behavior in general.

Hi,gher powers o/p: Similar to the univariate case we can construct higher-dimensional lattices in
which each vector is divisible by higher powers of p, e.g. using multiples of N2,N/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of XY only for
lattices of dimension at least 28.

More uariables; More isolated errors can be handled by writing p : a+Di:tTtn s,i with appropriate
bounds on the si I Xa so that the intervals do not overlap. The asymptotically optimal case is
described in [9] and reaches similar bounds for lli=, X4 as in the univariate and bivariate case.
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottom bits to generate a prime, the condition (det.L)di*t/r 1p holds
only for lattices of dimension at least 35 at which point X1X2X3 ( ly't/ra can be found. A lattice
of dimension 20 leads to the condition XtXzXz < 1. A sufficiently motivated attacker can run
LLL on latüices of these diraensions but we decided that factors found thus far were sufficient to
prove our point that the smart cards are fatally flawed.

Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the system for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each of the affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they informed us that they were not issued new
cards.
Several of the more recently factored keys described in this paper are still valid. This means
that MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart cards.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
longer responds to our queries. However, it is still possible to download Citizen Digital Certificates
from MOICA through a web-based interface under "Query of Certification" of "Certificate Ser-
vices" on http://moica.nat.gov.tw/htrnl/en/index.htm. Interestingly, the Chinese version of the
web interface requires much Iess information to query a certificate than the English version.
We emphasize that the random-number generators used in these cards obviously do not meet
even minimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problems until all of the cards are replaced.

References
1. ANSI. ANSI X9.91:1998: Digital Signatures Using Reuersible Public Key Cryptograph.y for the Finan-
cial Seraices Industry (rDSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 266

0261

Factoring RSA keys from certified smart cards: Coppersmith in the wild 13

2. Daniel J. Bernstein. How to find the smooth parts of integers, May 2004.
http: / / cr.yp.to/papers.htmlf smoothparts.
3. Dan Boneh and Glenn Durfee. Cryptanalysis of RSA with private key d less than n0'292.In Jacques
Stern, editor, DtlROCRYPT,volume 1592 of Lecture Notes i,n Computer Science,pages 1-11. Springer,
1999.
4. D. Coppersmith. Small soiutions to polynomial equations, and low exponent RSA vulnerabilities. J.
Cryp.to I og y, lO
(4) :233-260, 1997 .
5. Don Coppersmith. Finding a small root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, editor, EUROCRYPT, volume 1070 of Lecture Notes i,n Computer Science,pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Informationstechnik. Evaluation ofrandom number generators, 2013.
https://www.bsi.bund.de/SharedDocs/Downloa.ds/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-number-gener
and https://www.bsi.bund.de/DE/Themenf ZefüfizierwgundAnerkennungfZertlfrzierungnachCCundlTSEC/Anwendungshin'
7. Andrew Granville. Harald Cram6r and the distribution of prime numbers. Scand,. Actuarial J.,
1995(1):12-28, 1995.
8. Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. ln Proceedings of the 21st USENIX Securi,ty
Sympos'ium, August 2012.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYP?, volume 5350 of Lecture Notes i,n Computer Science,
pages 406-424. Springer, 2008.
10. Nick Howgrave-Graham. Approximate integer common divisors. In Joseph H. Silverman, editor,
CaLC, volume 2146 of Lecture Notes in Computer Science, pages 51-66. Springer, 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh Safavi-Naini and Ran Canetti, editors, CRYPTO,
volume 7417 of. Lecture Notes i,n Computer Science, pages 626-642. Springer, 2012.
12. Arjen K. Lenstra, Hendrik W. Lenstra jun., and L6,szl6Lovänz. Factoring polynomials with rational
coefficients. Math. Ann., 261:515-534, 1982.
13. MOICA. Safety questions, 2013. httpt//moica.nat.gov.tw/html/en-T2/f.aq22-066-090.htm.
14. National Institute of Standards and Technology (NIST). Security requirements for crypto-
graphic modules. Federal Information Processing Standards Publication (FIPS PUB) 140-
2, May 2001. http://csrc.nist.gov/publications/fips/fips140-2/frpsl4o2.pdf, updated 2002-12-03.
See http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf for differences between this and
FIPS-140-1.
15. National Institute of Standards and Technology (NIST). Recommendation for random number gen-
eration using deterministic random bit generators. NIST Special Publication (NIST SP) 800-904,
Janua.ry 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime was found.
46 ,
0xc000000O0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002f9
7, 0xc92424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424es
7, 0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000101ff
6, 0xd24949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949244924249224929249924949d7
4, 0xfOdbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbc1
4, oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbOddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbOddb6c6e23
4, 0xedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66dbOb6dbb6dbdb6ddb6d6db66db6b867
3,0xd0840842427O2L0AOA42A42721081084842142101O84OA42427O21O8084284212108108484214210108408424270270A0A428421210810848421421010840985
2, 0xe0000000000000000000000000000000000000000000O000000000000000000O0O0000000000000000000000000000000000000000000000000000000000000f
2, 0xfSadsad6d6b56b5a5ad6ad6b6bSab5adad6bd6bSbSadsad6d6b56b5a5ad6ad6b6bSab5adadobd6b5b5adsad6d6b56bSa5ad6ad6b6b5abSadad6bd6b5b5ad5d39
2,0xc28550a128500a14850aa14250a114280a144285a14228501428850a428550a128500a14850aa14250a114280aL44285a14228501428850a428550a128500a6f
2, 0xfd€fd6f7f7bd7bdedef7€fTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbd€bdefefTbfTbdbdefe0bl
2, Oxd2494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992484aot
2,0xe94a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a529294a94a5a629529494a54a525294294a4a52a529294b9afs
2 , 0xdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d7015
2, Oxca52d529294a94a5a529529494a54a525294294a4a52a529294a94aSa529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a601
2 , 0xc000000000000000000000000000O000000000000000000000000000000000000000000000000000000000000000000000000000000000000000O0000002030b
2,0xd8c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c9c63c631318c18c6c631631818c69107
2,oxf18c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c1907
2 , 0xfTbdTbdedef,TefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbd€fd€fTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbd82S9
2 , 0xc42L42!O1O84OA424270270AO8428427270A1084842L42LO7OA4OA4242|O27OA0842842L2!087OA4A42L421O70840842421O2LOA0A42A42I2fi8108484214369
MAT A BSI-1-6c_3.pdf, Blatt 267

4262

14 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

0xefTbfTbdbdefderTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbf969
0xd4e682e94f 1d6018a02056c0db85Oa74b3591b0f8405L4ce4077b2r5d25925ba2429a66e384b5be96e6a0a03d4a11eba10416018de3b3e354477250037b6f813
0xcac05be5c1eabf0c21f8e95cesd3cO777904282d7tdOc7738d727el97a0a32fda4cc59cc50b99d29f7fa8do7c972402ab88573e255db6bab055058 1.2c73c291!
0xcf052499061243cd82cd1b2059446c9634a7834d929ac929d92b259245254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4d144e242dbd
oxta94a972e2d,cttO68ee7257e228b53e9b9fcf46877f07daaa4d13c2bedJ132d07730f549f4691t68553f84be8ff405f 16a663d8fb8f82987bd96073a8108edc3
0xefTbefbdbdef9ef6fTbdTbde9efTefTbTbddgdcfefTb3TbdgfeddefTbTbdTbd€dee6€f3bSbde3de7ed7bfa99adebdef7b7bd77d7cff leeTbTbdebdeeefTgfSab
0xeeb29 19e1dc9ce33c2a0d9e190465b164a53c7c03e9a3d009ecf8fd6bdt743a04444332b7 ff4a0e8f53b5123a5422563a06a487cd6cb5f36cd541 1f0ae4dbc69
0xf51576e530188d5gbbcSf4f6ec9e824d7a9e7O742952b1 1c49a6f38188adgdbe3d29d1d9498b7aeffc4d9b0420f7!895t62e2a7b79d4887e45b6227e0b84fb97
0xd83f22a49af67d7f 196df580d514464d6dbb880b03bea50ddcc1f931ef7l09af2f880de26d88cbf24567302a0d6eed7cBeab859aa0c1cc18bd8efacdce194c13
0xc 1df3e8dbSf7b7f456edc1f60d23f60360536565836ce37af6f02e55de24a8dc373f3cSd49c93ba6fee0d44d08bcSfb0655781adeeSc05777fd4da2bcd803d0f
0xe279872638463a0a32a1412b13efccfa5ed68db44963c7f6955a3816bcaa33f94794c8b75298ddf4a8664e485ef99e6d9469f5187939e395cb1f09e666786741
0xce73e73939ce9ce7e738739c9ce7ce73739c39c€ce73e73939c€9ce7e739739c9ce7ce73739c39cece73e73939ce9ce7e739739cgce7ce73739c39cece73ead7
0xdg2ae5c6453et ec55c5614207827de2b77bf3ef027f4230fBaac1Jdgb0d69fdc61934132766f8dd1d8cb22ec38d834037eff6dgdd3535b9e582fbdd232Tcgces
0xc080000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000001003f
0xfff Tfff ffef ffffffffffffffff f if.teTfftfttTl.ftfffffffffffJffffffdTfffff fbffffffTbfffbfcffffTf ff ffffffbf 00000000000000000000000000c 1
0xeb6f80ff65b4a6d462cfa5961f642t25e207667752b0482fSac9dc091f4dc854de9c73b288aaaSda5298a33928f7b2920f89b81e3635932bc9db99a34e52b82b
0xfdfTb9bffbffdebeb28S92bT6f6gbbffbffdafaeffd9fTbdf 1ee7bfa6e2f33bb67dSaSb5676d2bf6a1de3626f06be367fJde73db1e01fSd3855f21f0eda8b4db
0xe643203b22b4048427210bd390d45a3a62ac132c0063990067686123d50128812e0941 1f27098400c841e09183400431018100a2b1cc0954c0405026420e8c71
0xfr ef efTffde6fff fTfffffbffff ff fbff effbffdfffff ffffffffffffffffff f ff fff ffff 1f cf ff f ef46ffldfdfffTff fff fffflfff ff ffffffeefefeceff e8d
0xf6dbdb6ddb6d6db66db6b6dbbOdbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66b37b6dbo19a4697
0xc000b800000000000000000000000000000000000000000000000000000000000000068000000000000000000000000000000000000000000000000000000251
0xccc5ebfea2f4bebBb62dfef5429f97f06af0af8d08159d21df4540a0197fJdb8386c8ebb18bd70b0f46c9615d2fcd0ea38a2cadb522ct79t2c3ab27d9564a197
0xedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dadb6d9b6f6db66da6b6fbf6cb9b7ddb656d9e6d36a7dbb673ba6ddb6f6db66df6bSes
0xe7fa15ab6c3d2c3d13960f598cd2bbf74a688580eSfdc70064563a10558t 1dfd36dSe8aec88897c79d73ebdcbec1bSf0121 175ceaae69e3a31a63f9e66eObfcs
0xffb308867fee16267Leb2blat272ffefffffe4308866fff5fffefe13Jfcf869aff4br907ff 1f9393fff0ftf3fJfcfff7ff3ef703ffaa8c7ffffe491affeff3b1
0xc010208a48c18027210A7084A42L4230fOa4084242O06309ca468d2123081084a520431000c40a425210210a084a8c€1290810cc84204a901 1ac28424O7O22e1
Oxe739729cgce7 ce73539c29cec126e7383b8e89bd2207faed08428421318c1084c410631858c68c63e31035cc8c63ce31318810c64331231818c60€63623b32a3
0xfeb1b9efa29f64ed53628a10a924b5268163dd887f653a6b82edbo63b6874c2039e4938018ab949a3c28cdc785fe2be58872c0c8a9ec5171e37ea6a82d5d46d7
0xc0100000000000000000000000009000004260400c000000000018000000000040208000000000202000010800000000000000000000000000028000000002f3
0xf9d5834f918b673e1f7eaae3cc5d97dd2706dd8de9cSb2fbef679b2c196933fe30f62ac3f7fcc 1c593fb63aobbb8838b8486eac959cc3949ea9182c46396fbcb
0xdac45d37aadacfec73b3184ef43d52d6314754abd38414dde03ade396bd809aa281 1047f015c9c71f0cbb0a91028190adeacc36165b0e0e6fce64549f947€ods
0xf49808713746a41a331625a7cb389611eaa3905984245f99e828f 17f867473cfaeg1230478715024db5ead44b eb2oib.73a23a27ld627 a777 47b5823f753eb03
0xd67a7b11 1c0401971f57806a2be12a174b8923fd3972ec64fe3de3€e96594a74207837d!2f16f545851cad6356bb16221bee68eb2tee9427e0daocaSf98e5861
0xe83071df5288c373aSbc43fb20309e25e99fd85b61a9a4e6f3f7151 1b98f7ec87047fb32520d94cd7753dbe1733O4445ca648231f601dd19d3cd40c74190c71d
0xed4294bSa529529c94250ad35394214a4a52a569a94a94a5e56b52948c aT4d52529429524a5aa529294a9ca5e7295294d4a74a7 27394696a4a13a529236a968d
0xd621€b6e5ab7992c6efba5f34a7b7b28026fc93138998c1 13831dbaaaca1a15738a7b7agd191bcd77955b92b75263adgf6bbd4ce0b4edca1efd5t3e24b3a2889
0xd9a43ff058df6b8d55085028eac413a7439e1dc89eSd6e8b5de09e7bc7483d762788fi9e36527ff67c39360cfc0d2a75986b7fb35614027cffb932e€1 1 12ee8d
oxe49292499249492449252492249292499249492449242492249292499249492449242492249292499249492549242492249292499249492s49252492249293A1
0xf9cf9b29d767edb655b2f6bf964bce697f652fb669b322€b63dffb6e7a6c69bb798396d284d85169883d42a6ec96b292761d6dcd7ab595b2adOagaSd7e97te4!
0xfffefffefffffffffffefffefffefffefffffffefffffffefJfefffefffffffffffefffefffefffefffefffeffffffff000O000000000000000000O0000000bd
0xf9€e9ce7e738738cgce7ce73739cb9cece73e738398e9ce7€719739c9ce7ce7373dc39cece73e53839ce9ce7e7b9739c9ce7ce73739c39cece73e73839ce9d63
0xd53bd2f L69ab7fb38abb7fOScb1 55Oe2OO914674b65ce176OO1ffeb29db dleg1c2La77e28c6dbfd6e6a782baaba532e2a98eff9ed8e924986af7O2c485O4dod1
0xc36e8f2addb6O2dgd18b2b040bc7a0Obc7046b2030c2d3e91c4c161ed562a31d2dO56afc759042a46c28e218e25E7c7882fb1cb2d66039ed961alaceSea69cSd7
0xed15cb0fd€ 1567b278et2422ee,!ed658173594b0bcb71594a18df455fc75ca7c5b52gbb6b9Ec229be6ba9777736ca917ac08a1e9f557adf079ab8bceb2bc01b
0rd00b0dd78fd35c88db31806803799deab89b8b36c39dc0321574801fb936f90e2920f3dd65400ddc00be90ebcefdd62dScScO62c200bdb04aaOa5acJ697e2aOd
0xd0054c94020831e800450e0581 1840282088a906825002d9a0c340938dc0b20628072f800334102c08010309c020800710200c04a6040837O0aa44008841 1987
0xc7592d7dc9ee1031dcd3d30f43028858305ac46ac981cafa164a8000a9c6eeb698181505242ac9dfee9e51c92460b987dbc8161def71863d35ac18fa1235a903
oxff fbf cfTf 7ff df3dfff et 5f f ff ffbfffff 9ffffffffdffTdffffff 9fff f ffef 7dl ffff fffbf ff df ff effbfffffffffffl ffTTfJfdfffffffffff lfffff ffff35
0xfSeb05d73ad4df3cdaf4td2eaf41eBe405952b7a327479147fffa33eb829039e77ff 116f9e4958a3f604743ed2c55ba67b47631842905dbc2f12c66fb6c4e40f
0xc3ff4d30474f40df0e7ffffdfa92ffff 1 1d59d35d214ffff85c357cSc85ed72acaf 1fb7d43f76d85€e6b4ib3ftdd60d5095€f 1f290df4ff888eZe37efe4f9e8f
0xcc7b18295347824ccb395bed351993c598c7cf7f4€32dcb9ab7aSd7eObaa7626d1b8dc651b34f5e4fSd3f2530b52fbgbd10e75259b36d774f059141bf9ede911
0xe675a7059b1e6df20198f8a76a0ab28123frf79a67f59c7049fd37d48128f3b3agb69475b902f4bc854ca1deecbce73cdab89b17ae3c6401a9d43594775a926b
0xef7b77bd3defdEf7f7b47bdedef76f7b7bd€bdefefTbfTbdbdeeTefTbT3dTb9edefTefTbTb9e3deeefTbfTbgbdefd6ffffbgTbd€def7ef7b7b9ebdafef3bf845
0xfd23b110962000d598488c43407369898cd0086df780826dcfa14784f38388874362851b771 1dc13564441351335c71fbd7c564dSd5008f5de20d43t2476d715
0xe918f 165879091 1a71a9ae1895cte56dbed767816e337e2f950462affb3280d8a8dcb1240620ec8f 1d19c3750afcfe295c58cca1 17b36632414cd9e114fdbo97
0xffffaa55ffffffffff3cd9fe3ffff676fffffffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000009d
0xc021000048041000001000100080OLce2o64OO4242c812186250154c00000088ba78008a43a9713bc0abb849220e8362cc838b53cI88fcdbdd7fca83c8df8145
0xe3 183 18c8c63c63 13 1 8c 18c6 c63163 1818c68c6363 183 18c8c63c63 13 1 8c 18c6c631631818c68c6363 183 18c8c63 c63 13 18c 18c6c63 1631818c68c6363 183 1d3
oxd501973162d4017f4e3b3c9d6803d4cc46a1d457c91f€bsb6c2ae77423ba41c9cfbdsf4b9235667874507e9cafb4123e1992d1cSae75ee29508701 1a822a6ccf
oxe28ecco1de7a0326423076465160c 1b03f8e721 181e046ef4860ae94d7802a082f9f6007c0011f20056de200677aa7d8a471 18e6692ee4b3f862c24e04b543b5
oxda2f36d74bc2dc29de4de92f4b37b03942173e15a2dfb67e8f09e79Oed1656af5a8aadef 14b696426f 1e929699da0€e3adgf21a9f66ede57d945fc 765b27d2f7
0xd28550a3a8520a1c850aa14250a1 14ba0a144285a1422850742885Oa428550e128400a14850aa14250a1 1408OaL44285a7422851 1428852a4685d0a128500a2d
0xe79082499b094b2459266493608a9249b2410d34092 42692a49OA24d934941254935265a3410861 19449d824691524922697926bb24949O44O277O8a8c939aSd
0xedfc3T3fTS3ffbfffTfefed3fffafff€fffdSfffffdefffSffdffff3ff5ffffefefd3fefTfbfSdfff6l3bbS9f9fb5f5bdS2aefdTSebddfe6edeefle3fSfb3dfs
0xfffTlfb6fbfffefffffffeeffffeefffefTfffebfffeffffffffefff9fffff cbfdbff0faffffdfffTfTedffeeTadfffafffbfbTeffffdifdeTfadfdef63esO6b
0xcaf67d473c10t4e73d6678d4a27e4eb04a743925d12c31f97efa510ca68558b2c56d839acecbe75e935f86cec7dae7c95aa0b93065a3aa924594fdfb9f521535
Oxf6b43€3bd52841756d1a27f22a8590a8a1c43c1 c36b95cc72dO1O2f26b6da1b23a236856f7c6e6faa83cc7Oe84f2db44O88487fd94a175f22aodg9Occ1afea6b
0xd2a20d1b986de2152b9d93cf6obf98f68e9f9eO5Ofeb9820b0O6e5dc581f 17a82f35a78d23fb34fab3962ae95bcf3a1e442ebSb1d72cd6956fa599483eee38c1
0xe52e529494a54a535294294a4a51a509294a96a5a529529494a54a52529d29ea4a52a522298a94aSa522529494a44a525294294a4842a52e294a14aSa52f554b
0xc942c4644b1 169461581e0713ba400570237a55c9ae69e3fe58d189aa751d218208421934f2132a888e796bc1f0914a8c9b4r 1 16358cca22c69c35596bd961e5
0xed7f7e78af c7d3735fc1dfb0d13887cddcd715c9fe530530e0efceaa4bcaffbaebac9e601623db36fffef47fffffefffffff000000000000000000OOOOOOO3ed
Oxf6db9b6dda6d29b61dfe73dbbaSbdb6d.dead69beedf6aOdbf7dadb6ddf6c6cb66db6f6d3b6db9b64997c6dbg6cb4364b96dbdb6ddb6c67be6da4b7cbaedadf35
0xc080a1000000000000000000000000000000000000000000003008000880000002608020010120004408001004202080000800000050000000100000000900e1
0xe5335f76a97cSe29d4557170cd9ef3ed53efc819fda87a566aSefe247ef102b85c7ad90c484ade030c7ebc23455e0dcbca2cec6afdf0e8c978cb6fbed5733fa5
0xc0000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000400000000000000000000000000000165
0xc924249324929249b2ct4924492464926492Ia4A92494936593320b93f 9292e992497dt449242492229293499249492449262493248e96fff3c9104432f4cdbb
Oxc9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
0xc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000177
1, 0xc00000041002400005080008021000049000000100000002080000000001021005180000000000000000210080600040082000400000183001000000200020f 1
1, 0xcadoca7 166b2aaf6c82b0eadfeb13409da7c2679517d4fd96f89719659 133e0492d209da600753dc5c2570ce128cf985332f944143204b706bf6e990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 268

0263

Factoring RSA keys from certified smart cards: Coppersmith in the wild 15

1, Oxe739739c9ce7ce73739c39cece73eZ3939ce9cez€739739c9ce2co73739c39cece73673939c69c€7e739739cgce7ce73739c39cece73e73939ce9ce7€73973df
7, oxaog2g24gg24g4g244g2424ga24g2g24gg24g4g2449242499249292499a494924499424922492924992494924492424922492b24992494924492424922482926t
1, oxcoooloooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooolooSo2ooocboo4ogo38oglSooo8aSoo00000l0c000l2l0lb20000000002ad
!, Orcecr2ToogetO7418atc89e2c96 eTg6d44bc2244d}8aObbBce9Ob4d661736b486b6€1d8352822a4697cdd07 02a3d8b7c4b23ada22B5a2ato9234a7 1346b8141795
1, Oxc8d.ceZ2cOe38ecaf2e3e11aef07326e3431a92ad87el296d3dob6d4b3dOO646bobd7b3af6c9e424eO74e1486d186d26997a4d9c131acb524881aEcace287c067
1, OxeeO9fObE62OL4c72gget8fl'27ab8cdOO48O9c631f1id5Oa2OO13331678ccaat2O6318?9842b8a122669€b18c4b1ddse4b1lbce7a14t4ae76973debf4c8768c4bd
1 , Oxd66cdaeet27Ebfalgd1ee6fir43OddZaeo1SbdOe9aSe4389Oe7836€2a2a01b702703d0c3fd50d5917t3ba77aeb851c016d26135d754c114adf303d091500462bd
1, Oxfa147eaS8cddaaabe6dtao4ff891OO9db3ff3Ze1272d573b7a3da63g4l24fg6l2lda7tt41l63a72482a}eatfra9140001aae21fSa64fd:|30f93s819a968acatb7
I , Oxf718cObcOc5Zccg18c99fa1S2A6191asg182BagSOS6d6ac833a7€3a211Odded25226ea4344cabbb2fe1gde14863b8c46o31btl4038c87e8ce4aea42a10alabf91
1,0xd86at996183ba3c0870238db47f1d3t673cdec3112196acfaa1239667bcb3a3a7t6749f3229f550ds097510e5asdf0626a641e2112112f95080c5629973b1c976
1, Orfc1fc96eeZ482142bccb7tObcScd6Z4ad82edca6:Ife26sgc78622ea673485cc11c993a8aeb15t77dgodte1c6a945e239ab47e5ca3eb2aeb7o2f2de36626858db
1, OxfTc6bf2lSfcfadcbag26acEE ru6OtgZaeba8alsfTOceb2Z€tfOfSd670763bfe86dc7ä86€676b8ba9do76bt1a8l4a7fcfb0297a96c6cEa7o€a7ese3c38326ff83
I, OxcS94391o868c24c8a7fe971d78db78atd4Bc96ba3g84fO2acf71fc2506?36c65f7c44st6c3bbf7b05659b954c6b9ce96t648c900b56cSf3caO1e473B4ad4da577
1, oxdagZS41o693d312Ob3299Zc8cZ2BfOgdo961of6fefoB9azct63fi1dcf673ffrfb493c19c64167e0457646aaba4f3409f9648fr7c390c25d4a8a3d7c9b2f16b2d
1, Oxf16feaatgafO3clcbg6SZ1b8b3fe3ct246313aec€858b7d4e800838329c9b729ecc6d691di4e€8547a9fdb18d6bbc43384f8214fa1603ad53f8e3a0603bfb6735
1, OrddJ3b56a7bb556afa1476addb54aa956569c94ab62d5fa95cO54afO4b5a3b56adft55e2dbb4666d1b56aaal581629c6a93adssbf5adie3ba4e5ab9722dat5d7bd
1, Oxd99Sgfe3Og34b89cBcO2ac21Oc4dc8o6e61Od1c968cb4d436e11aedeOf72e3b8a88e18b7c663533218c68ed560b031ad4ce38aa13bbc10b6c73fe3911acc8ds1
1, Orfcbo663sf5e3c922936834039fd787aode9fdd178017O21129cfb5925?Of,aü]c5€60787fc59128bc66btcb38be0c064b08c087fd8fs6b960207c93ca4ci3c5add
MAT A BSI-1-6c_3.pdf, Blatt 269

026 4

16 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

B Appendix: FIPS-140 certifcation


Searching for the term "FIPS" on MOICA's website (http://moica.nat.gov.tw/html/en/index.htm)
returns the following entries in the FAQ section, all of which claim some securi§r through FIPS
certification.

g I mkr$t9wl1. q'ir E

O ;*.rto Agttrortty ot rct

|A:It is iuposa'bh ro Ept hEv dete 6om cerrificate IC crd A prh'ile i

|ey pumrter ia creakd ir Cryptographrc Modrles wlticb i5 utiliees ,

ithe RSA ad rudon ßetrsator: .{ privale key i§ lsed to seale,


FTQ l0roted, ald s(r, r ir HSil{. Besides, Tbe IC cad äc(ord.trce k'idr
,FIPS 140-l lerel 2 certifiable hr'l(, cdd DanageDsr{ co*a ard dre
icad pusess biglr senur§ A prtvile key !s qeated insrde atd 6e

l$i§a& Ey cirl ! rporl t oD IC ra-d aris- k:I .t_oilt4


[,iritrigi ristr o rore."tifi .ai-ü G d;6y disi'rü,* .ar r"kn1, :

if,opy ä ars tise The r-lrirsr digitäl cstificae pasJ FIPS 140-l :

tar$oritr level ? ard have Ligb semity Priv'irü kcy cu't br copy i
r'- FAQ
i{rau IC crd afrer gerer ae key prir ol iosidc tlre lC card. Thls
icerrifirde level 15 \ 509 v 3 flle polic-r of cifirqr öEital cqtifi(ilc
i
ithat cenifi<xe should load itrto tC Cüd
a:Liiordtngto ciS ot tlotcÄ. urc ic cad rr high swir! ud i
AQ lbme bctn acoeditrd l§ rlPs 1,10-l level 2 ad Üe cad use is used i

I
Itqc-f9ari_.plo!!!t d,.,llryi!l§-* ,
i A Tbe CA hey paüs ile gerera{cd rviüiu hudrrae clptogaphrc
inodules or softi.a e.lrrdwae oyp(ogaplü( modules ui&iu the lC
FAQ ,€ad. treetin8re$riteuenr of CPS ad FFS 1,10-l lerel2

t. :tgllqsg-q' 91 c9p?1 +l9 Tcgig S*gt Lglgt ..


;A:Thc C.{ k:yr a e crexed in a crypmg4hic noötle, rringRSA
.algoridrn and rarlon runbe geuerator. Creatcd widrir a lrdrree
I
l

nodule. dre ptsrte ket is med ioside r'itlrut lealtq:. f,{caw.


FAQ
,'
icstificste s(bs$iber's IC ced is iutamlly l{G
I lelel 2 (§tificetiou ,rf tln Cad Ceuq Tlrc hr,
'"lPgl *!! E"lts,ti!"..1
I
,Ä,ü.äiri r"äi"iic-iard r rlu carig tciüä
rcru be easi§ copied ud ibe risk is [iglt.
.arhrndcärios. da cetificre IC crd ir [igfr§t
i FAQ
lbrin3 3mcraed iuteully a&er wütct r
isemed ttor r.plic$«l sübsoibü't
:üsin8 rr^rtifi(dr plot€ctiou 1i.509 v3 lFq
Tord6 Page l,'r-- [ Ntr 20 | [ Dl* 20 I
tile:lll
MAT A BSI-1-6c_3.pdf, Blatt 270 #t
Re: Fwd: Re: [Renesasl possibty unsecure RSA key generation

Von: "Hesselmann, Thomas" <thomas.hesselmann@bsi.bund.de> (BSI Bonn)


An: "Lochter. Manfred" <manfred.lochter@bsi.bund.de> 426
Kopie: "Schindler. krlerner" <werner.schindler@bsi.bund'de>, -E!g-f-J3-t-t-h-hl
<matthias.peter@bsi.bund.de>, "Wiemers, Andreas" <andreas.wiemers@bsi.bufld.de>, -5-EU§S*
Ch ri s t ia n " <c h ri s t ia n . k ra u se@b s i . b u nd . de>, -§.a.b,-qi§-1-Jd-ti41
<adrian.oabriel@bsi.bund.de>, "Gamero.Octavio" <octavio.oamero@bsi.bund.de>, -lM-Lli3!-
Gereon" <oereon. killian@bsi. bund, de>
Datum: 30.08.2013 13:33
Anhänge: {i)
c rnmmcnts on thp Presentation on Crvoto 2013 Ramo-session about Certficatesv2.odt

Halto,

im Anhang eine (kurze) Stellungnahme seitens T-Systems zum vortiegenden Falt.


Neu sind die Ausführungen in den Abschnitten "CSP of Ministry of the Interior
Certiflcation Authority" und'M0ICA Smartcard".
G rüße

o
ursprüngl1che Nachricht

Von: "Lochter, Manfred" <manfred.tochter@bsi.bund.de>


Datum: Donnerstag, 29. August 2013, 08:49:56
Anl "Hesselmann, Thomas" <thomas.hessetman
Kopie: "Schindler, Werner" <werner,schindler(Öbsi.bund.de>, "Peter, Matthias"
<matthias. peter@bsi. bund.de>, "Vrliemers, Andreas"
<andreas.wiemers@bsi.bund.de>, "Krause, Christian"
<christian.krause@bsi.bund.de>, "Gabriel, Adrian"
<@, "Gamero, Octavio"
<octavio.oamero@bsi.bund.de>, "Kiltian, Gereon" <oereon.killian@bsi.bund.de>
Betr.: Re: Fwd: Rel [Renesas] possibly unsecure RSA key generation
> Halto Thomas,

> angehängt das paper dazu. Die Präsentation von der Crypto habt ihr ja schon.

Q",,",
EI
7^ comments on the Presentation on Crvoto 2013 Ramp-Session about Certficatesv2.odt
MAT A BSI-1-6c_3.pdf, Blatt 271

0266

Comments on Crypto 2OL3 Ramp-Session


Presentation about Weak Taiwan Citizen Digital
Ceftificates
Wolfgang Killmann, 28.08.2013

The lssue

Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja
Lange and Nicko van Someren gave a presentation on Crypto 2013 ramp-session "Factoring
RSA keys from certified smart cards: Coppersmith in the wild" available on fl1. The authors
analyzed Taiwan Citizen Digital Certificates issued for government-issued smart cards (slide
o 2 shows the MOICA card). They discuss a hypothesized key generation process for weak
primes (slide 9) and hypothesized reasons (failure) why government-issued smartcards
generating weak keys (slide 16). On the 2d slide is a statement "FIPS-140 and Common
Criteria Level 4+ certified", where it is unclear what component is meant: the smartcard
application, the operating system (OS) or the integrated circuit (lC). Unfortunately, the vocal
presentation is not available for additional information.

The following comments discuss the key generation for Taiwan Citizen Digital Certificates
and whether Common Criteria certified components might cause the weakness discussed in
this presentation.

The term 'RSA key generation" refers to the generation of the two prime numbers p and q,
which product build the modulus n and if a fixed public exponent e is assumed also define
the private exponent d.

Summary of the presentation about RSA generation used for Taiwan Citizen Digital
Certificates

The authors of the presentation analyzed 3,002,000 certificates for RSA keys available from
Taiwan national LDAP directory and found 2.3 million distinct 1024-bit RSA moduli, 700,000
2048-bit moduli (cf. slide 3). Note The Certificate Authority of Ministry of lnterior (MOl) issued
a total number of 3733239 certificates (2O13lOBl28).

They apply an algorithm finding common prime numbers in different moduli and found
commonly shared factors (cf. slides 7, 8):

(1) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000002f 9

(2) c9242492249292499249492449242492249292499249492449242492249292499
249 492449242 492249292499249 492 449242 4922492924992 49 4924 492424e5

Based o these primes they assume a hypothesis about the prime number generation
algorithm (cf. slide 9) and apply factorization algorithms based on hypothesis on specific
types of prime numbers in the moduli (cf. slides 11 and 14):

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 272

4267

(3) c0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000101ff
(4) c0000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000100000177

(5) ffffaa55ffffffffff3cd9fe3ffff616fffffffffffe000000000000000000000
00000000000000000000000000000000000000000000000000000000000009d

( 6) c000b800000000000000000000000000000000000000000000000000000000000
000068000000000000000000000000000000000000000000000000000000251

Based on their findings the authors conclude hypothesized failure

O (1)a weak algorithm were used for generation of the prime numbers (cf. slide 9) and

(2)possibly weak random number generator was used (cf. slide 16), especially

a) hardware ring oscillator gets stuck in some conditions,

b) card software not post-processing RNG output.


Key Generation for Taiwan Gitizen Digital Certificates

This chapter analyzes public available information about the key generation for the Taiwan
Citizen Digital Certificates

1.1.CSP of Ministry of the lnterior Gertification Authority

The slides of the presentation do not provide details about the certificates with found weak
RSA keys like issuer, validity of the certificates, Certification Policy or Certification Practice
Statement (CPS).

The CSP of Ministry of the lnterior Certification Authority (MOICA) is issued as version 1.0 in
2003-04-03 and last updated as version 1.6 in
2013-06-1 1 (cf.
http://moica.nat.gov.tw/html/en/cps.htm). Only the versions 1.2 issued in 2003-11-26 was
found in English translation. The CPS Version 1.6 in Chinese is available from thewebsite
http://moica.nat. gov.tw/download/MOICA-CPS-V1 .6. pdf.

The CPS, version 1 .2, states in chapter 6.1 .1 Key pair production:

,,Based on the provision of section 6.2.1, this authority will produce key pair within the
software cryptographic module and will adopt true random number generator and RSA key
calculation method. After the production of private key within the hardware cryptographic
module, it will be stored there all along and will not be leaked out."

"The token utilized by the subscriber is lC card. For its key pair, after the card management
center has driven the lC with the safety control system, it will be produced on its own within
the lC card. ln addition, after the key pair production is completed, its private key cannot be
transmitted from the lC card."

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 273

0268

Further statements are in chapter 6.1.7 Key parameter quality inspection:

"This authority adopts ANSI X0.31 calculation method to generate the prime number required
by RSA calculation method. That method can guarantee that the prime number is strong
prime.

Subscriber's key can generate the required prime number in the RSA calculation method
inside the lC card or other software and hardware cryptographic module. However, it is not
guaranteed that such prime number is strong prime."

The descriptions of key generation in chapter 6.1 .1 and 6.1 .7 in CSP version 1.2 are contra
dictionary. Therefore, few detected weak RSA keys might be produced by software and
hardware cryptographic module, not by lC card.

Note, Google translation of CSP, version 1.6, section 6.1.7 seems requiring that"the user is
using the security level through FlPS140-2 Level 2 certification the user smartcard Security
lC card hardware cryptographic modules'. [2] refers to the MOICA FAQ that cards are "high
security", and "have been accredited to FIPS 140-1 level 2" (cf. chapter 4.1 below).

1.2.MO|CA Smartcard

Suppose the weak RSA keys, i.e. the prime numbers p and q of the module n are generated
by the smartcard used as subscriber token. What is known about security assessments of
the MOICA smartcard?

MOICA states on his homepage [3]:

"lf an applicant loses his/her/its lC card, and the card is picked up by someone, can the card
information be stolen out?

A: The CA keys are created in a cryptographic module, using RSA algorithm.and random
number generator. Created within a hardware module, the private key is stored inside without
leakage. Moreover, certificate subscriber's lC card is internally generated with FIPS 140-1
level 2 certification of the Card Center. The private key will not export after generation."

MOICA does not provide technical information about the subscriber lC card product itself.

The company lDpendant GmbH, a member of the TRÜB Group, informs on its website [4]
about a reference project [5] for the MOICA card. The described solution is based on the
SafeSign ldentity Client of AET. AET provides the SafeSign ldentity Client with JCOP smart
card. lDpendant provides other smartcards as well, cf. Bl (2008) including

. IBM Java card OS JCOP21 v2.3.1 (CC EAL4+) on NXP chip P5CC036/72,
PSCD036/72 and P5CT072 (all CC EAL5+),

. Giesecke&Devrient Sm@rtCafe Expert FIPS M (F|PS140-2 level 3) and Sm@rtCafe


Expert 64 Bio on Renesas chip AE46C1 (CC EALS+),

. |-COS 36 on ST Microelectronic chip ST19XT34

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 274

0259

and other smartcards. JCOP v2.3.1is evaluated by TÜV|T and certified by BSl. Sm@rtCafe
Expert FIPS 64 is FIPS140-2 level 3 accredited. The Sm@rtCafe versions provided by
lDpendant are not CC evaluated, but Sm@rtCafe version 5.0 is evaluated by TÜVIT. All NXP
and Renesas mentioned chips are CC EALS+ (including AVA_VAN.S) evaluated by
T-Systems and certified by BSl. The chip ST19XT34 is according to f] EAL4+ evaluated but
the corresponding certificate was not published t81 t9] The OS |-COS 36 is neither evaluated
nor accredited.

[10] refer to private communication with a supplier of MOICA card (probably lDpendant
GmbH) that his MOICA cards are EAL4+ certified and accredited to FlPS140-2 level 2. This
does not fit with [11].

Based on the referenced public available information one cannot concluded about the
concrete MOICA card implementation which could have generated weak RSA keys.

RNG used in MOICA smartcard chips and their successors

[12]states in chapter 2.1:


"lt is clear from our results that the random-number generators used in these cards are in
fact awed, and thät any keys generated using these cards should be considered insecure."

The hardware random number generator (RNG) of the chip is an important but not the only
smartcard component involved in RSA key generation. The OS of many state of the art
smartcards is responsible for online testingl and post-processing of the generated random
numbers. Even the current state of the art smartcard chips do not generate RSA keys. Only
the combination of hardware RNG of the chips and OS generates RSA keys. Therefore the
weak RSA key generation may be caused by errors in the usage of the hardware RNG
output and key generation as well.

This chapter discusses generation and use of random numbers for RSA key generation.

1.1.RNG of FIPS 140-2 accredited smartcards


O
Chapter 2.3 discusses random number generation and states:

"As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any
run-time testing before generating keys, and they clearly do not apply any post-processing to
the randomness stream. The lack of testing or post-processing causes the initial
randomness-generation failure to be much more damaging than it would have been
othenrise."

They authors refer to standards (NIST SP 800-90A, ANSI X9.31:1998) and evaluation criteria
(FIPS 140-2, BSI AIS for CC evaluation / certification) for RNG. They missed the fact that
NIST SP 800-90A and ANSI X9.31:1998 describe deterministic RNG only. FIPS 140-2
require approved RNG but only deterministic RNG are approved so far.
1 Note the newest NXP chips implement online tests in hardware.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 275

027 0

FIPS 140-1 level 2 smartcards are required to implement statistical power-on tests. The
power-on test will not effectively protect against failure during operation and perturbation.

FIPS 140-2, chapter 4.9, requires a continuous random number generator test, which
requires to compare any neral generated n bit block (n>15) with the previous generated block
and the test fails if bit blocks are equal. lf the length of any repeated pattern does not divide
the output length of the compared pattern the test will not detect the bad random numbers
(e.g. if the pattern has odd length and the compared pattern has even length the consecutive
blocks may be different and the test fails).

lf the MO|CA card is FIPS 140-2level 2 accredited the continuous random number generator
test should detect the patterns causing the weak keys by repeating short bit sequences in
the prime numbers shown above and in the Annex A of fl 31.

O l.z.C}evatuated RNG according to AlS20 / AlS31


The BSI requirements for Common Criteria (CC) RNG evaluation laid down in AIS 20 / AlS31
address

(1) the generation of entropy,

(2) the post-processing if implemented,

(3) the quality of the RNG output,

(4) the health test (tot test and online test) detecting failure after start-up and during RNG
operation.

The requirements shall prevent the weaknesses discussed in fl41:

The T0 test (disjointness test) as part of test procedure A of PTG1 and PTG.2 class
RNG will detect repeated patterns in the RNG output during the evaluation. The
PTG.3 class RNG prevents such patterns by means of
cryptographic
postprocessing.

The tot test shall detect break-down of the entropy source and prevent bad random
numbers output for PTG.1, PTG.2 and PTG.3:

"A total failure fesf defecfs a total failure of the entropy source immediately when the
RNG has started. When a total failure is detected, no random numbers will be
output."

The online test shall detect non-tolerable statistical defects of the raw random number
sequence immediately when the RNG has started, and while the RNG is being
operated. lt is a quality check of the generated random numbers usually realized by
hardware by physical measurements, or by OS as statistical test or a test procedure

2 The first n bit block generated after power-up, initialization or reset is only stored and compared
with the next n bit block.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 276

027 1

that applies several statistical tests. lt shall detect bad random numbers output for
PTG.2 and PTG.3.

Roughly speaking the tot test shall detect very bad random numbers very quick (short
sequences) and the online test other non-tolerable weak random numbers slowly.

Some RNG prevent with high probability repeated short patterns in the RNG output
additionally by design. The post-processing with internal memory may reduce the probability
of repeated patterns and stores some internal entropy to mitigate temporary low entropy
output of the source of randomness. E.g. the BSI CC certified Renesas chips are AIS 31
compliant and provide post-processing by linear shift registers (LFSR). Some chips allow the
OS to enable / disable the post-processing.

The RNG of smartcards under evaluation may be implemented completely in hardware or as


combination of hardware and software (OS) components. lf the RNG is implemented as
combination of lC and OS components the OS components shall be precisely described in
the guidance documentation and are subject of the lC evaluation. lf the OS developer
implements the certified software components the RNG evidence of the lC evaluation are
applicable for the smartcard. lf the OS developer deviates from the guidance documentation
the OS developer shall provide additional evaluation evidence and the composite evaluation
shallanalyze the modified RNG.

The failure of the hardware RNG is not the only possible source of failure of the RSA key
generation. The OS using the hardware RNG shall obey the guidance documentation
describing the method of use of the hardware RNG which is CC evaluated. lf the guidance is
not obeyed the operating developer cannot rely on the certified security functionality of the
RNG.

Typical errors of hardware RNG usage are:

The OS may read the hardware RNG output register before the start-up tests after
power-on, sleep mode or soft-reset are completed. The RNG output register may
contain undefined or constant values (e.9. zeros or short patterns as seen in the
weak prime numbers).

The OS does not implement and run online tests even if required by the guidance
documentation of the certified lC. This might speed up the key generation process but
with bad random numbers.

The OS does implement and run RNG tests different from those described in the
guidance documentation of the certified IC. These tests might not be non-appropriate
for the hardware RNG used.

The OS read the hardware RNG interface in short intervals not obeying the time for
generation of fresh random numbers in the output register of the hardware RNG
described in the guidance documentation. Note the hardware RNG may generate the
shorter internal random numbers and sequentially fill the o.utput register. ln this case
the output register will contain fresh and old random numbers if read before
refreshing the whole output register.

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 277

027 2

Summary

The available information is not sufficient do decide about the reasons for generation of weak
RSA prime numbers in the RSA moduli in some Taiwan Citizen Digital Certificates. The
conclusion made in [15] and [16] about failure of hardware random generator of the MOICA
smartcards is only one of possible reasons.

The reason for the detected weakness shall be analyzed by (i) checking whether the weak
RSA keys were generated by the MOICA cards or not, and (ii) if smartcard key generation is
confirmed by analysis of RNG implementation and usage in the MOICA smartcard.

References

[17] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger,
Tanja Lange, Nicko van Someren: Factoring RSA keys from certified smart cards:
Coppersmith in the wild, slides of ramp-session presentation at Crypto 2013,
h tttr//crypto 2 0 1 3 ru mp cr yp. to/55e2988c4ed 3c9f63 5c9a4c3f 52f aOL 1-pdf

[18] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger,
Tanja Lange, and Nicko van Someren: Factoring RSA keys from certified smart cards:
Coppersmith in the wild, paper to be presented at ASIA Crypt2013

[1 9] http.i/www. id pendant. de/loesungen/eoovernment. html

[20] http://www.idpendant,de/fileadmin/pdfs/2007_04%20MOlCA%20Fallstudie itpdf


[21] http:/iwww.idpendant.deifileadmin/pdfs/2009_11 DS_Chipkar'te_DE.pdf

[22] http://www. commoncriteriaportal.org/products/

[23] http :/iwww. ssi.oouv.frlen/products&ertified-products/

[24] http://moica.nat.gov.tw/html/en/index,htm, FAQ 0502


O

09.05.201 4T-Systems GEI GmbHSeite


Security Analysis & Testing
MAT A BSI-1-6c_3.pdf, Blatt 278 #t
lile:lll

Fwd: Schwache RSA-Keys

Von: "Hesselmann, Thomas" <thomas.hesselmann@bsi.bünd.de> (BSI Bonn) A 27


An: "Frank. Guido" <ouido.frank@bsi.burid.de>
Kopie: "Gabriel. Adrian" <adrian.oabrietGbsi.bund'de>
Datum: 16.09.2013 16;02
Anhänger ftli
>ll[ertl-e-q!-§--dl

vielleicht interessant?

weite rgeleitete Nach richt


Von: "Hessetmann, Thomas" <thomas.hesselmann6bsi. bund.de>
Datum: Freitag, 30. August 2013, 15:33:31
An:
Kopie: "Kil1ian, Gereon"
<oe reon . kitlianobsl . bund . de>
, Schwache RSA-Keys
O.
Hallo G"
zur Zeit wird zwischen HW-Prüfstetlen und BSI über das folgende Thema
diskutiert:
- htto: -rvpto.2013. rumo.cr.vo.to q5e2988c4ed3c9f635c9a4c3f52faOb1.Ddf
- Paper im Anhang (in Draft-Version, bitte nUr intern benutzen)
Auf der Internetseite von IDpendant GmbH findet man, dass dlese Firma
ebenfalls mit der Ministry of the Interior Certification Authority (MOICA)
Taiwan zu tun haben:

htto: //www. idoendant . de,/toesunoen/eoove rnment . html


htto : //www. id oendant . de /f ileadmin zodf s/2007-04k20M0ICA%20Fa1 lstudie-dt . Ddf

Auf der Seite

werden Karten aufgelistet, die wohl als genutzt werden.


n genutzt
MOICA-Karten

Wir haben bislang nicht den Eindruck, dass ein von SRC evaluiertes Produkt
betroffän ist ... vietteicht aber haben Sie hierzu dennoch weitere
Hinte rg rundinfo rmatibnen?

G rüße
Thomas Hesselmann

Unfortunatety I will be out of the office in the weeks 4l-42, 52-92. During
this time I witt be unable to reply to your mail.

Bundesamt für Sicherheit in der fnformationstechnik


Dr. Thomas Hesselmann
Referat S22
Godesberger Attee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn
MAT A BSI-1-6c_3.pdf,
file;lll Blatt 279 #2

Telefont +49 (0)228 99 9582 5691


Telefax z +49 (0)228 99 10 9582 5691 427 4
E-Mail: Thomas . Hesselmann@bsi. bund.de
Internet: www. bsi. bund. de
www. bsi- f uer- bue roer. de

smartfacts.odf
MAT A BSI-1-6c_3.pdf, Blatt 280

427 5

Factoring RSA keys from certified smart cards:


Coppersmith in the wild

Daniel J. Bernsteinl,2, Yun-An Changs, Chen-Mou Cheng3, Li-Ping Choua, Nadia Heningers,
Tanja Langez, and Nicko van Somereno
1 Depäriment of Computer Science
University of Illinois at Chicago, Chicago, IL 60607-7053, USA
djb@cr. yp. to
? Depa.rtment of Mathematics and Computer Science
Technische Universiteit Eindhoven
P.O. Box 513, 5600MB Eindhoven, the Netherlands
taaj a@hyperelliptic . org
3 Department of Electrical Engineering
National Taiwan University, Taipei, Taiwan
{gbf jdks1, doug}@crypto . tw
a Department of Computer Science and Information Engineering
Chinese Culture University, Taipei, Taiwan
randonalg@gmai1. coro
5 Microsoft Research New England
One Memorial Drive, Cambridge, MA 02142, USA
nadiah@cs . princeton. edu
6 Good Technology Inc.
430 North Mary Ave., Sunnyvale, CA 94085, USA
nicko@good. con

Abstract, This paper explains how to efficiently factor 183 distinct RSA keys out of more
than two million 1024-bit RSA keys downloaded from Taiwan's national "Citizen Digital
Certificate" database. These keys were generated by government-issued smart cards that
have built-in random-number generators, and that are claimed to have passed FIPS 140-1
Level 2 certification.
These 183 keys include 103 keys that share primes and that are efficiently factored by a
batch-gcd computation. This is the same typ'e of computation that was used last year by two
.Wustrow,
independent teams (USENIX Security 2012: Heninger, Durumeric, Halderman;
Crypto 2012: Lenstra, Hughes, Augier, Bos, Kleinjung, Wachter) to factor tens of thousands
of cryptographic keys on the Internet.
The remaining 80 keys do not share primes. Factoring these 80 keys requires taking deeper
advantage of randomness-generation failures: first using the shared primes as a springboard
to characterize the failures, and then using Coppersmith-type partial-key-recovery attacks.
This is the first successful public application of Coppersmith-type attacks to keys found in
the wild.
Keywords: RSA, sma"rt ca.rds, integer factorization, Coppersmith, lattices

1 Introduction
In 2003, Taiwan introduced an e-government initiative to provide a national public-key infrastruc-
ture for all citizens. This national certificate service allows citizens to use smarü-card ID cards to
digitally authenticate themselves to government services, such as filing income taxes and modi-
fying car registrations online, as well as to a $owing number of non-government services. RSA
keys are generated by the cards, registered with a government authority, and placed into an online
repository of "Citizen Digital Certificates".
Unfortunately, the random-number generators used to generate many of these keys are fatally
flawed, and have generated real certificates containing keys that provide no security whatsoever.
MAT A BSI-1-6c_3.pdf, Blatt 281

027 6

D J Berristein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

inspect repeated primes,


batch gcd observe patterns,
generalize

Public-key 103
164 patterns
database secret keys
batch trial division

127
secret keys
batch trial division

125
univariate secret keys
Coppersmith
pnmes
primes

\72
secret keys

183
secret keys

Fig. 1. Retrospective summary of the data flow leading to successful factorizations. After successfully
factoring keys using a batch gcd algorithm, we characterized the failures, and used trial division to check
for broader classes of specified primes (input on the right) as exact divisors. We then extended the attack
and applied Coppersmith's method to check for the specified primes as approximate divisors.

This paper explains how we have computed the secret keys for 183 different certificates in use by
real people.

1.1 Factorization technique


Bad randomness is not new. Last year two independent research teams [8, 11] exploited bad ran-
domness to find secret keys for tens of thousands of SSL certificates on the Internet, a similar
number of SSH host keys, and a few PGP keys.
Our starting point in this work is the same basic attack used in those papers against poorly
generated RSA keys, namely scanning for pairs of distinct keys that share a common divisor (see
Sectiou 3). The basic gcd attack, applied to the entire database of Citizen Digital Certificates,
shows that 103 keys factor into 119 different primes.
We go beyond this attack in several ways. First, the shared primes provide enough data to
build a rnodel of the prime-generation procedure. It is surprising to see uisible patterns of non-
randomness in the primes generated by these smart cards, much more blatant non-rarldomness
than the SSL key-generation failures identified by [8, 11]. One normally expects smart cards to
be controlled environments with built-in random-nuinber generators, typically certified to meet
various standards and practically guaranteed to avoid such obvious patterns. For comparison, the
SSL keys factored last year were typically keys generated by low-power networked devices such as
MAT A BSI-1-6c_3.pdf, Blatt 282

a27 7

Factoring RSA keys from certified smart cards: Coppersmith in the wild

routers apd firewalls running the Linux operating system while providing none of the sources of
random input that Linux expects.
The next step is extrapolation from these prime factors: we hypothesize a particular model
of randomness-generation failures consistent with 18 of the cornmon divisors. The same model is
actually capable ofgenerating 164 different primes, and testing all ofthose primes using batch trial
division successfully factors further keys. One might also speculate that the cards can generate
primes fitting a somewhat broader model; this speculation turns out to be correct, factoring a few
additional keys and bringing the total to 125. See Section 4 for a description of the patterns in
these primes
There are also several prime factors that are similar t,o the 164 patterns but that contain
sporadic errors: some bits flipped here and there, or short sequences of altered bits. We therefore
mount several Coppersmith-style lattice-based partial-key-recovery attacks to efficiently find prirne
divisors close to the patterus. The univariate attacks (Section 5) allow an arbitrary stretch of
errors covering the bottorn 40% of the bits of the prirne. 'ihe bivariate attacks (Section 6) allow
two separate stretches of errors. The internal structure of the patterns makes them particularly
susceptible to these attacks. These attacks produce dozens of additional factorizations, raising the
total to 183.
In the end nearly half of the keys that we factored did not share any common divisors with other
keys; most of these were factored by the Coppersmith-style attacks. This is, to our knowledge, the
first publicly described instance of a Coppersmith-style attack breaking keys in the wild.

L.2 Certification
The flawed keys were generated by governmeht-issued smart cards that both the certification
authority and manufacturer advertise as having passed stringent standards certifications. See Sec-
tion 2.1.
It is clear from their externally visible behavior, as shown in this paper, that the random-
number generators used to generate the vulnerable keys actualiy fall far short of these standards.
This demonstrates a faiiure of the underlying hardware and the card's operating system, both of
which are covered by certification. We have no explanation for the discrepancy.

1.3 Observed response and recommended response


When we reported the common-divisor vulnerabilities to government authorities, their respon§e
was to revoke exactly the certificates sharing common factors and ask only those users to regenerate
keys. See Section 7 for more details.
Our further factorizations demonstrate how dangerous this type of response is. Randomness-
generation failures sometimes manifest themselves as primes appearing twice, but sometimes
manifest themselves as primes that appear only once, such as the primes that we found by
Coppersrnith-type attacks. Both cases are vulnerable to attackers with adequate models of the
randomness-generation process, while only the first case is caught by central testing for repeated
primes.
We endorse the idea of centrally testing RSA moduli for cornrnon divisors as a mechanism to
detect some types of randomness-generation failures. We emphasize that finding repeated primes
is much more than an indication that those particular RSA keys are vulnerable: it shows that the
underlying randomness-generation system is malfunctioning. The correct response is not merely to
eliminate those RSA keys but to throw away the entire randomness-generation system, replacing
it with a properly engineered system and to revok€ all keys generated with that generation of
hardware.
We also emphasize that an absence of common divisors is not an indication of security. If
the primes generated by these smart cards had been modified to include a card serial number
as their top bits then the keys would have avoided common divisors but the primes would still
have been reasonably predictable to attackers. Our work illustrates several methods of translating
different types of malfunctioning behavior into concrete vulnerabilities. There are many potential
MAT A BSI-1-6c_3.pdf, Blatt 283

027 B

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

vulnerabilities resulting from bad randomness; it is important to thoroughly test every cornponeut
of a random-number generator, not merely to look for certain types of extreme failures.

2 Background
2.1 The Taiwan Citizen Digital Certificate program
Taiwan's Citizen Digital Certificates (CDCs) are a standard means of authentication whenever
Taiwanese citizens want to do business over the Internet with the government and an increasing
number of private companies.
CDCs are issued by the Ministry of Interior Certificate Authority (MOICA), a level 1 subordi-
nate CA of the Taiwanese governmental PKI. Since the program's launch in 2003, more than 3.5
rnillion CDCs have been issued, providing public key certificate and attribute certificate services.
These digital certificates form a basis for the Taiwanese government's plan to migrate to electronic
certificates from existing paper certiflcates for a rauge of applications including national and other
identification cards, driver's licenses, and various professional technician licenses.
Taiwanese citizens can already use the CDC to authenticate themselves to a nurnber of govern-
ment agencies over the Internet, in order to file personal income taxes, update car registration, and
make transactions with government agencies such as property registries, national labor insurance,
public safety, and immigration. In addition, the CDC is accepted as a means of authentication by
a variety of organizations such as the National Science Council, several local governments, and
recently some private companies like Chunghwa Telecom.

Cert'if,cate regis,tration: In order to generate a CDC, a citizen brings their ID card to a government
registration office. A government official places the (smart) ID card into a registration device. The
device prompts the card to generate a new cryptographic key, and the public key is incorporated
into a certificate which is signed by MOICA. The certificate is made available in a database online
for authentication purposes. In general, an individual will have two certificates: one for signing,
and one for encryption, each with distinct keys.

Standards certifications; MOICA states that these cards are "high security", and "have been
accredited to FIPS 140-1 level 2" , ald also that "It is impossible to get key date from Certificate IC
card". (See [13] and Appendix B.) For comparison, the SSL keys factored last year were generated
by software-hardware combinations that had never claimed to be evaluated for cryptographic
security, such as Linux running on a home router.
Public information indicates that at least two different manufacturers have been involved in
Taiwan's smart-card ID program. On the basis of various metadata surrounding the factored keys,
we conclude that most, possibly ail, of the problems we have identified are limited to cards from
the more recent of these two manufacturers.
The supplier's website states "Certification Authority of Ministry of Interior: Citizen digital
certificate" as a use case. The chip has passed Common Criteria EAL4+ certification and the card
and card operating system have been accredited to FIPS 140-l level 2 [14]. This was confirmed in
private communication with this supplier.
It is clear from our results that the random-number generators used in these cards are in fact
flawed, and that any keys generated using these cards should be considered insecure.

2.2 Collecting certiflcates


In March 2012, inspired by the results of [8] and [11], we retrieved 3002273 CDCs from the MOICA
LDAP directory at ldap://moica.nat.gov.tw. Out of these RSA keys, 2257569 use 1024-bit RSA,
while the remaining 744704 use 2048-bit RSA.
The 1024-bit CDCs contain 2086177 distinct moduli, of which 171366 moduli appear more
than once. The repeated moduli appear to all be due to expired certificates still contained in the
database which contain the same keys as newer certificates issued to the same individuals.
MAT A BSI-1-6c_3.pdf, Blatt 284

027 e

Factoring RSA keys from certified smart cards: Coppersmith in the wild

2.3 Random Number Generation


While generating high-quality random-numbers is critical to the security of cryptographic systems,
it is also notoriousiy difficult to do. Non-deterministic behavior is considered to be a fault in almost
every other component of a computer, but it is a crucial corrponent of generating random numbers
that an attacker cannot predict. Several national and international standards for random number
generation [15, 1, 6] specify correct behavior for these types of systems. In general, software pseudo-
random number generators require a significant amount of entropy before their output is useful
for cryptographic purposes.
As we will see later in the paper, the smart cards used in the PKI we examined fail to follow
many well-known best practices and standards in hardware random number generation: they
appear to utilize a source of randomness that is prone to failing, they fail to perform any run-titne
testing before generating keys, and they clearly do not apply any post-processing to the randomness
stream. The lack of testing or post-processing causes the initial randomness-generation failure to
be much more damaging than it would have been otherwise.

Analog RNG circuitsr An analog circuit is the standard choice when hardware designers have the
iuxury of designing dedicated circuits for random-number generation. An analog circuit allows the
designer to obtain randomness from simple quantum effects. While the use of radioactive decay is
rare in commercial products, the quantum noise exhibited by a current through a suitably biased
diode can be amplified and sampled to deliver an entropy source of very high quality.

On-ch'ip RNG circuits: Mixing analog and digitai circuits on the same die is costly, so chip designers
often seek other sources of unpredictability. These sources can include variation in gate propagation
delays or gate metastability, which exhibit inherent randomness. Designers can explicitly harness
gate-delay variation by building sets of free-running ring oscillators and sampling the behavior at
hopefully uncorrelated intervals. To take advantage of randomness in gate metastability, designers
build circuits that output bits based on the tirne it takes for the circuit üo settle to a steady state,
a variable which should be hard to predict. These designs are often tricky to get right, as the
chip fabrication process can reduce or eliminate these variations, and subtle on-chip effects such
as inductive coupling or charge coupling between components can cause free-running oscillators to
settle into synchronised patterns and metastable circuils to predictably land one way or the other
depending on other components nearby on the chip.

Handl'ing Entropy Sources: Even with perfectly unpredictable source of randomness, care needs to
be taken to convert the raw signal into usable random numbers. Generally, designers characterize
circuits in advance to understand the entropy density test the signal from the entropy source at run
time, and run the output through a cornpression function such as a cryptographically secure hash
function. These practices are required by a number of security süandards such as FIPS 140 [14].

3 Batch gcd
This section reviews the approach of [8, 11] for detecting common factors in a collection of RSA
keys, and reports the results of this approach applied to the collection of Citizen Digital Certifi-
cates.
If there are two distinct RSA rnoduli .lüt : pqr and N2 - pq2 sharing exactly one prime factor
p, then the greatest common divisor of 1[1 and .lüz will be p. Cornputing this gcd is fast, and
dividing it out of l( and -lü2 produces the other factors q1 and Q2.
Of course, this type of vulnerability should never arise for properly generated RSA keys. How-
ever, since [8,11] had observed weak random-number generators producing keys with repeated
factors in the wild, we began by checking whether there were repeated factors among the Citizen
Digitai Certificates.
MAT A BSI-1-6c_3.pdf, Blatt 285

0280

D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

Instead of the naive quadratic-time method of doing this computation (checking each .lü1

against each N2), we used a faster batch-gcd algorithm using product and remainder trees described
in [2,8]. We used the C implementation available athttps:f f fantorable.net/resources.html.
We ran this impiementation on the 3192962 distinct RSA moduli and found that 103 moduli
were factored due to nontrivial common factors. This computation, parallelized across four cores
of a 3.lGHz AMD FX-8120, finished in just 45 minutes.

Attacking patterned factors


A properiy functioning random number generator would never generate identical 512-bit primes,
so the discovery of repeated prime factors described in the previous section immediately indicates
that the random-number-generation process producing these keys is broken. This section analyzes
the structure ofthe repeated factors generated by the flawed random-number generator and designs
a targeted attack against this structure.
The 103 moduli with repeated factors show a remarkable distribution of the shared factors; see
Figure 2. The complete list of factors found using the GCD approach is given in Appendix A.
One prime factor, p110, appears a total of 46 tirnes with different second primes. The hexadec-
imal representation of this factor is
c000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000002f 9

which is the next prime after 2511 4 2570 .


The next most common factor, repeated 7 times, is
c9 242 49 2249292 49 9 2 49 49 2 4 49 2 4249 2249 29 249 92 49 492 4 49 24249 2249 29 249
9 249 49 2 449 242 49 2249 29 249 9249 49 2 44924249 2249 29249 I 249 49 2449 2424 e5

which displays a remarkable periodic structure. The binary representation of this integer, excluding
a few most and least significant bits, is a repeated sequence ofthe string 001 with a "hiccup" every
16 bits.
Nearly all of the shared prime factors had a similar and immediately apparent periodic struc-
ture. Wc hypothesized that nearly every repeated prime factor had been generated using the
following process:

1. Choose a bit pattern of length 1, 3, 5, or 7 bits, repeat it to cover more than 512 bits, and
truncate to exactly 512 bits.
2. For every 32-bit word, swap the lower and upper 16 bits.
3. Fix the most significant two bits to 11.
4. Find the next prime greater than or equal to this number.
We generated the 164 distinct primes of this form corresponding to all patterns of length 1, 3,
5, and 7 and tested divisibility with each modulus. This factored a total of 105 rnoduli, including
18 previously unfactored moduli, for a total of 121.
None of the repeated primes exhibit a (minimal) period of length 9 or larger. On the other
hand, the data for period lengths 1, 3, 5, 7 shows that patterns with longer periods typically appear
in fewer keys than patterns with shorter periods, and are thus less likely to appear as divisors of
two or more keys, raising the question of whether there are primes with Iarger periods that appear
in only one key and that are thus not found by the batch-gcd computation. We therefore extended
this test to include length-9 periods and length-11 periods. The length-9 periods factored 4 more
keys but the length-11 periods did not factor any new keys, leading us to speculate that 3,5, and
7 are the only factors of the period length. We then ran a complete test on all length-l5 patterns
but did not find any further factors. The total number of certificates broken by these divisibility
tests, together with the initial batch-gcd computation, is 125.
MAT A BSI-1-6c_3.pdf, Blatt 286

0281

Factoring RSA keys from certified sm f,s: Coppersmith in the wild

Fig.2. Relationships between keys with shared factors. Each ellipse represents a prime; edges connect
prime factors dividing the same modulus.

Sporad'i,c eryors: The handful of shared prime factors in our sample of gcd-factored keys that did
rot match the above form were differing from patterns in very few positions. We experimented with
finding more factors using brute-force search starting from 0xc0. . .0 and found a new factors, but
these factors are more systematically and efficiently found using LLL in Coppersmith's method,
as described in the next section.

5 UnivariateCoppersmith
Several of the factors computed via the GCD algorithm in Section 3 follow the bit patterns
described in the Section 4, but are interrupted by what appear to be sporadic errors. Coppersmith's
method [5,4] factors RSA rnoduli if the top bits of thö primes are known, which matches our
situation if the errors appear in the bottom few bits of a factor. This section presents this method
following the variant by Howgrave-Graham [10] for lattices of dimension 3 and 5 and gives an
outlook of how more keys could be factored.
The idea is as follows: we assume that some prime factor p of N is of the form

P: a'+ r
MAT A BSI-1-6c_3.pdf, Blatt 287

a282

D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

where is a 512-bit integer known to us (one of the bit patterns described in the previous section)
@

aud ris a small integer error to account for a sequence of bit errors (and incrementing to next
prime) among the least significant bits of p.
In the Coppersmith/Howgrave-Graham method, we can write a polynomial

f(r):o+*
and we would like to find a root r of / modulo a large divisor of I{ (of size approximately Nr/z * p).
Let X be the bound on the size of the root we are searching for. We will use lattice basis reduction
to construct a new polynomial g(e) where g(r) :0 over the integers, and thus we can factor g to
discover it.
We construct the lattice -L as
lx2 xa o1tt
|0 "lx
L0 0 r{.J
corresponding to the coefficients of the polynomials N,f(Xr),Xrf (Xx), apply the LLL lattice
basis reduction algorithm [12], and regard the shortest vector in the reduced basis as the coefficients
of a polynomial g(Xr). Then we compute the roots ri of g(r) and check if a * r.i divides ly'. If so,
we have factored -l[.
Any lattice vector is a linear cornbination.of / and .l{ and is thus divisible by p. A prime p is
found by this method if 9(16): 0 mod p holds not only modulo p but over the integers. The latter
is ensured if the coefficients of g are sufficiently small. The shortest vector u1 found by LLL is of
length
< 2(di'r-t)/a(det L)l/ dim r'
lt,1 | ,

which must be smaller than p for the attack to succeed.


In our situation this translates to
,ttz 7Xs N)l/s . 1trr/z <+ X< Z-1/2 Nr/6 ,

so for -l{- 27024 we can choose X as large ffi 2t7o , meaning that for a fast attack using dimension-
3 lattices up to the bottom third of a prime can deviate from the pattern a. In the following
we ignore the factor 23imL-t)/a since all lattices we deal with are of small dimension and the
contribution compared to lI is negligible.

5.1 ExperimentalResults
A straightforward implementation using Sage 5.8 took about one hour on one CPU core to apply
this method for one of the 164 patterns identified in Section 4. Running it for all 164 patterns
factored 160 keys, obviously including all 105 keys derived frorn the patterns without error, and
found 39 previously unfactored keys.
It is worth noting that the 160 keys included all but 2 of the 103 keys factored with the GCD
method, showing that most of the weak primes are based on the patterns we identified and that
errors predominantly appeared in the bottom third of the bits. The missing 2 keys are those
divisible by 0xe0000...0f. Including 0xd0000...0, 0xe0000...0, 0xf0000...0 as additional
bit patterns did not reveal any factors beyond the known ones, ruling out the hypothesis that the
prime generation might set the top 4 bits rather than just 2. Instead this prime must have received
a bit error in the top part.

5.2 Handling more errors


Coppersmith's method can find primes with errors in up to 712 of their bits using lattices of
higher dimension. Getting close to this bound is prohibitively expensive, but trying somewhat
Iarger dimensions than 3 is possible. For dimension 5 we used basis

{N2, N f (nx), f'(*x),rx f2(rx),(rx)z 721rx)\


MAT A BSI-1-6c_3.pdf, Blatt 288

0283

Factoring RSA keys from certified smart cards: Coppersmith in the wild

which up to LLL constants handles X < Nr/5, i.e. up to 204 erroneous bottom bits in p for 1ü of
1024 bits. The computation took about 2 hours per pattern and revealed 6 more factors.
We did not use higher dimensions because the "error" patterns we observed are very sparse
making it more profitable to explore multivariate attacks (see Section 6).

5.3 Errors in the top bits


The factor 0xe000. . . f (2511+25t012r0e-1.15) appeared as a common factor after taking GCDs but
was not be found by the lattice attacks described in this section starting from the basic patterns
described in Section 4. Coppersrnith's attack also works to search for errors in higher bits ofp by
defining the polynomial / as f (r) : a * Ztr. Here t is the offset location of the errors we hope to
learn and the same rnethod will find errors of the form Ztr withr < X.
However, since we hypothesize that the prime factors are generated by incrementing to the next
prime after a sequence of bits output by the flawed RNG, we do not know the least significant bits
of o because they are modified in the prime generation process. This problem can be overcome
by brute forcing the least significant bits of the pattern a. This can be handled at the expense
of running this attack for more strings a: For each of the 164 basic patterns include all 2--1
variations of the bottorn rn bits with the LSB fixed to 1. This will find factors if finding the next
prime from the base string did not require more than those bottom rn bits to change.
A brief analysis suggests that for this attack to have a 50% chance of success, we need to
study 128 new patterns for every old pattern: By Cramer's conjecture the chance that a number
of size z is prirne is approximately 1/ ln z. See [7] for an overview aud more precise statements.
In our case of primes around 2512,each number has about all355 chance of being prime. Since
1 - (1 - 11355)256:0.514290, trying 128 patterns for the bottom eight bits for odd patterns has
a 50% chance of covering a sufficiently large interval to find a prime. For our implementation this
computation would take 20992 core hours or close to 2.5 core years. It is fairly likely that more
factors would be found with this search but the rnethod presented in the following section is more
efficient at handling erors in top and bottom positions uuless a very large portion of the top bits
are erroneous.

6 BivariateCoppersmith
The lattice attacks described in the previous section let us factor keys with unpredictable bits
occurring in the least significant bits of one of the factors, with all of the remaining bits of the
factor following a predictable pattern. In this section, we describe how we extended this attack to
factor keys with unpredictable bits among the middle or most significant bits of one of the factors,
without resorting to brute-forcing the bottom bits.
In the basic setup of the problem, we assume that one of the factors p of 1ü has the form
p: a+2tstr
*h"." o is a 512-bit integer with a predictable bit pattern (as described in Section 4), t is a bit
offset where a sequence ofbit errors s deviating frorn the predictable pattern in o occurred during
key generation, and r is an error at the least significant bits to account for the implementation
incrementing to ühe next prime.
To apply Coppersmith's method, we can define an equation f (*,A) - a+2trlU and try to use
lattice basis reduction to find new polynornials Qi(r,g) with the property that if /(s,r) vanishes
moduio a large unknown divisor p of ,Ä[ and s and r are reasonably small, then Qi(s, r) : 0 over
the integers. In that case, we can attempt to find appropriate zeros of Qi. The rnost common
method to do this is to look at multiple distinct polynomials Qi and hope that their common
solution set is not too large.
These types of bivariate Coppersmith attacks have many cryptanalytic applications, perhaps
most prominently Boneh and Durfee's atüack against RSA private key d < No'n [3].Our ap-
proach .is very similar to that described by Herrmairn and May for factoring RSA moduli with
MAT A BSI-1-6c_3.pdf, Blatt 289

0284

10 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

bits known [9], although for the application we describe here, we are less interested in optirnal
pararneters, and more in speed: we wish to find tire keys most likely to be factored using very low
dimensional lattices.

Algebrai,c independ,ence: Nearly all applications of multivariate Coppersmith methods require a


heuristic assumption that the attacker can obtain two (or several) algebraically independent poly-
nomial equations determined by the short vectors in a Lll-reduced lattice; this allows the attacker
to compute a finite (polynomially-sized) set of comrnon solutions. Most theorem statements in
these papers include this heuristic assumption of algebraic independence as a rnatter of course,
and note briefly (if at all) that it appears to be backed up experimentally.
Notabiy, in our experiments, this assumption d'id, not hold in general. That is, most of the
time the equations we obtained after lattice basis reduction were not algebraically independent,
and in particular, the algebraic dependencies arose because all of the short vectors in the lattice
were polynomial multiples of a single bivariate linear equation. This linear equation did in fact
vanish aü the desired solution, but without further information, there are an infinite number of
additional solutions that we couid not rule out. However, we were often able to find the solution
using a simple method that we describe below.
Herrmann and May [9] describe one case where the assumption of algebraic independence did
not hold in their experirnents, namely when X and Y were significantly larger than the values of
s and r. Similar to our case they observed that the polynomials of small norm shared a common
factor but unlike in our case this factor was the original polynomial /. Note that the linear
polynomial in our cabe does vanish over the integers at (s, r) while / vanishes only modulo p.
We experimented with running smaller dimensional lattice attacks in order to generate this
sublattice more directly. The attack worked with smaller degree equations than theoretically re-
quired to obtain a result, but when we experimented with lattices generated from linear equations,
this sublattice did not appear. Note that we specify a slightly different basis for the lattice, in
terms of monomial powers rather than powers of /, which may have an effect on the output of the
algorithm compared to the examples in [9] and might explain why we find a usdful linear equation
in the sublattice instead of the useless factor f.

6.1 Implementation details


Lattice construction: Our lattice is constructed using polynomial multiples of / and Iy' up to
degree k vanishing to degree 1 modulo p. Let X and Y be bounds on the size of the roots at r
and gr we wish to find. Our lattice basis consists of the coefficient vectors of the set of polynomials

{.1ü, rX.lü, f , (r X)2 N, (, x) f , . . ., (yy)o-' (r X) f , (yY)k- f ),


1

using coefficients of the monomials {1,r, U,x2,...,Ak-Lr,gk}. The determinant of this lattice is

det.L : ryn+t176f ;(*ä').

and the dimension ir (*l') . Omitting the approximation factor of LLL, we want to ensure that

(detLlt/ai-t .o
xr (-t'))'' t')
(r
(1,.r+
r
1Nt/z

So for l{ = 21024, setting k : 3 shoutd let us find XY < 2702 arld /c : 4 should let us find
XY < 2128. The parameter choice k : 2 results in a theoretical bound XY < 1, but we also
experimented with this choice; see below.
MAT A BSI-1-6c_3.pdf, Blatt 290

0285

Factoring RSA keys from certified smart cards: Coppersmith in the wild 11

Soluing for solutions: After running LLL on our lattice, we needed to solve the system ofequations
it generated over the integers to find our desired roots. The usual method of doing this in bivariate
Coppersmith applications is to hope that the two shortest vectors in the reduced basis correspond
to algebraically independent polynomials, and use resultants or Gröbner bases to compute the set
of solutions. Unfortunately, in nearly all of our experiments, this condition did not hold, and thus
there were an infinite number of possible solutions.
However, a simple method sufficed to compute these solutions in many cases. In general,
the algebraic dependencies arose because the short vectors in the reduced basis corresponded to
a sublattice of multiples of the same degree-one equation, with seemingly random coefficients,
which vanished at the desired roots. (The coefficient vectors were linearly independent, but the
underlying polynomials were not algebraically independent.) The other polyuomial factors of these
short polynomials did not vanish at these roots. This linear equation has an infinite number of
solutions, but in our experiments our desired roots corresponded to the smallest integer solution,
which we could obtain by rounding.
Let
ut1-aY-w:0
be an equation we want to solve for r and y.If u and u are relatively prime, then we can write
c7u + c2u: 1, and parametrize an integer family of solutions

fr:cru+az
Y:c2w-uz
withz:c2fi.-c1!.
In experiments with the already-factored moduli, we observed that the solution was often the
minimum integer value of r or A among the solution family. So we searched for z among the
rounded values of -c1wf u aod c2wf u.
For the handful of cases where the lattice did result in independent equations, we computed
the solutions using a Gröbner basis generated by the two shortest vectors.

6.2 Experimental results


We ran our experiments using Sage 5.8 parallelized across eight cores on a 3.1GHz AMD FX-
8120 processor. We used fpLLL for lattice basis reduction, and Singular to factor polynomials and
compute Gröbner bases. For each lattice, we attempted to solve the system of equations either by
factoring the polynomial into linear factors and looking for small solutions of the linear equations
as described above or using Gröbner bases.
We attempted to factor each of the 2,086,171 1024-bit moduli using several different parameter
settings. For k : 3, we had 1O-dimensional lattices, and attempted to factor each modulus with
the base pattern a:0 using Y :23o, X:27o, and f : 442.We then experimented with k:4
Y : 228 and X - 2700, which gave us l5-dimensional lattices, and experimented with a ba,se
pattern o - 2571 * 2sto and five difierent error offsets: t : 0 with Y - 2128 and X : 1, and
t:128,t:228,t:328,andt:428withY:228andX:2Too.Finaily,weexperimentedwith
theclroicek:2,X:4,Y:4andthechoicesoftandousedinthek:4experiments,which
used 6-dimensional iattices and theoretically should not have produced output, but in fact turned
out to produce nearly all of the same factorizations as the choices above. The choice k : 1 with
the same parameter choices as k:2 did not produce results.

6.3 Handling more errors


Ftom these experimental settings, it seems likely that many more keys could be factored by different
choices of parameters and initial pattern values; one is limited merely by tirne and computational
resources. We experimented with iterating over all patterns, but the computation quickly becomes
very expensive.
MAT A BSI-1-6c_3.pdf, Blatt 291

az1 6

12 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

k logr(XY) ff t ff factored keys f alg. indep. eqns. running time


245105 3 4.3 hours
3 i00 1 112 - 2 hours
4 128 5 109 4 20 hours
Table 1. E*perime Proach, using the
parameters listed in the text. Where we collected data, we noted the very small number of cases where the
lattice produced algebraically independent polynomials; all of the other cases were solved via the heuristic
methods described above.

Patterned, factors: Mysteriously, using the base patterns a:0 and a:2571 125'o, the algorithm
produced factorizations of keys with other patterned factorizations. This is because the product
of the bit pattern of the relevant factor multiplied with a small factor produced an integer of the
form we searched for, but we are as yei unable to characterize this behavior in general'

H,igher powers o/p: Similar to the univariate case we can construct higher-dimensional lattices in
which each vector is divisible by higher powers of p, e.g. using multiples of N2,I{/, and /2 for
divisibility by p2. However, this approach is successful in covering larger ranges of XY only for
lattices of dimension at least 28.

More aari,ables: More isolated errors can be handled by writingp : o+Ii:r 2t's1 with appropriate
bounds on the s.i I X,i. so that the intervals do not overlap. The asymptotically optimal case is
described in [9] and reaches similar bounds for f[f:, X1 as in the univariate and bivariate case.
However, the lattice dimension increases significantly with c. For c : 3, i.e. two patches of errors
together with changed bottom bits to generate a prime, the condition (det.L)di't/z < p holds
only for lattices of dimension at least 35 at which point X1X2Xa ( Iül/la can be found. A lattice
of dimension 20 leads to the condition X1X2Xy < 1. A sufficiently motivated attacker can run
LLL on lattices of these dimensions but we decided that factors found thus far were sufficient to
prove our point that the srnart cards are fatally flawed.

7 Disclosure and response


Our GCD factorization results were publicly announced in a talk in Taiwan in July 2012. We
shared the list of compromised certificates with MOICA. Despite the clear indication of a problem
with the system for generating random numbers, MOICA responded merely by (1) revoking the
factored certificates and (2) asking each of the affected individuals to come in to regenerate keys.
We contacted a sample of the affected individuals; they informed us that they were not issued new
cards.
Several of the rnore recently factored keys described in this paper are still valid. This means
ihat MOICA or the supplier behind the cards has not understood the problem identified via the
GCD computation to be a more widespread problem with the smart cards.
Instead MOICA appears to have changed the query policies on its LDAP server; the server no
Ionger responds to our queries. However, it is still possible to download Citizen Digital Certificates
from MOICA through a web-based interface under "Query of Certification" of "Certificaüe Ser-
vices" on http://moica.nat.gov.tw/html/en/index.htm. Interestingly, the Chinese version of the
web interface requires much less information to query a certificate than the English version.
We emphasize thaü the randorn-number gererators used in these cards obviously do not meet
even minimal standards for collecting and processing entropy. This is a structural flaw in the cards,
and it can be expected to continue causing problems until all of the cards are replaced.

References
1. ANSI. ANSI X9.31:1998: Di.gi.tal Si,gnatures [Jsing Reuersible Pubkc Key Crgptography for the Finan-
cial Seruices Industry (rDSA). American National Standards Institute, 1998.
MAT A BSI-1-6c_3.pdf, Blatt 292

0287

Factoring RSA keys from certified smart cards: Coppersmith in the wild 13

2. Daniel J. Bernstein. How to find the smooth parts of integers, May 2004.
httpt / / u.yp.to/papers.htmlfsmoothparts.
3. Dan Boneh and Glenn Durfee. Cryptanalysis of RSA with private key dless 15^n n0'292.In Jacques
Stern, editor, EUROCRYPT,volume 1592 of Lecture Notes i,n Computer Science,pases 1-11' Springer,
1999.
4. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. J.
Cryptology, 10(4) :233-260, 1997.
Don Coppersmith. Finding a small root of a bivariate integer equation; factoring with high bits known.
In Ueli M. Maurer, editor, EUROCRYPT, volume 1070 of Lecture Notes'in Computer Sci,ence, pages
178-189. Springer, 1996.
6. Bundesamt für Sicherheit in der Informationstechnik. Evaluation ofrandom number generators,2013.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Zertifierung/Interpretation/Evaluation-of-random-number-gener
and https://www.bsi.bund.de/DE/Themen f ZerlifizierwgundAnerkennungf ZertifizierungnachCCundlTSEC/Anwendungshin
7. Andrew Granville. Harald Cram6r and the distribution of prime numbers. Scand. Actuari,al J.,
1995(1):12-28,1995.
8. Nadia Heninger, Za,kir Durumeric, Eric Wustrow, and J. Alex Halderman. Mining your Ps and Qs:
Detection of widespread weak keys in network devices. ln Proceedings of the 21st USENIX Security
Symposium, August 2012.
9. Mathias Herrmann and Alexander May. Solving linear equations modulo divisors: On factoring given
any bits. In Josef Pieprzyk, editor, ASIACRYPT, volume 5350 of Lecture Notes in Computer Science,
pages 406-424. Springer, 2008.
10 Nick Howgrave-Graham. Approximate integer common divisors. In Joseph H. Silverman, editor,
CaLC, vofume 2746 of Lecture Notes i,n Computer Science, pages 51-66. Springer, 2001.
11. Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, and
Christophe Wachter. Public keys. In Reihaneh Safavi-Naini and Ran Canetti, editors, CRYPTO,
volume 7417 of Lecture Notes in Computer Science, pages 626-642. Springer, 2012'
12. Arjen K. Lenstra, Hendrik W. Lenstra jun., and LaszllLovdsz. Factoring polynomials with rational
coefficients. Math. Ann., 261:515-534, 1982.
i3. MOICA. Safety questions, 2013. http://moica.nat.gov.tw/htmllenll2lfaq22-066-090.htm.
14. National Institute of Standards and Technolog'y (NIST). Security requirements for crypto-
graphic modules. Federal Information Processing Standards Publication (FIPS PUB) 140-
2, May 2001. http://csrc.nist.gov/publications/fips/fipsI4O-2/fipsl4}2.pdf, updated 2002-12-03.
See http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf for differences between this and
FIPS-140-1.
15. National Institute of Standards and Technology (NIST). Recommendation for random number gen-
eration using deterministic random bit generators. NIST Special Publication (NIST SP) 800-90A,
January 2012.

A Appendix: Raw data


The following data presents all primes found using the GCD method (Section 3); the initial number
indicates how often that particular prime was found.
46, OxcOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0oOOOOO0000000000000000000000000o00000000000000000000000002f9
7, 0xcg2424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424es
7, OxcOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO00000000000000000000000O00000000000000O0000000101ff
6, 0xd24949244924249224929249s24949244924249224929249s24949244924249224929249924949244924249224929249924949244924249224929249924949d7
4, 0xf6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbbodbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdbc1
4, Oxdb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6c6e23
4, Oxedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db65db5b867
3,0xd084084242102LOAOA42A42L2LOA|OA4A42L42L0!OA4084242LO2LO808428421210810848421421010840A4242|O270AOA42842!21OA70A4A42142101084098s
2, OxeOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO00000000000000000000000000000000000000000000000000000f
2, OxfSadsad6d6b56bSaEad6ad6b6bSabSadatl6bd6bSbSadSad6d6bS6bSaSad6ad6b6bSabSadad6bd6b5bSadsad6d6bS6b5aSad6ad6b6bSabSadadSbd6bSbSadSd39
2,0xc28550a128500a14850aa14250a114280a144285a7422A5O742AA5Oa428550a128500a14850aa14250a114280a744285a!4228501428850a428550a128500a61
2, OxfdefdefTfTbalTbdedefTefTbTbdebalefefTbfTbdbdefd€fTfTbdTbdedefTefTbTbdebdefefTblTbdbdefdefTJTbdTbdedefTelTbTbdebdefefTbfTbdbdefe0bl
2, O1d24g4g244g2424s22492924992494924492424922492924992494924492424922492924992494924492424922492924992494924492424922492924992484a,t
2, 0xe94a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a529294a94a5a529529494a64a525294294a4a52a529294b9afs
2, Oxdb6d6db66db6b6dbb6dbdb6ddb6d6d.b66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db5b6dbb6dbdb6ddb6d7015
2, Oxc412a'2g2g4a94a5a52952949 4a54d525294294a4a52a529294a94aSa529529494a54a525294294a4a52a529294a94a5a529529494a54a525294294a4a52a601
2, OxcOOOOOOOOOOOOOOOOOOOOOO0oOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO000000000000000000000000000000000000000000000000002030b
2,0xd8c68c63631831ec8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c69107
2,0xf18c18c0c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c1907
2 , OxfTbd7bdedefZetTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdS2ag
2, O\c4214270!0840842421021080A42842L270A!OA48421421010840842427027080842A42121081084842142|070A40A4242702108084284212108108484214369
MAT A BSI-1-6c_3.pdf, Blatt 293

O2BB

t4 D J Bernstein, Y-A Chang, C-M Cheng, L-P Chou, N Heninger, T Lange, N van Someren

0xefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbfTbdbdefdefTfTbdTbdedefTefTbTbdebdefefTbf969
0xd4e682e94f 1d6018a02056c0db850a74b3591b0f8405t4ce40L7b2t5d25925ba2429a66e384bSbe96e6a0a03d4a11eba10416018de3b3e354477250037b6f813
0xcac05beSc1€abfOc21f8e95ceSd3cO777904282dltdOcL738d727 e197a0a32fda4cc59cc50b99d29f7fa8d07c972402ab88573e255db6bab05505812c73c291L
0xcf052499061243cd82cd1b2059446c963487834d929ac929d92b259245254c7828ed3e92259292c924d24947d4896d1545f4001029b3b265d0ea4dL44e242dbd
cxta94a972e2d,cf.f068ee1257e228b53e9b9fcf46877f07daaa4d13c2bedf 132d07730f549f4691168553f84be8ff405f 16a663d8fb8f82987bd9e073a8108edc3
0xefTbefbdbdef9ef6fTbdTbde9efTefTbTbddgdciefTb3Tbdgfedd€fTbTbdTbdEdee6ef3bSbde3deTedTbfa99adebdefTbTbdTTdTcff leeTbTbdebdeeefT9fBab
0xeeb29 19e1dc9ce33c2a0d9e190465b164a53c7c03e9a3d009ecf8fd6bdt743e04444332b7 ff4a0e8f53b5123a5422563a06t487 cd6cb5f36cd541 1t0a€4dbc69
0xf51576e530188d5gbbcSf4f6ec9e824d7 age7O742952b11c49a6f38188adgdbe3d29d1d9498b7aeffc4dgb042Of77895f62e2a7b79d,4887e45b6227e0b84fb97
0xd83f 22a49af 67d7f 196df 580d51 c1f931ef7f09af2f880de26d88cbf24567302a0d6eed7c8eab859aaoc 1cc18bd8efacdce194c13
0xc1df3e8dbSf7b7f456edc 1f60d23f60360536565836c€37af6f02e55de24a8dc373f3cSd49c93ba6fee0d44d08bc5fb0655781 adee5c05777fd4da2bcd803dOf
0xe279872638463a0a32a1412b13efccfaSed68db44963c7f6955a3816bcaa33f94794c8b75298ddf4a8664e485ef99e6d9469{5187939e395cb1f09e666786741
0xce73e73939ce9 ce7 e738739c9ce7 ce73739c39cece73e73939ce9ce7e739739c9ce7ce73739c39cece73e73939ce9ce7e739739cgce7ce73739c39cece73ead7
0xd92ae5c6453ef ec55c5674207827d,e2b77bf3ef027f4230f8aac1fdgb0d69fdc61934132766f8dd1d8cb22ec38d834037eff6d9dd3535b9e582fbdd2327 cgces
0xc080000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000001003f
0xfffTfffffefffffffffffftffffftfteTffttttTf.ffffffffffffffftfiffdTflffffbffffffTbfffbfcffffTfffffifffbf00000000000000000000000000cl
0xeb6f80ff65b4a6d462cfa59611542f25e207667752b0482fsacgdc091f4dc854de9c73b288aaa5da5298a33928f7b2920f89b81e3635932bc9db99a34e52b82b
0xfdfTbgbffbffdebeb2SS92bT6f69bbffbffdafaeffd9fTbdf 1ee7bfa6e2f33bb67d5asb5676d2bf6a1de3626f06be367ffde73db1e01f5d3855f21f0eda8b4db
oxe643203b22b404A4272L0bd390d45a3a62ac 132c0063990067686123d5OL288L2eO947L127098400c841e0918340043 1018100a2b1cc0954c0405026420e8c7t
oxff ef et 7f f de6ff ffTff fffbfffffffbff effbffdfffffffffffffffffJffffffffffl f ff f 1 f cf t ff ef46fffdf dftfTf ffff fifffffffffrf ff f eefef eceff e8d
0xf6dbdb6ddb6d6db66db6b6dbbodbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66b37b6dbo19a4697
oxcooobSoooooooooooooooooooooooooooooooooooooo00ooooooooooooooooooooooo6Sooooooooooooooooooooooooo0o0oooooooooooooooooooooooboozsr
0xccc5eblea2f4beb8b62df ef5429f97f06af0af8d08159d21df4540a0197ffdb8386c8ebb18bd70b0f46c9615d2fcd0€a38a2cadb522cf.79t2c3ab27 d9564a197
0xedb6b6dbb6dbdb6ddb6d6db66db6b6dbb6dbdb6ddb6d6db66db6b6dbb6dadb6dgb6f6db66da6b6fbf6cb9b7ddb656d9e6d36a7dbb673ba6ddb6f6db66df6bSe5
0xe7fa15abOc3d2c3d1396Of598cd2bbf74a68858OeSfdc7OO64563a1O558f 1dfd36d5e8aec88897c79d73ebdcbec 1b5f0121 175c'8aae69e3a31a63f9€66eObf c5
0xffb308867f€s1 6267f.eb2braf2!2ffefffffe4308866fffSfffefe13ffcf869aff4bf907ff 1f9393fff0fff3fff ctff7ff3ef703ffaa8c7ffffe491affeff3b1
0xc010208a48c 1802721,081084A42742301Oa40a4242006309ca468d2123081084a52043100Oc4}a42527O270a084a8ce1290810cc84204a901 1ac284240!O22e!
Oxe739729a9ce7ce73539c29coc126e7383b8e8gbd2207taed08428427378c1084c410631858c68c63e31035.cc8c63ce31318810c64331231818c60e63623b32a3
0xfeb1b9efa29f64ed53628a10a924b5268163dd887f653a6b82edb063b6874c2039e4938018ab949a3c28cdc785fe2be58872c0c8a9ec5171e37ea6a82dSd46d7
0xc0100000000000000000000000009000004260400c000000000018000000000040208000000000202000010800000000000000000000000000028000000002f3
0xf9d5834f918b673e1f7eaae3cc5d97dd2706dd8de9cSb2fb€f679b2c196933fe30f62ac3f7fcc1c593fb63a0bbb8838b8486eac959cc3949ea9182c46396fbcb
0xdac45d37aadacfec73b3184ef43d52d6314754abd38414dde03ade396bd809aa281 1047f015c9c71fOcbboa91028190adeacc36165b0e0e6fce64549f947e0d5
0xf49808713746a41a331625a7cb38961 1€aa3905984245f99e828f17f867413cfae91230478715024dbSead44beb2otbc73a23a271d627 a|1747b5823f753ebo3
0xd67a7b1 1 1c0401971f57806a2be 12a774b8923fd397 2ec64fe3d€36e96594a14207831d12f 16f545851cad6356bb16221bee68eb2fee9427eoda0caEf98e5861
0xe83071df5288c373asbc43fb20309e25e991d85b61a9a4e6f3f7151 1b98f7ec87047fb32520d94cd7753dbe173304445ca648231f601dd19d3cd40c74190c71d
1,0xed4294bSa529529c94250ad35394214a4a52a569a94a94a5e56b52948ca74a52529429524a8aa529294a9caSe1295294d4a74a727394696a4a!3a529236a968d
1,0xd621eb6eSab7992c6efba5f34a7b7b28026fc93138998c113831dbaaaca1a15738a7b7agd191bcd77955b92b75263ad9f6bbd4ce0b4edca1efd5f3e24b3a2889
1,0xd9a43ff058df6b8d55085028eac413a7439e1dc89eSd6egbSde09e7bc7483d7627ABff9e36527ff67c39360cfc0d2a75986b7fb35614027cffb932eo1112eeBd
7 , Oxa49292499249492449252492249292499249492449242492249292499249492449242492249292499249492s492424922492924992494925492524922492933f.
1 , 0xf9cf9b29d767edb655b2f6bf964bce697f652fb669b322eb63dffb6e7a6c69bb798396d284d85169883d42a6ec96b292761dOdcd7ab595b2ad0a9aSd7eg7fe41
l,0xfffeffleffffftfftffefffefffefffefffffffefffffffefffefffefffffffffffefffefffefffefffefffefffffflf000000000000000000000000000000bd
1 , 0xf9cq9ce7e738738cgce7ce73739cb9cece73e738398e9ce7e719739c9ce7ce7373dc39c€ce73e53839ce9ce7e7b9739cgce7ce73739c39cece73e73839c69d63
1,0xd53bd2t169ab7fb38abb7f05cb1550e200914674b65ce176001ffeb2gdbd1e90c21a77e28c6dbfdOe6a782baaba532e2a98eff9ed8e924986af702c48504d0d1
1 ,
0xc36€8f2addb602d9d18b2b040bc7a00bc7046b2030c2d3e91c4c161ed562a31d2d056af c759O42a46c28e218e25e7c7882fb1cb2d66039ed961daceEea69cSd7
1, Ored15cbOfde1567b278et2422eeO1ed658173594bObcb71594a18df455fc75ca7c5b529bb6b9ec229be6ba977773ecag77ae}8a1e9f557adfO79abBbceb2bcO1b
1 , 0xdo0b0dd78fd35c88db31806803799deab89b8b36c39dc0321574801fb936f90e2920f3dd65400ddc00be90ebcefdd62d5cSc062c20obdb04aa6a5acf697e2a0d
1,0xd0054c94020831e800450e05811840282088a906825002d9a0c340938dc0b20628072f800334102c08010309c020800710200c04a604083700aa440088411987
l, O\c7592dTdcgee1031dcd3d30f43028858305ac46ac981cafa164a8000a9c6eeb698181505242acgdf€e9€51c92460b987dbc8161def71863d35ac18fa1235a903
1,oxfffbfcfZfTfrdf3dfJfefsffffffbfffffgffJfffffdffTdfffffigfffiffefTdffffffffbfffdfffeffbfffflflfffffffTTfffdffffffffffflfffffffff35
1, Oxf5ebOEdT3ad4df3cdaf4fd2€af41e8e405952b7a327479L47i.fr.a33eb829039e77ff116f9e4958a3f604743sd2c55ba67b47631842905dbc2f12c66fb6c4e40f
1,0xc3ff4d30474f4odf0e7ffffdfa92ffff11d59d35d214ffff85c357c5c85ed72acaf1fb7d43f76d85ee6b4fb3ffdd60d5096€f1f290df4ff888e7e37efe4fge8f
1,0xcc7b18295347824ccb395bed351993c598c7cf7f4e32dcb9ab7a5d7e0baa7626d1b8dc651b34f5e4fSd3f2530b52fbgbd10€75259b36d774f059141bf9ede911
1 , 0xe675a7059b1e6df20198f8a75a0ab28123fff79a67f59c7049fd37d48128f3b3agb69475b902f4bc854ca1deecbc€73cdab89b17ae3c6401a9d43594775a926b
1 , 0xef7b77bd3defdef7f7b47bd€def76f7b7bdebdefef7bf7bdbdee7ef7b73d7b9edef7ef7b7b9e3deeet7bf7bgbdefd6ffffb97bdedef7ef7b7b9ebdafei3bf845
1,0xfd23b110962000d598488c43407369898cd0086d1780826dctaL4784f38388874362851b7711dc13564441351335c71fbd7c564dsds008f5de20d43i2476d71s
1,0xe918f1658790911a71a9ae1895cfe56dbed767816e337e2f950462affb3280d8a8dcb1240620ec0f1d19c3750afcf6295c58cca117b36632414cd9e114fdb097
1 , 0xffffaa55ffffffffff3cd9fe3ffff676ffffffffff1e0000000000000000000000000o000000000000000000000000000000000000000000000000000000009d
1,0xc02100004804100000100010008001ce2064004242c812186250154c00000088ba780O8a43a9713bc0abb849220e8362cc838b53cf88fcdbdd7fca83c8df8145
1,0xe318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c636318318c8c63c631318c18c6c631631818c68c63631831d9
1, 0xds01973162d4017f4e3b3c9d6803d4cc46a1d457c91feb5b6c2ae77423ba41c9cfbdSf4b9235667874507e9cafb4123e1992d1cSae75ee29508707!a822a6ccf
1,0xe28ecce1de7aO326423O76465160c1b03f9e721181e0468f4860ae94d7802a082f9f6007c001u20056de200677aa7d8a47718e6692ee4b3f862c24e04b543bs
1,0xda2f36d74bc2dc29de4de92f4b37b03942173€15a2dfb67e8f09e790ed1656af5a8aadef14b696426f1e929699daoe€3adgf21a9r66ede57d945tc!65b27d277
1,0xd28550a3a8520a1c850aa14250a114ba0a144285a14228501428850a428550e128400a14850aa14250a114080a144285a14228511428852a4685d0a128500a2d
1, 0xe79082499b094b2459266493608a9249b2410d34O9242692a49OA24d934941254935265a341086119449d824697524922697 926bb24949044027108a8c939aSd
1 , 0xedfc3T3fT83ffbfffTfefed3fffafffefffdSfffffdelffSffdffff3ffSffffefefd3fefTfbfEdfff6l3bbS9f9fbSfSbdS2aefdTEebddfe6edeeffe3f3fb3dtS
1, oxfffTlfb6fbfffefffffffeeffffeefffefTfffebfffeffffffffefff9fffffcbfdbff0faffffdfffTfTedffeeTadfffafffbfbTeffffdffdeTfadfdef63eS06b
1, 0xcaf67d473c10f4e73d6678d4a27e4eb14a743925d12c31f97Efa510ca68558b2c56d839acecbe75e935J86cec7dae7c95aa0b93065a3aa924594fdfb9f521535
1, 0xf6b43e3bd52847756d,1a271.22a8590a8a1c43c1c36b95cc72d0102f26b6da1b238236856f7c6e6faa83cc70e84f2db44088487fd94a175f22a0d990cc1afea6b
1,0xd2a20d1b986de2152b9d93cf6Obf98f68e9f9e050feb9820b006e5dc581f17a82f35a78d23fb34fab3962ae95bcf3a1e442eb5b1d72cd6956fa599483eee38c1
1, 0xe52e529494a54a535294294a4a51a509294a96a5a529529494a54a52529d29ea4a52a522298a94a5a522529494a44a525294294a4842a52e294af4aSa52f554b
1,0xc942c4644b1169461581e0713ba4O0570237a55c9ae69e3fe58d189aa751d218208421934f2132a888e796bc1f0914a0c9b4f116358cca22c69c35596bd961e5
1,0xed7t7e78afc7d3735fc1dfb0d13887cddcd715c9fe530530e0efceaa4bcaflbaebac9e601623db36fifef47fttttettf.f.ttl.00000000000000000000000003ed
1 , 0xf6db9b6dda6d29b61dfe73dbbasbdb6ddead69beedf6a6dbf7dadb6ddf6cOcb66db6f6d3b6db'gb64997c6dbe6cb4364b96dbdb6ddb6c67be6da4b7cbaedadf35
1 , 0xc080a1000000000000000000000000000000000000000000003008000880000002608020010120004408001004202080000800000050000000100000000900e1
1,0xe5335f76a97cse29d4557170cd9ef3ed53efc819fda87a566a5efe247ef102b85c7ad90c484ade030c7ebc23455e0dcbca2cec6afdf0e8c978cb6fbed5733fas
1 , OxcOOOOOOOOOOOOOOOObOOOOOOOOOO0oOOOOOOO0oOOOOOOOOOOOOOOOOOOO4oOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO4oOOOOOOOOOOOOOOOOOOOOOOOOOOOOI6s
!,0xc924249324929249b2ct4924L92464926492ra4892494936593320b93f9292e992497dL449242492229293499249492449262493248e96fff3c9104432f4cdbb
t, 0rc9242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449242492249292499249492449342b29
1, 0xc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000177
1,0xc00000041002400005080008021000049000000100000002080000000001021005180O00000000000000210080600040082000400000183001000000200020f1
1,0xcad0ca7166b2aaf6c82b0eadfeb13409da7c2679517d4fd96f89719659133e0492d209da600753dc5c2570ce128cf986332f944143204b706bf6e990c0e43dcb
MAT A BSI-1-6c_3.pdf, Blatt 294

0289

Factoring RSA keys from certified smart cards: Coppersmith in the wild l5

1,0xe739739c9ce7ce73739c39c€cs73e73939c€9ce7e739739c9ce7ce73739c39c6c€73e73939ce9ce7e739739c9ce7ce73739c39cece73e73939ce9c€7e73973df
1' , 0xe0929249924949244924249a249292499249492449242493249292499a494924493424922492924992494924492424922492b2499249492449242492282926f

1 , 0xc0001000000000000000000000000000000000O0000000000000000000000000000100802000cbo040908809180008c8000000010c00O12101b20000000002ad
1 , 0xcac7270Ogef07418dc89e2c96e796d44bc2244d98a0bb8ca9ob4d661736b486b6e1d8362822a4697cdd}7o2a3d8b7c4b23aala2285a2a109234a? 1346ba141795
1 , 0xcgdc672c0e38€caf2e3e1 1aef07326e3431a92ad87ef296d9dob5d4b3d00646b€bd7b3a!6c9a424e'74eL486d186d26997a4d9c131acb524881a€caco287cO57
1,0x€€09t0b€62O74c7299a788527ab8cd004809c631i1fd50a20013331678ccad20631879842b8a122569eb18c4b1dds64b11bce7a1414ae76973debf4ca768c4bd
1,0xd66cdaeef27sbfal3d1e66sdf430dd7aeo15bd0e9a5e4389067836e2a2aofb702703d6c3rd50d5917f3ba77aeb851cO16d26135d754c114adf303d0915O0452bd
1,oxfa147ea58cddaaabe6dJa04ff891009db3ff37e1272d573b7a3da5334t24195L2tda7tt4f163a72/t82aoedffa9140OO1ae21fSa64fd330f93€819ag68acatb7
1 , 0xf718c0bc8c57cc318c99fa15236191a531828a95856d6ac833a7e3a2110ddsd25226ea4344cabbb2fe19d614863b8c46e31b44038c8768c€4aea42a1Oafabt91
1,0xd86d99e183ba3c0870238db37t1d3f673cdec3112196acfaa1239667bcb3a3a7f6749f3229f550d5097510€6asau0626a641e2112112f,95080c5629973b1c975
1 , orfc1fc95ee7482l42bccb7tobcscd674ad82edca61fe2653c78622eo673485cc11cgg3aaeeb15f77d9OdJe1c6a946€239ab47€5ca3eb2aeb7O2t2de36626868db
1 , 0xt7c6bf218fcfadcba926ac5efdf60f97aeba8d5f70ceb27EftOf,6d57e763bfe86dc7a86ee76b8ba9dO76bf1a8f4a7fcfbO297a96c6cSa7Oea7e6€3c38326ff83
1 , Orc594391e8eOc24c8a71eg77d7 8db784d43c96ba3384tO2acf7ltc25O6736c65t7c44ef6c3bbf7b05659b954c6b9ce96f648c900b56c5f3caO1e47384ad4de577
1,0xdag75410693d:)120b32997c8c728t09d09610f5fef089a7ct63ff1dct673ftftb493c19c64167e0457646aaba4t34O9f9648rf7c39Oc25d4aea3d7cgb2f16b2d
1,0rt16teadget03ctcb36571b8bgfe3cf24e313aäce858b7d4e80O838329cgb729ecc6d.691df46€8647a9fdb18d.6bbca338aJ8214fa1eO3ads3fBe3ao5O3bfb6735
1 , Orddf3b56a7bb556ata1476addb54aagSe569c94ab62d5ia95cO54afO4b5a3b56adJf55€2dbb466eaubs6aad5a1629cSab3ad5sbf5ad1eBba4E5abg722dafSd7bd
1 , Oxd9958Je30334b89c8c02ac21Oc4dc8€6661Odlc958cb4d436e11aed€0t72a3b8a88e18b7c663533218c68€d66ObO31ad4c€38aa13bbc1Ob6c73fe3911accBde1
L,0xfcb0663af5e3c922936834039fd787aode9fdd178017021129cfb592570fd3c5e60787fc59128bceSbfcb38beOcO64b08c087fd8lE6bg6O207c93ca4cf3c5add
MAT A BSI-1-6c_3.pdf, Blatt 295

0290

16 D J Bernstein, Y-A Chang, C-M Cheng, LP Chou, N Heninger, T Lange, N van Someren

B Appendix: FIPS-L40 certifcation


Searching for the term "FIPS" on MOICA's website (http://moica.nat.gov.tw/html/en/index.htm)
returns the following entries in the FAQ section, all of which claim some security through FIPS
certification.

C (, i- mk!n*.9w!rj.r q;t
=

§-r,f Crtiflcrtr lut{prity ol IOI

A.tr i! iEposgible to ger key date ton C6ti6cäre IC cnd g priqde


Le] püalets i, .reited i, Cry?togräph( Moötles which i: rjlizes :

Srucrato( A pririüe key is used to crede.


rüe RSA and randon
:

FAQ rprste§, aElrlore ir HSIvI Besrdes, TltelCcadacrordantew-ith .

'Fm ,.4O-l level 2 cerüfiable b1'lC (trd BilliErmerl csrt+r ed *r


ta d possess higlr sequty. A plivile kel' ii asted iuidc ild dE
h om lC ca d afttr kcy *39ted
1rx1v119 \3y giry'1 grlon
:.rr"rlt's hig[ risk to store certificme irr dre floppy tlisL tLu car nal:ng,
iropy a* anl' tine lbc Cidzetr di8,ita.l certifi (de p6s FIPS l,tli'l
iöJ*lq'itv tel,at ? ild [ave biglr :eo ity Pt ivate Ley cu t be cql
FAQ
ifou IC cru rl alier gemrate key pair of irrside the IC card flrir
,cer rifi rate level rs \ 509 r 3 I he poliq ol
(itiretr dI8ilal ccl ri6(e
:drm certi8crre should load irto tc cd d
or.*crodingio cr-J ot uoicr. U" ic catl is hig! se<nrrq'ard it
FAQ trra'e bem acqeditrd to FIPS 140-t level 2 and 6e crd use is rred
'r.o
5_1ga1e
gro19gr, u__d.$9.rg il.lJLNl,. ,

inoörles o softwne,Iadq,ae cryptographic no&rler wiöin tlle lC


FÄQ jcad, ueerirgrequireoers oI CPS md FIPS l.t0-l level 2
rariffratiu ol'coe?qt_le sgglyr§ :r-$9fr_!!!.-9:- ... . .. -
,.t , it; AA i,"i;; ;;;;d i; &i"s"phi.-;'dlrli irtins, RsA
ialgpridrn ard rodon umbv generaot Cteatpd widrhr a htdrtar
rnodule. dre pr ivue key is m ed bside wirhout lealiagS, Mom{eä ,
FAQ
.csrificae subscriber s IC cild ir tutermlly geuacdwul E?5 tro-
:l l€lel ? certificatio! al &e Cüd ceüs. The Frivmltr i iry.r&l
etrYY' 1!eI s§I!!-91
:A.H*'i[;üii; iud r rbe criu fa üx fr
.can be trily copied ard dre rirk is hig!.
iarüenrication. the <errifrcete IC cad ß hi{H,
FAQ
'beüq grnoarod iutenrally after *'tic! e
rc\pmrd nor replicated Subs«ibs'r iacfi
hsuXgenificare protectio X.509 V3 lwtl, _*
To{al6 PasF 1,'l-- [ Ncrr 20 I I Prrv 20 ]
MAT A BSI-1-6c_3.pdf,
file;lll Blatt 296 #t-

Fwd: Gotem-Artike1

Von: "Kowatski, Bernd" <bernd.kowalski@bsi.bund.de> (BSI Bonn) flU /'Y


O O,l
An: "Hesselmann, Thomas" <thomas.hessetmann@bsi.bund.de> I

Kopie : Dennis Küqle r <Dennis . Kueote robsi . bund . de>, -Kif.1i-a-0-J.9 regEl
<oereon.killian@bsi.bund.de>, "Weber, Joachim" <ioachim.weber@bsi.bund.de>,
"vloeschaeftszimmerabt-s@bsi.bund.de" <vloeschaeftszimmerabt-s@bsi.bund.de>, l5.c§§-Ug-
Karl Eoon" <karl eoon.sossono@bsi.bund.de>,
Datum: 17. 09. 2013 L2t48

HalIo Herr Hesselmann ,

bitte hierzu Stetlungnahme verfassen. Bitte auch Abstimmung mit K und S12.

Neben einer fachlichen, internen Stellungnahme benötigen wir auch einen


Kurztext für die Pressestelte bis Mittwoch DS.
VD und Gruß BK

weitergeteitete Nachricht
Von: Geschäftszimmer S <qeschaeftszimmer-s@bsi.bund.de>
Datum: Dienstag, 17. September 2013, 11;56t47
An: "Weber, Joachim" <ioachim.weber@bsi.bund.de>, "Killian, Gereon"
<oe reon . klllian@bsl . bund . de>
Kopie: GPReferat S 24 <referat-s24@bsi.bund.de>, "Hembach, Friedrich"
< ,GPReferatS23
<referat-s23@bsi.bund.de>, "Gast, Thomas"
<thomas.oast@bsi.bund.de>, "Utlmann, Markus"
<markus.ultmann@bsi.bund.de>, "Kügler, Dennis"
<dennis.kueoterGbsi.bund.de>, "Kowalski, Bernd"
<bernd. kowalski@bsi. bund. de>, "GPGeschaeftszimmer_S"
<oeschaef ts zimme r - s@bsi . bund . de>
Betr. l Fwd: Go1em-Artikel

> Hallo Herr Killian,


;lit der Bitte um kurzf ristige Bewertung des Sachverhaltes (siehe
J"rr"*r.ter Lung, .
> Mit freundtichen Grüßen
>i.A.
> Christine Krause
> Geschäftszimmer S
> Bundesamt für Sicherheit in der Informationstechnik
> Godesberger Allee 185 -189
> 53175 Bonn
> Tetefont +49 (0) 228 99 9582 5101
> Fax: +49 (0) 228 99 10 9s82 5101
> E-Mai1: oes chaeft sz imme r - s(absi . bund. de
> Internet: www. bsi. bund. de
www. bsi - fue r - bue roe r. de

weitergeteitete Nachricht
> Von: "BSI-Pressestelle" <oresse@bsi.bund.de>
> Datum: Dienstag, 17. September 2013, 1"1"242t23
MAT A BSI-1-6c_3.pdf,
file:lll Blatt 297 #2

> An: GPAbteilung S <abteilunq-s@bsi.bund.de>


> Kopie: oresse@bsi.bund.de
> Betr.: Gotem-Artikel
029 2
> > Liebe Kolteginnen und Kotlegen,
> > ein aktueller Artikel auf Golem beschreibt Fotgendes
> > Einem Team von Kryptographen ist es gelungen, die privaten Schlüssel
> > zahlreicher Zertifikate, die von der taiwanischen Regierung ausgegeben
> > wurden, zu brechen. Erstellt wurden die Keys mit Hitfe von Chipkarten,
> > die von verschiedenen Stelten ats sicher zertifiziert v'rurden - unter
> > anderem vom deutschen Bundesamt für Sicherheit in der Informationstechnik
> > (BSr).

> > Der ganze Artikel ist hier zu lesen:


> > htto://www.oo1em.delnews,/zufallszahlen-talwanische-bueroerzertifikate-oek
> >na ckt-1309-L0163L.htmt
> > Ein Link im Artikel auf das Zertifikat zeigt, dass dieses aus 2004 ist.
> > httos://www.bsi.bund.de/SharedDocs,/Dourntoads/DE/BSI/Zertifizieruno/ReDort
> >e0 2/0212a_pdf . pdf?-b1e[=publicationFile

!r"n". unsere Frage; War es denn dann überhaupt noch gültig?

> > Noch sind keine Presseanfragen dazu angekommen, aber ggf. kommen
> > Rückfragen.
> > Vielen Dank für eine Rückmeldung und Einschätzung und viele Grüße

> > Patricia Baumann

> > Bundesamt für Sicherheit in der Informationstechnik (BSI)


> > Pressestelle
> > Godesberger Atlee 185 -189
> > 53L75 Bonn
> > Postfach 20 03 63
> > 53133 Bonn
-^Telefon: +49 (0)228 99 9582 5777
!rur"t"x: ++g io) zzl gg 9582 5455
> > E-Ma11: oresse(absi.bund.de
> > Internet:
> > www.bsi.bund.de

Kowalski, Bernd

Bundesamt für Sicherheit in der Informationstechnik (BSI)


Abteilungsp räsident

Godesberger Atlee 185-189


53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefon: +49 (0)228 99 9582 5700


Mobit: +49 (0)L7L 223 L384
Telefax: +49 (0)228 99 10 9582 5700
E-Mail : bernd. kowalski@bsi. bund.de
I nte rnet : !rt,,wt-b§i=b.glu!-J-q
MAT A BSI-1-6c_3.pdf,
tile:lll Blatt 298 #1

Fwd: Gotem-Artiket

Von: (BSI Bonn)


An: 029
Datum: 17.09.2013 12:56

Hal1o

gibt es weitere Informationen als die, die Sie mir bislang zugesandt haben?

G rüße
Thomas Hesselmann

Unfortunately I witl be out of the office in the weeks 41-42, 52-92. During
this time I will be unable to reply to your mail.

Bundesamt für Sicherheit in der Informationstechnik


h, Thomas Hesselmann
Irat s22
Godesberger Atlee 185 -189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefon: +49 (0)228 99 9582 5691


Tetefax t +49 (0)228 99 10 9582 5691
E-Mail:
Internet : www. bsi, bund. de
www. bsi - fue r- bue roer. de

weite rgeleitete Nach richt


Von: "Kowalski, Bernd" <bernd,kowalski@bsi.bund.de>
Datum: Dienstag, 17. September 2013, L2t48:45
An: "Hesselmann, Thomas" <
[d,e: Dennis Kügler <Dennis.Kueqler@bsi.bund.de>, "Kiltian, Gereon"
eon. killian@bsi. , I'Weber, Joachim"
<joachim,weber@bs , " "
< "Sossong, Karl Egon" ,
<karI-eoon.sossonq@bsi-.bund.de>, "Gast, Thomas" <thomas.oast@bsi.bund.de>
Betr.: Fwdr GoIem-Artikel

Hatlo Herr Hessetmann,

bitte hierzu Steltungnahme verfassen. Bitte auch Abstimmung mit K und S12.

Neben einer fachlichen, internen Stellungnahme benötigen wir auch einen


Kurztext für die Pressestelle bis Mittwoch DS.
VD und Gruß BK

weite rgeleitete Nachricht


Von: Geschäftszimmer S <oeschaeftszimmer-s@bsi.bund.de>
Datum: Dienstag, 17. September 2013, 11:.56t47
An: "Weber, Joachim" <ioachim.weber(Obsi.bund.de>, "Ki11ian, Gereon"
<
MAT A BSI-1-6c_3.pdf, Blatt 299
tite.lll #2

Kopie: GPReferat S 24 <referat-s24@bsi.bund,de>, "Hembach, Friedrich"


<friedrich.hembachGbsi.bund,de>, GPReferat S 23
<referat-s23@bsi.bund.de>, "Gast, Thomas" n9
\J {' A
<thomas.oast@bsi.bund.de>, "Ullmann, Markustr
/ A
-t
<markus.ullmann@bsi.bund.de>, "Kügler, Dennis"
<dennis. kueoler@bsi.bund.de>, "Kowalski, Bernd"
<bernd. kowalski@bsi. bund. de>, "GPGeschaeftszimmer_S"
<qeschaeftszimmer- s@bsi. bund . de>
Bet r. : Fwd : Gotem-Artikel

> Halto Herr Killian,


> mit der Bitte um kurzfristige Bewertung des Sachverhaltes (siehe
> Pres'semitteilung).
> Mit freundlichen Grüßen
> i. A.
> Christine Krause
) -:--
> Geschäftszimmer S
> Bundesamt für Sicherheit 1n der Informationstechnik
185 -18e
el;;HserAtree
> Tetefonz +49 (0) 228 99 9582 5101
> Fax: +49 (0) 228 99 10 9582 5101
> E-Mail: oeschaeftszimmer-s@bsi. bund. de
> Internet: www. bsi. bund. de
> www. bsi-fuer-bueroer.de

> Von: "Bsl-Pressestelle" <@


> Datum; Dienstag, 17. September 2013, 77:42:23
> An: GPAbteitung S <abtellunq-s@bsi.bund.de>
> Kopie: presse@bsi,bund.de
> Betr.: Golem-Artikel

,-. Liebe Kolleginnen und Kollegen,


!> > ein aktueller Artiket auf Golem beschreibt Folgendes
> > Einem Team von Kryptographen 1st es gelungen, die privaten Schlüsse1
> > zahlreicher Zertifikate,'die von der taiwanischen Regierung ausgegeben
> > wurden, zu brechen. Ersteltt wurden die Keys mit Hilfe von Chipkarten,
> > die von verschiedenen Stetlen als sicher zertifiziert wurden - unter
> > anderem vom deutschen Bundesamt für Sicherheit in der Informationstechnik
> > (BSr).

> > Der ganze Artikel ist hier zu lesen:


> > htto:,//www.oolem.de,/news/zufaltszahlen-taiwanische-bueroerzertifikate-oek
> >na ckt-1309-101631.html
> > Ein Link im Artiket auf das Zertifikat zeigt, dass dieses aus 2004 ist'
> > https:,//wr*r.bsi.bund.delSharedDocs/Downtoads/DE/BSI/Zertifizieruno/Reoort
> >e0 2/02L2a_pdf . pdf ?_bls[=publicationFile
> > Daher unsere Frage: War es denn dann überhaupt noch gültig?
> > Noch sind keine Presseanfragen dazu angekommen, aber ggf. kommen
> > Rückfragen.
> > Vielen Dank für eine Rückmeldung und Einschätzung und viele Grüße

> > Patricia Baumann


MAT A BSI-1-6c_3.pdf, Blatt 300

> > Bundesamt für Sicherheit in der Informationstechnik (BSI)


> > Pressestelle
> > Godesberger Attee 185 -189
> > 53175 Bonn
> > Postfach 20 03 63
> > 53133 Bonn
> > Telefon: +49 (0)228 99 9582 5777
> > Tetefax: +49 (0)228 99 9582 5455
> > E-ltlail: oresse@bsi.bund.de
> > Internet:
> > @LMd:&.
> > www. bsi-fuer-bueroer.de

Kor.ralski, Bernd

Bundesamt für Sicherheit ln der Informationstechnik (BSI)

jirunsspräsident
Gödesberger Atlee 185-189
53175 Bonn

Postfach 20 03 63
53133 Bonn

Tetefon z +49 (01228 99 9582 5700


Mobil: +49 (0)l7L 223 1384
Telefax: +49 (0)228 99 le 9582 5700
E-tlait : bernd. kowatskiobsi. bund. de
Internet : www. bsi. bund.de
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 301
#1

Fwd: Golem-Artiket

Von: "Hessetmann, Thomas" <thomas.hesselmann@bsi.bund.de> (BSI Bonn) non


An: Manfred Lochter <Manfred.Lochter@bsi.bund.de>, @ U /'>
<we rn e r. schindte r@bsi . bu nd . de>
Kopie: Dennis Küoler <dennis.kueoler@bsi.bund.de>
Datum: 17.09.2013 12 :59

Ha1lo,

gibt es hreitere Informationen als die bislang verteitten,


G rüße
Thomas

weite rgeteitete Nach richt


Von: "Kowatski, Bernd" <bernd. kob,,atski@b
Datum: Dienstag, 17. September 20L3, 12t48l.45
"Hessetmann, Thomas" <thomas.hesselmann@bsi.bund.de>
: Dennis Kügter <Dennis.Kueoter@bsi.bund.de>, "Killian, Gereon"
< , "Weber, Joachim"
<joachim.weber@bsi , " "
<vtoeschaeftszimm , "Sossong, Karl Egon"
<kart_egon.sosson , "Gast, Thomast'<thomas.gastobsi.
Betr.; Fwdr Golem-Artikel

Hatto Herr Hesselmann,


bitte hierzu Stettungnahme verfassen. Bitte auch Abstimmung mit K und S12.
Neben einer fachlichen, 5-nternen Stellungnahme benötigen wir auch einen
Kurztext für die Pressestelte bis Mittruoch DS.

VD und Gruß BK

weitergeteitete Nach richt


Von: Geschäftszimmer S <oeschaeftszimmer
Datum: Dienstag, 17. September 2013, 11:,56:47
An: "Weber, Joachim" <ioachim.weber@bs , "Kittian, Gereon"
<oereon. kitlian@bsi. bund. de>
Kopie: GPReferat S 24 <referat-s24@bsi.bund.de>, "Hembach, Friedrich"
<friedrich.hembac ,GPReferatS23
<referat-s23@bsi. , "Gast, Thomas"
<thomas.gast6bsi. , "Ultmann, Markus"
<markus, ulLmann@bsi. bund. de>, "Kügter, Dennis"
<dennis.kueoter@b , "Kowatski, Bernd"
<bernd.kowatskiOb , "GPGeschaeftszimmer S"
<oeschaeftszimmer
Betr. : Fwd: Golem-Artikel

> Hallo Herr Kittian,


> mit der Bitte um kurzfristige Bewertung des Sachverhaltes (siehe
> Pressemitteitung),
> Mit freundtichen Grüßen
>i"4.
> Christine Krause
file:lll
MAT A BSI-1-6c_3.pdf, Blatt 302
*2

> Geschäftszimmer S
> Bundesamt für Sicherheit in der Informationstechnik
> Godesberger Attee 185 -189
0297
> 53175 Bonn
> Telefon z +49 (gl 228 99 9582 5101
> Fax: +49 (0) 228 99 10 9582 5101
> E-Mail: geschaeftszimme r- srabsi. bund . de
> Internet: www.bsi.bund.de
> www.bsi-fuer-bueroer.de

> Von: "BSI-Pressestetle" <presseCIbsi.bund.


> Datum: Dienstag, 17. September 2013, LLz42123
> An: GPAbteitung S <abteiluno-s@bsi.bund.de>
> Kopie: presse@bsi.bund,de
> Betr.: Gotem-Artiket
I ,r"0" Kotteginnen und Kotlegen,

> > ej.n aktuetter Artiket auf Gotem beschreibt Fotgendes


> > Einem Team von Kryptographen ist es gelungen, die privaten Schtüssel
> > zahtreicher Zertifikate, die von der taiwanischen Regierung ausgegeben
> > wurden, zu brechen. Ersteltt wurden die Keys mit Hitfe von Chipkarten,
> > die von verschiedenen Stetten als sicher zertifiziert wurden - unter
> > anderem vom deutschen Bundesamt für Sicherheit in der Informationstechnik
> > (BSr).
> > Der ganze Artiket ist hier zu tesenl
> > ht