S: Microcontroller mit NPU?

[Christian Kahlo]

Hallo,

ich suche einen Microcontroller der ueber eine RSA-taugliche NPU
verfuegt. D.h. quasi BigInteger, ggf. mit Chinese Remainder Theorem
(CRT), erwuenschte Integerlaenge 2048 - 4096 Bit. Moeglichst klein
mit mind. 3 freien I/O Pins, SIO von grossem Vorteil.

Nein, ich will kein PayTV Hacking betreiben dazu fehlen Zeit und
Motivation. Desweiteren existiert dafuer Hardware am Markt.

Problem:

Sichere Verbindung zu einem Server. Die Kommunikation an sich
laeuft mit dynamisch generierten SSL Keys um den Datenstrom zu
scrambeln, die User Authentisierung laeuft unabhaengig von SSL
auf Applikationsebene. Dazu ist ein kleines HSM (Hardware Security
Module) notwendig.

Loesungsziel:

Einen der bekannten Smartcard Reader Chipsaetze mit uC+NPU verquicken
und in geschirmtes Gehause unterbringen inkl. Abblockkondensatoren
in der Stromversorgung, Resetcontroller, Powerfail Erkennung,
interner Taktung (Stichwort: Differential Power Analysis, Glitching),
SRAM, Lithium Batterie.

Z.b. die am Markt erhaeltlichen Smartcards bieten a) keine 2048
- 4096 Bit, b) Glitching erweist sich nachwievor als Problem,
c) Abstrahlung (EMV) kann auf der minimalen Modulflaeche nicht
ausreichend geschirmt werden, d) intrusive Attacks sind mangels
SRAM und Batterie zwangsweise frueher oder spaeter erfolgreich.
Auch die USB-Tokens koennen bei dem zu beruecksichtigenden
Angriffspotential getrost in den Skat gedrueckt werden.

PCI oder PCMCIA Module scheiden auf Grund der benoetigen
Steckplaetze bzw. Einbauaufwand aus. Dazu kommt der bezueglich
Materialkosten voellig ueberzogene Preise und die typischer
Weise US-Amerikanischen Hersteller.

Es geht nicht um die Realisierung von RSA bzw. Abwehrmethoden
von Differential-Fault-Analysis (z.B. Bell-Core Attacke) sondern
um sachdienliche Hinweise auf einen moeglicher Weise geeigneten
uC. Auf einem "normalen" wenn auch schnellem Atmel wird eine
native Implementierung von RSA zu langsam, vor allem wenn man
hinterher noch sicher gehen moechte, dass man sich nicht unge-
wollt "verrechnet" hat.

Danke fuer Hinweise.

Beste Gruesse,
Christian

 

[Christian Kahlo]

Nachtrag zur Info:

Im Prinzip waere so etwas wie der Philips P8WE5032V0G, zu finden
z.B. in Giesecke&Devrient STARCOS 2.3 SPK, sinnvoll.

STARCOS2.3 hat fuer die Loesung jedoch zwei logische Probleme, da eine
nicht standard-konforme Funktion explizit gebraucht wird und Schluessel
groesser 1024 Bit nicht generierbar sind - obwohl Hardwaretechnisch
durch die Philips FrameX NPU bis 4096 Bit machbar waeren.
Weiterhin fehlt das SRAM, dass man bei Alarm killen kann.

Nun steckt STARCOS 2.3 auch im Rainbow iKey 3000. Nur dass ich
Rainbow keinen zehntel Zoll ueber den Weg traue.

/Christian

 

[Rafael Deliano]

ich suche einen Microcontroller der ueber eine RSA-taugliche NPU
verfuegt.
Da muß man nicht lange suchen: alle Controller die diese sonderbare

Peripherie haben sind für Chipkarten gedacht und werden wohl nur
als Chipkarten verpackt an die einschlägigen Großkunden heraus-
gegeben. Die Hersteller sind nach Marktanteil etwa:
Siemens, Philips, ST und schon abgeschlagen Atmel.
Mir wäre nichtmal klar, wo die Serienanwendung wäre, die Chips sind
also wohl typisch Papiertiger die nicht über Bemusterung rauskommen.

Mir wäre nur eine Anwendung für Chipkartenlösung bekannt geworden:
Hf-Transponder von Siemens haben verschlüsselte Übertragung und
Siemens verkauft für die Basisstation entweder teuer Softwarelösung.
Oder etwas preiswerter Prozessor auf Schrumpfchipkarte a la Handy.
Jedem Anwender wäre ein DIL-IC sicher lieber.
Wohlgemerkt: Siemens kann die Chips intern in den geringen Mengen
beschaffen, Aussenstehender hat die Möglichkeit ohnehin nicht.

Sichere Verbindung zu einem Server.
Wenn ein asymmetrisches Verfahren wie RSA nötig ist, kann man es ja

zur Schlüsselübergabe verwenden und dann symmetrisches Verfahren
wie DES oder AES laufen lassen. Die sind wesentlich effizienter.

Differential Power Analysis ...intrusive Attacks ... zu berueck-
sichtigenden Angriffspotential ... Differential-Fault-Analysis
(z.B. Bell-Core Attacke)
Der Quark wird zwar gerne rumgereicht, aber

* schon die Leute die tiefschürfen darüber sprechen haben nie
versucht ein echtes System per Krytographie anzugreifen.
Pseudo-"erfolge" wie sie auf Konferenzen gern angepriesen
werden, haben mit der Realität wenig zu tun.
* die Leute die echte Systeme angreifen haben von Kryptographie
keine Ahnung. Intelligenter Krimineller liest nicht das Buch
von Schneier zwecks Fortbildung, sondern wird Wirtschafts-
verbrecher oder Politiker.
* die meisten echten Systeme haben einfachere Alternativen
als Angriffsmöglichkeit als Krytographie. Man wird nicht
umständlich einen Garagentoröffner mit Computer abhören, wenn
man mit Werkzeugkasten bequem die Garagentür aufbrechen kann.
* das kann man ja auch in dem Buch von Kahn das die historische
Perspektive gibt nachlesen.

MfG JRD

 

[Christian Kahlo]

Rafael Deliano wrote:

ich suche einen Microcontroller der ueber eine RSA-taugliche NPU
verfuegt.
Da muß man nicht lange suchen: alle Controller die diese sonderbare
Peripherie haben sind für Chipkarten gedacht und werden wohl nur
als Chipkarten verpackt an die einschlägigen Großkunden heraus-
gegeben. Die Hersteller sind nach Marktanteil etwa:
Siemens, Philips, ST und schon abgeschlagen Atmel.

Alles bekannt. Sonst wuerde ich nicht solche Fragen stellen.
Einen Infineon SLE66CX640P als Muster hab ich ja auch rumliegen,
nur loest der das Problem nicht. Es geht auch nicht um Einzel-
stueckzahlen - sicher in der Prototypenphase, aber ich suche auch
etwas "Finales".

Mir wäre nichtmal klar, wo die Serienanwendung wäre, die Chips sind
also wohl typisch Papiertiger die nicht über Bemusterung rauskommen.

Ja, leider im Moment. Obwohl die Bond-Outs der Chips o.g.
Hersteller in Musterzahlen in etwa die Ansprueche erfuellen.

Mir wäre nur eine Anwendung für Chipkartenlösung bekannt geworden:
Hf-Transponder von Siemens haben verschlüsselte Übertragung und
Siemens verkauft für die Basisstation entweder teuer Softwarelösung.

Auf der Basis vom SLE66CLxxx?

Sichere Verbindung zu einem Server.
Wenn ein asymmetrisches Verfahren wie RSA nötig ist, kann man es ja
zur Schlüsselübergabe verwenden und dann symmetrisches Verfahren
wie DES oder AES laufen lassen. Die sind wesentlich effizienter.

AES sowieso nicht. AES wurde nicht fuer Sicherheit gebaut.
Aber die Diskussion gehoert dann eher nach dcsm.

3DES/IDEA als transport cipher.

Differential Power Analysis ...intrusive Attacks ... zu berueck-
sichtigenden Angriffspotential ... Differential-Fault-Analysis
(z.B. Bell-Core Attacke)
Der Quark wird zwar gerne rumgereicht, aber
* schon die Leute die tiefschürfen darüber sprechen haben nie
versucht ein echtes System per Krytographie anzugreifen.
Pseudo-"erfolge" wie sie auf Konferenzen gern angepriesen
werden, haben mit der Realität wenig zu tun.

DFA, DPA, Glitching sind ein ernstes Problem bei Pay TV Hacks.
Nichts Anderes als Glitching tun "Card Unlooper" fuer die DSS
Karten. Weiteres ggf. per PM. Ich moechte nicht weiteres Material
dazu rumreichen, da ich genug Aerger wegen derlei Dingen hatte
und Mails wie "Wie knacke ich meine D-Box" gerne nicht mehr
sehen moechte.

* die Leute die echte Systeme angreifen haben von Kryptographie
keine Ahnung. Intelligenter Krimineller liest nicht das Buch
von Schneier zwecks Fortbildung, sondern wird Wirtschafts-
verbrecher oder Politiker.

Ein "intelligenter Krimineller" duerfte schon an Starcos
oder handelsueblichen TCOS2.0.3 (SLE66CX320P) verzweifeln.
Intelligente Kriminelle sind aber nicht das Angriffspektrum
in diesem Szenario.

* die meisten echten Systeme haben einfachere Alternativen
als Angriffsmöglichkeit als Krytographie. Man wird nicht
umständlich einen Garagentoröffner mit Computer abhören, wenn
man mit Werkzeugkasten bequem die Garagentür aufbrechen kann.

man Off-Shore-Hoster. Mit Garagentuer ist es da nicht getan

* das kann man ja auch in dem Buch von Kahn das die historische
Perspektive gibt nachlesen.

Yep.

Danke fuer Deine Mail auch wenn Sie nicht das beantwortet
hat wonach ich gesucht habe. Evtl. laeuft es darauf hinaus
eine extra Maske fuer eine Smartcard CPU unserer Wahl
entwickeln zu lassen und weniger Wert auf die internen
Sicherheitsfeatures zu legen und dies durch umgebendes Klein-
gemuese herzustellen.
Es muss halt ein Konzept und eine Zahl in einer Machbarkeits-
studie stehen koennen.

Gruesse,
Christian

 

[Christian Kahlo]

Rafael Deliano wrote:

Hf-Transponder
Auf der Basis vom SLE66CLxxx?
Chip unbekannt. Die Schnittstelle zum Benutzer ist das übliche
halbduplex Smartcardprotokoll, soweit ich das mitbekommen habe.

T=0/T=1, also SLE66CL.
Es gab noch einen Flipchip von OKI der eine Abart von ISO14443
auf der einen und ISO7816-2/-3 auf der anderen Seite gesprochen
hat.

Für Anwender jedenfalls keine Freude:
* man muß sich die sonderbaren Chipkartenhalter in Kleinstück-
zahlen beschaffen und auf die Leiterplatte setzen.

Leider ja, bzw. OKI. Optimal allerdings auch nicht, da mit
2 Chips der Platz unter einem Modul extrem eng und die ganze
Konstruktion instabil wurde. (Module loesten sich leicht aus
Kartenkoerper heraus) Habe alles Moegliche in dieser Richtung
mal evaluieren duerfen. Ergebnis: 2001 kein dauerhaft brauch-
bares Produkt am Markt. Selbst die Motorola Module vom Berliner
e-Ticket(?) und Koelns i-Ti (SLE66CL) waren preislich/funktions-
maessig unwirtschaftlich. Dazu kamen ja noch mind. 60 Leser.
Die alte Kalkulation belief sich noch auf deutlich mehr.
Sind dann bei HITAG II fuer den kontaktlosen Betrieb, vorrangig
Zugangskontrolle, und TCOS 2.0.2 Min auf SLE66CX160S, eigene
Applikationsstruktur, fuer kontaktbehafteten Betrieb
(Authentisierung, Signatur, Transactionlog) angekommen.
Hat sich bisher auch im Rahmen der Anwendung bewaehrt bei
ertraeglichen Kosten. Ca. 12,5 Euro/Karte, teuerste Komponente
TCOS im Vergleich zu 5 Euro/Karte ohne TCOS und 25 Euro/Karte
fuer eine ISO 14443-A/B Variante mit Einschraenkungen.

* man muß eigentümliches, langsames Protokoll implementieren.

Warum eigentuemlich? Auf der Leserseite kommt wieder
T=0 oder T=1 raus, je nachdem was das Karten OS spricht oder
beim PTS vereinbart wurde.

Man hätte ja auch beliebigen OTP-Controller in DIL-Gehäuse
mit 2 UARTs nehmen können und da dann Daten durchschicken können.

Inwiefern siehst Du da eine Loesung? Damit ist die ISO 14443/B
Schnittstelle wie sie der SLE66CL implementiert noch nicht geloest.
Oder meinst Du was Anderes?

IDEA als transport cipher.
Ich dachte IDEA wäre mit Patent von ASCOM gesegnet ( wiewohl
mit EU-Steuergeldern entwickelt ).

Richtig. Aber wenn man es einsetzen will wird man das auch tun
und sich ggf. an die Schweizer wenden. In TCOS ist es z.B. drin
und sehr gut verwendbar implementiert. Insofern sind die Patent-
kosten ein wirtschaftlich loesbares und argumentierbares Problem.

Wenn man Daten über ein Kompressionsprogramm a la LZW
laufen lässt, haben sie meist schon wünschenswerte
Eigenschaften. Und die Übertragung ist schneller.

Das waere dann aber leicht brechbar durch simples sniffing,
scheidet aus =) Es geht hier um kryptographisch wasserfeste
Mechanismen, security-by-obscurity ist kein gangbarer Weg.
Die Ende-zu-Ende Verschluesselung laeuft zwischen Client-Host.
Fuer Host setze etwas beliebiges zwischen 4-fach XEON,
SUN enterprise >=450, HP N/L Class ein. Notfalls noch eine
Rainbow Cryptoswift Karte dazu. Fuer den Client rechne
etwas bei Pentium III 600 als Minimum. Alles was ueber die
Karte laeuft ist der Key-Exchange, ich habe SSLv3/TLSv1
fuer diesen Zweck re-implementiert, um mit einem externen
Modul zu arbeiten und eigenen, verifizierbaren Code zu
besitzen. Nein, openssl scheidet ebenfalls aus - zu gross
fuer den Client. Naeheres dazu gehoert wieder nach dcsm. ;-)
Nach dem Handshake laeuft wie gesagt 3DES/IDEA was durch
die betreffende Maschine selbst abgefackelt wird.
Ein ausreichend schneller und ausreichend latenzarmer Stream
laesst sich durchaus realisieren. Es ginge nur darum die
PKCS #1 Signatur ueber die Zufallszahlen auf der Clientseite
in eine Blackbox zu werfen und den Session-Key fuer den
betreffenden zuvor vereinbarten Mechanismus zurueckzu-
bekommen. Das Einzige Ziel ist also alle Massnahmen zu
ergreifen die Wahrscheinlichkeit eines RSA key leaks nach
menschlichem, derzeit moeglichen Ermessen so niedrig wie
moeglich zu halten. Das ist mein Job. Daher ja auch die
Frage nach einem brauchbaren uC+NPU um das ganze exemplarisch
aufbauen zu koennen bevor man mit 10k-20k Euro zu Philips
geht und freundlich um eine Testmaske bittet oder elend
teure Development Kits zu kaufen die einen auch nur einen
kleinen Schritt naeher an die Loesung bringen als ein
alternativer Aufbau.

Mails wie "Wie knacke ich meine D-Box"
Haarwuchsmittel werden auch angeboten.

LOL
Sollte man vielleicht mal eine Adresse eines Versender
zurueckschicken in solchen Faellen.

Da ich wenig Bild-Zeitung oder Publikationen des Heise-Verlags
lese, juckt mich das alles wenig.

Bild? Was ist das? Bei Heise steht seit geraumer Zeit leider
eher nur noch halbfertig recherchiertes Material. Wie soll das
auch gehen wenn man News "verkauft" und eine moeglichst kurze
Time-to-market haben will. Ich erinnere mich da an vorschnelle
Schlussfolgerungen als wir das CMS eines SLE44 disassembliert
hatten.

Es gab mal in IEEE Spectrum ( find den Artikel leider gerade
nicht ) seriösen Bericht über Reversengineering von Chips via
aufätzen usw. Die gutausgerüstete US-Firma über die berichtet

Microprobing Angriffe -> intrusive Attacks.
"Rauchende" (98%) HNO3 bei 60 Grad Celsius zum Entfernen der
Passivierungsschicht, microprobing mit Wolframnadeln unterm
Mikroskop. Ich gehe eher weniger davon aus, dass diese Sorte
von extrem aufwendigen Angriffen durchgefuehrt wird. DPA,
DFA sind simpler, quasi mit Elektronikkuechenmitteln zu
erledigen zu haeufig auch erfolgreich. Such mal nach DSS
Card-Unlooper, schmoeckere mal die serioesen Seiten dazu durch.
Hier geistert auch irgendwo noch ein Text rum, der genau sagt
nach wieviel Clockcycles bzw. ns bei 3,58MHz Takt Vcc auf
2,5(?) V abgesenkt werden muss um ueber eine Endlosschleife,
die die Karte im gesperrten Zustand ausfuehrt, hinweg zu springen.
"Dead Processor Boot Board" waere evtl. auch ein Suchbegriff.
Desweiteren waere ein microprobing Angriff bei der angestrebten
Architektur mit 3 Keys (production key im EEPROM,
key-encipherment key im SRAM, SRAM encipherment key im EEPROM)
erfolglos sofern das SRAM bei Black-Box Oeffnung sicher ge-
toetet wird und definiert seinen Inhalt verliert.
Ladeterminals fuer Geldkarten waeren ein schoenes Beispiel,
die Haendlerterminals kriegt man mit etwas Uebung und mehreren
Lernversuchen irgendwann "zerstoerungsfrei" auf - natuerlich
rein auf die Keys bezogen.

wurde hat das anfangs mal für "Kunden" in Sachen pay-TV
gemacht. Nachdem sie rechtskräftig verurteilt waren,

Ja. Kenne die Firma. U.a. haben sie auch beim PIC16F84
auf denen diverse PayTV Cracks fertig ausgeliefert worden
sind die Lock-Fuse durch eine Maske und UV-Bestrahlung
zurueckgesetzt und die Inhalte ausgelesen. PIC16C84 lies
sich durch verringerte Vpp und neu programmieren der Fuse
Bits umkippen. Ein Paper zu diesem speziellen Fall fand
sich IMHO auch bei Google vor einiger Zeit.

haben sie das Nebengeschäft aufgegeben und machen jetzt
Fehleranalyse an Chips bzw. Untersuchungen zu Patent-
verletzung. D.h. es geht schon, aber der Aufwand steht
in keinem Verhältnis zum Nutzen.

Korrekt. Je nach Angriff. Es gibt aber auch billigere Angriffe.
Laengere Zeit existierte auf alten Geldkarten (<=2000) die
Moeglichkeit den PIN fail counter durch Abschalten der
Versorgungsspannung im richtigen Moment (korrigeren des
Counters bei falscher PIN = EEPROM Zugriff = kurzes Spike auf
Vcc/GND durch eingeschaltete Ladungspumpe) manipulieren.
Man hat halt nach der Verifikation korrigiert, nun
dekrementiert man erst den retry counter und inkrementiert
Ihn bei Erfolg ggf. wieder. Bei 100.000 - 1Mio moeglichen
Schreibzugriffen und durchschnittlichen Kartenlebenszyklen
von ca. 2 Jahren stellt dies kein Hindernis dar.

Also Rafael, irgendeinen Vorschlag wo ich weiter suchen
koennte? Ansonsten lege ich mich auf STARCOS SPK 2.3 +
8051-Derivat mit 2 UARTS fest. Sind zwar erstmal nur
1024 Bit, aber es geht ja hoffentlich weiter.

Geduldig auf Philips SmartMX wartend,

Gruesse,
Christian

 

[Rafael Deliano]

Also Rafael, irgendeinen Vorschlag wo ich weiter suchen
koennte?
Nein. Die 3 typischen Halbleiterhersteller für Chipkarten

sind bekannt.

Ansonsten lege ich mich auf STARCOS SPK 2.3 +
8051-Derivat mit 2 UARTS fest.
Hört sich ökonomisch vernünftiger an, wenn die

tatsächlich benötigten Stückzahlen unsicher sind.

uC+NPU 10k-20k Euro
Sind das Preise die Philips genannt hat ?

Ich vermute eine Maske macht den vollen Wafer.
Chipkarten-ICs sind klein, deshalb viele ICs. Mehr als die
2k Stück für ROM 8051 die man ehedem von MHS-Temic bekam.
Im allgemeinen kann man von Halbleiterherstellern
rohe Chips nach Probelauf leichter bekommen als verpackte.
Möglich, daß sie bei Chipkarten-ICs pingeliger sind.
Und es gibt sicher jemand der sie je nach Absatz in kleinen
Chargen in Gehäuse bondet.
Trotzdem hätte man wohl mehr als man in 20 Jahre braucht.

Ich halte wie gesagt nichts von Chipkarten-ICs.
Weil Chipkarten-ICs klein sind ( wegen Durchbiegen,
Flachschleifen ) deshalb wohl auch die eigentümliche
Kombination kleine CPU + NPU. Ein konventioneller,
handelsüblicher 32 Bit OTP Controller ( StrongARM usw. )
hätte eventuell bereits Rechenleistung daß er keine
NPU benötigt.

... beim PIC16F84 ...die Lock-Fuse durch eine Maske und
UV-Bestrahlung zurueckgesetzt
Das ist eben ein Verfahren das jederman einleuchted und zum

Erfolg führt. Aufätzen kann man auch hierzulande von
Halbleitertesthaus machen lassen. Allerdings können
tatsächlich bei Chipkarten-ICs Maßnahmen dagegen auf dem
Chips sein.
Alle anderen Sachen können zwar irgendwo im weiten wwww
beschrieben sein, aber solange ich sie nicht selber
gesehen habe bin ich skeptisch.

Abgesehen vom Aufätzen: konventionelle Prozessoren haben
ohnehin 1-2 Hintertüren.
* Bei FLASH ( z.B. 68HC908 ) ist das Ausleseschutz-Bit
oft durch einen Zugangscode ersetzt.
Bei 68HC908 sind das 8 Bytes die unsinnigerweise auch
die Vektoren des Prozessors sind, sodaß man sie nichtmal
frei wählen kann.
* Irgendwo vermute ich hat jeder Chip zum Testen sowas
wie JTAG wo der Hersteller tief und überall reinkommt.
68HC908 werden in China gefertigt, dem sicherlich nicht
unkorruptesten Land der Welt. Die Specs wären wohl
für Geld beschaffbar.
Das ist beim MARC4 Controller der für die Automobil-
transponder verbreitet ist besonders krass: die
alten EEPROM/FLASH-Versionen haben überhaupt kein
explizites Ausleseschutzbit. Programmierung, Emulation
und wohl auch Halbleitertest sind alles gleicher Modus.
Zwar ist das Auslesen nicht dokumentiert, aber vermutlich
möglich.

MfG JRD

 

[Christian Kahlo]

Rafael Deliano wrote:

Nein. Die 3 typischen Halbleiterhersteller für Chipkarten
sind bekannt.

Ja, bin nun fuendig geworden bei einem der Kunden dieser 3 ;-)
Zwar muss ich in dem Fall den benoetigten Subset von DIN66291
nachimplementieren, aber mit 30kB Platz, 2048 Bit RSA, einer
vertrauenswuerdigen Hardware (also nicht Siemens und nicht
Atmel ;-P) kann ich denke ich einen Prototypen im geforderten
Masstab erstellen.

Ansonsten lege ich mich auf STARCOS SPK 2.3 +
8051-Derivat mit 2 UARTS fest.
Hört sich ökonomisch vernünftiger an, wenn die
tatsächlich benötigten Stückzahlen unsicher sind.

Genau. Das denke ich auch. Die MCU darf nun sogar sehr
klein ausfallen, solange mindestens ein UART drin ist,
notfalls schalte ich mit 4 MOSFETS als 2 diskrete Analog-
schalter den UART zwischen Host und Smartcard chip um.
Dann darf der Key im externen SRAM liegen und wird bei
Bedarf in die Karte geladen, die Ihn dann in RAM haelt,
mit dem KEK entschluesselt, verwendet und wieder entsorgt.

uC+NPU 10k-20k Euro
Sind das Preise die Philips genannt hat ?

Ja, ein Entwickler der mit Philips Chips arbeitet nannte
mir diese "Hausnummer" fuer das Erstellen einer Testmaske
- ohne den Eigenaufwand die Maske erstmal zu entwickeln.

Ich vermute eine Maske macht den vollen Wafer.

In der Regel schon, glaube nicht, dass man extra kleinere
Wafer nimmt.

Chipkarten-ICs sind klein, deshalb viele ICs. Mehr als die
2k Stück für ROM 8051 die man ehedem von MHS-Temic bekam.

Lass mich nachdenken, 2mm x 2,5-3mm duerfte in etwa die
Groessenordnung pro Dice sein. Die Teile sind winzig geworden.
Also im Zweifelsfall viel Siliziumkonfetti fuer die naechste
Party.

Im allgemeinen kann man von Halbleiterherstellern
rohe Chips nach Probelauf leichter bekommen als verpackte.

Bonden lassen waere auch kein Problem.

Möglich, daß sie bei Chipkarten-ICs pingeliger sind.

Als Dice oder Modul auf Band bestellen ist kein Problem.
Als Modul laesst man sie sich einkleben oder holt sich passend
gefraeste Traeger bzw. "Universaltraeger" und klebt Sie halt
selbst ein. UHU Greenit Alleskleber haelt hier bei 5 Stueck
schon ueber 2 Jahre. Der UHU ist auch spaeter noch ziemlich
flexibel was ein Rausbrechen wirksam verhindet, aehnlich wie
der industriell eingesetzte Heisskleber.

Und es gibt sicher jemand der sie je nach Absatz in kleinen
Chargen in Gehäuse bondet.
Trotzdem hätte man wohl mehr als man in 20 Jahre braucht.

Brauchst Du evtl. nen paar? ;-)
Die Doku gibts nach erfolgreicher Implementation dann auch.
Aber Vorsicht T=0 ist das Zielprotokoll, T=1 macht nur
Overhead und bringt uns in dem Moment keinen signifikanten
Vorteil, nur viel Code in der moeglichst kleinen MCU die
ja mit der Smartcard sprechen muss.

Ich halte wie gesagt nichts von Chipkarten-ICs.
Weil Chipkarten-ICs klein sind ( wegen Durchbiegen,
Flachschleifen ) deshalb wohl auch die eigentümliche
Kombination kleine CPU + NPU. Ein konventioneller,
handelsüblicher 32 Bit OTP Controller ( StrongARM usw. )
hätte eventuell bereits Rechenleistung daß er keine
NPU benötigt.

Auch eine Variante, bereits ein ARM7 waere evtl. fix genug.
Das muesste ich glatt mal ausprobieren. Ein 30MHz ARM7 im
PCMCIA Gehaeuse liegt zu Hause noch irgendwo rum.

Halbleitertesthaus machen lassen. Allerdings können
tatsächlich bei Chipkarten-ICs Maßnahmen dagegen auf dem
Chips sein.

Bei multi-layer chips, mit durchgezogenen VCC und GND
Ebenen, sowie "quer" und 3-dimensional "ueberkreuz"
laufenden Datenleitungen bzw. Alarmleitungen, die bei
Auftrennen, Kontakt mit GND oder VCC Exceptions ausloesen,
usw. usf.

ohnehin 1-2 Hintertüren.
* Bei FLASH ( z.B. 68HC908 ) ist das Ausleseschutz-Bit
oft durch einen Zugangscode ersetzt.
Bei 68HC908 sind das 8 Bytes die unsinnigerweise auch
die Vektoren des Prozessors sind, sodaß man sie nichtmal
frei wählen kann.

Bei Anderen z.B. die Maskenseriennummer, die man selbst ebenfalls
schlecht beeinflussen kann - evtl. bei "guten Vertraegen"
mit dem Hersteller.

* Irgendwo vermute ich hat jeder Chip zum Testen sowas
wie JTAG wo der Hersteller tief und überall reinkommt.

Motorola hatte das sogar mal bei Smartcard ICs als bond-area
und offenbar "vergessen" diese abzutrennen vor der Auslieferung.

Das ist beim MARC4 Controller der für die Automobil-
transponder verbreitet ist besonders krass: die
alten EEPROM/FLASH-Versionen haben überhaupt kein
explizites Ausleseschutzbit. Programmierung, Emulation
und wohl auch Halbleitertest sind alles gleicher Modus.
Zwar ist das Auslesen nicht dokumentiert, aber vermutlich
möglich.

Umpf. Wenn das so ist, dann leuchtet mir ein warum immer wieder
jemand klagt sein ach-so-sicherer A8 ist Ihm abhanden gekommen.
Passat 3B mit triefendem Hydraulikoelbehaelter klaut zum
Glueck kaum einer, man braucht nur regelmaessig Nachfuellen,
aber fuer "Kenner" sieht das Auto stets kapputt aus =)

Gruesse,
Christian

 

[Rafael Deliano]

Es gab mal in IEEE Spectrum ( find den Artikel leider gerade
nicht ) seriösen Bericht über Reversengineering von Chips
Bei Bedarf scannbar:

Kumugai "Chip detectives" IEEE Spectrim 11/2000
6 Seiten, davon aber 2 Fotos. Inklusive der Anschriften der
Firmen aus Kanada/USA an die man sich vertrauensvoll wenden
kann.
Rauch "The law on reverse engineering" IEEE Spectrum August 93
2 Seiten. Darstellung des Falls AMD vs. Brooktree bei dem AMD
verurteilt wurde, weil Teile von RAM-Layout geklaut.

MfG JRD