FAQFAQ SuchenSuchen MitgliederlisteMitgliederliste BenutzergruppenBenutzergruppen  RegistrierenRegistrieren  ProfilProfil Einloggen, um private Nachrichten zu lesenP.M. LoginLogin
Sichere Funkübertragung, z.B. zu Zündgeräten
Gehe zu Seite 1, 2, 3  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  

Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Mi 21 Dez 2005, 14:48    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
wozu Verschlüsselung? Eine Zustandsmaschine die in beiden Geräten läuft tut den gleichen Zweck und ist nicht zu knacken.
Prinzip muss einfach sein, dass das eigentliche Signal eine Sequenz ist, welche aus mehreren Kommando -> Quittierung Schritten besteht und bei jedem Fehler sofort auf Anfang zurückfällt.

Also dann spiel' ich jetzt mal den Advocatus Diaboli. Mit der Zustandsmaschine schuetzt Du Dich nicht vor Replay. Warum soll ich nicht einfach die gleichen Kommandi nochmals schicken, die ich beim letzten Start mit dem Scanner gesehen habe? Dazu muss die Zustandsmaschine einen nicht wiederholbaren Teil haben, das erreicht man mit der Seriennummer. Wenn diese aber offen uebermittelt wird, kann ich die Seriennummer aendern, d.h. ich kann Dir einen Start ausloesen in dem Moment, da Du von der Rakete zum Startpult zurueckmarschieren willst. Ob es nun genau eine Seriennummer ist oder irgend etwas anderes, was jedesmal anders ist, spielt keine Rolle. Dagegen gibt es zwei Methoden: die Uebermittlung schuetzen, oder Authentisierung. Damit das moeglichst zustandslos funktioniert, muesste man wieder jede Uebermittlung authentisieren, d.h. man braucht zum Beispiel ein Zero Knowledge Protokoll, damit die Authentisierung nicht einfach abgehoert werden kann. Oder man verschluesselt einfach, dann kann nur jemand, der den Schluessel kennt, einen Befehl formulieren, und weil die Seriennummer darin verschluesselt und mit Hash gesichert ist, kann er auch nichts daran aendern.

Das Protokoll funktioniert auch one-way, d.h. man koennte ohne Rueckwaertskanal operieren, obwohl man dann die Continuity nicht mehr so genau kontrollieren kann. Zur Sicherheit muesste man hier jedoch alle Zustandsaenderungen lease-based machen, also zum Beispiel ARM ist gueltig fuer die naechsten 8 Sekunden, wenn bis dann kein FIRE eintrifft, passiert auch nichts. Das macht man heute auch bei Fileservern oder Datenbanken so, z.B. NFSv4 verwendet lease based locking.

Natuerlich ist Verschluesselung nichts anderes als eine State-Machine, nur mit mathematisch sehr komplexem internem Zustand, so dass ohne dessen Kenntnis (den Schluessel), nur falsche Zustaende produziert werden koennen.

Auch die Enigma ist eine Zustandsmaschine, und wie die Geschichte bewiesen hat, war sie sehr wohl zu knacken, und nicht ohne Einfluss auf den Kriegsverlauf.

Fuer das Projekt: es muss ja nicht AES und SHA1 sein, einfachere Algorithmen duerften auch genuegen, aber spendier' Dir auf jedenfall etwas mehr als einen Tiny, damit Du fuer ein sicheres Protokoll genuegend Flash/RAM/CPU hast. Oder verlege diese Intelligenz ausserhalb der eigentlichen Zuendbox, in den Sender/Empfaenger.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Mi 21 Dez 2005, 15:22    Titel: Antworten mit Zitat

Nö, das funktioniert anders: Die Zustandmaschine beginnt an einem zufällig gewählten Zustand, übermittelt diesen an die Gegenstation, und von dort aus gehts dann nur noch weiter, wenn man dieselbe Maschine hat.
Für "Replay" muss man da schon sehr lange zugehört haben und auch das Gehörte mit Logik verknüpfen.
Klar kann der NSA das wahrscheinlich knacken, aber dann wäre es doch noch wesentlich einfacher die Leitungen der Kabelzuleitung anzuzapfen und so den Start auszulösen. Wink
Irgendwo hat's ja auch Grenzen was man abfangen können muss.
Dass Befehle ein "Verfalldatum" haben müssen ist sowieso eine gute Sache: Zum einen sinkt die Wahrscheinlichkeit von Fehlern, andererseits gibt es einen definierten Rückfallpunkt wenn sich irgend etwas "verheddert".


Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 2:03    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
wenn man dieselbe Maschine hat

Voilà, hier ist die Schwäche. Wenn Du der einzige bist, der die Zustandsmaschine besitzt, ist das OK. Wenn Du die Software der Zustandsmaschine hier postest (zum Beispiel als GPL Software, vielleicht darf ich ja mithacken), oder aus dem Ding ein Produkt machst, dann stimmt die Annahme nicht mehr, die Zustandsmaschine ist nicht mehr einzigartig, jeder kann eine haben. Das Problem kennt man von Garagentoröffnern, Autoschlüsseln und gewissen drahtlosen Mäusen/Tastaturen, mit denen man Nachbars PC gleich mitbedienen kann. Du brauchst eine Möglichkeit, Paare von Zündbox/Fernsteuerbox individuell zu machen. Dann hast Du Code, der aus einer Zufallszahl (der zufällig gewählte initiale Zustand) und dem individuellen Kennzeichen einen Befehl macht. Wenn du jetzt dem individuellen Kennzeichen "Schlüssel" sagst und nochmals über "aus ... ... macht" nachdenkst, dann erkennst Du ein Verschlüsselungsverfahren. Ziemlich genau das, was ich ein paar Posts früher beschrieben habe.

Ach ja, der zufällig gewählte Anfangszustand ist auch nicht so einfach, vor allem bei einem Microcontroller, der sehr wenige Entropiequellen hat. Da ist alles deterministisch, wenn man nicht vorsorgt. Wie stellt man sicher, dass zwei Fernsteuerboxen beim Einschalten mit Wahrscheinlichkeit > 0 verschiedene Zufallszahlen wählen? Automatisch geht das kaum (ausser man baut Hardware dafür ein), vielleicht kann man die Zeit zwischen Benutzeraktionen als Entropiequelle benutzen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 12:10    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Voilà, hier ist die Schwäche. Wenn Du der einzige bist, der die Zustandsmaschine besitzt, ist das OK.

Davon gehe ich mal aus.

Zitat:
Wenn du jetzt dem individuellen Kennzeichen "Schlüssel" sagst und nochmals über "aus ... ... macht" nachdenkst, dann erkennst Du ein Verschlüsselungsverfahren. Ziemlich genau das, was ich ein paar Posts früher beschrieben habe.

Mit einem wesentlichen Unterschied: Ich brauche keine Online-Rechenleistung mehr, die "Verschlüsselung" ist beim Programmieren passiert. Ich kann ja auch eine Zustandsmaschine wählen, welche durch externe Parameter verändert wird, zb. durch ein xx-bit Wort was auf einem Dip-Switch eingestellt werden kann.

Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 12:57    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Davon gehe ich mal aus.

Schade. Warum nicht Open Source (klicken), dann hätten mehr etwas davon, und tatkräftige Unterstützung könntest Du auch haben (von mir zum Beispiel).

Zitat:
Mit einem wesentlichen Unterschied: Ich brauche keine Online-Rechenleistung mehr, die "Verschlüsselung" ist beim Programmieren passiert.

Naja, zeig mir mal die Zustandsmaschine, die ohne Rechenleistung funktioniert. Der Herr Turing hätte da wohl auch noch so seine Meinung dazu. Eine Zustandsmaschine macht ja aus Bits andere Bits, und das nennt man üblicherweise "Berechnung", und macht es mit der CPU. Das Argument, dass das schon bei der Programmierung festgelegt worden sei, zieht natürlich nicht: erst wenn das Programm ausgeführt wird, wird die Zustandsmaschine auch realisiert. Führ' mal ein Programm ohne CPU aus...

Zitat:
Ich kann ja auch eine Zustandsmaschine wählen, welche durch externe Parameter verändert wird, zb. durch ein xx-bit Wort was auf einem Dip-Switch eingestellt werden kann.

So etwas nennt man einen Verschlüsselungsalgorithmus, und das xx-bit Wort heisst dann Schlüssel. Statt des DIP-Switches könnte man den Code ja auch ins EEPROM brennen, damit spart man noch Platinenfläche und Bauteile.

Sag ich doch die ganze Zeit: Zustände + Randomisierung Verschlüsseln und übermitteln.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 13:47    Titel: Antworten mit Zitat

Das würde der Herr Turing ganz konkret sagen: Die Zustandsmaschine kann durch eine Turing Maschine simuliert werden, da eine Turing Maschine jede andere Maschine simulieren kann. Da moderne Prozessoren in einem beschränkten Sinne Turing vollständig sind, sind sie äquivalent zu einer Turing Maschine, d.h. moderne Prozessoren können jede Zustandsmaschine simulieren, die Du dir ausdenken kannst. Kurz: jede Zustandsmaschine kann von einem Prozessor berechnet werden.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 14:32    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:

Naja, zeig mir mal die Zustandsmaschine, die ohne Rechenleistung funktioniert.

Naja, etwas unscharf formuliert. Man muss da immer extrem aufpassen, wenn man mit Mathematikern diskutiert Wink
Korrektur: Man braucht weniger Rechenleistung, weil man nicht die ganze Kommunikation verschlüsseln sondern nur den nächsten Zustand einmal errechnen muss. Wink

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 14:35    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Statt des DIP-Switches könnte man den Code ja auch ins EEPROM brennen, damit spart man noch Platinenfläche und Bauteile.

Ja, aber dann kann man den Schlüssel nicht mehr ohne weiteres anpassen!

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 15:15    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Ja, aber dann kann man den Schlüssel nicht mehr ohne weiteres anpassen!

Was macht genau so ein Bluetooth Device wenn es mit dem Computer gepaart wird? Genau: einen Schlüssel generieren, der zwischen den zwei geheim ist. D.h. man kann jederzeit die Schlüssel wechseln, selbst ohne DIP-Switch. Zum Beispiel so: in den ersten 5 Sekunden nach dem Einschalten wird nach neuen Partnern gesucht, sonst wird der alte verwendet. Braucht nicht einmal ein Bedienungselement. Nur auf 5 Sekunden genau gleichzeitig einschalten.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 15:24    Titel: Antworten mit Zitat

Juerg hat folgendes geschrieben:
Korrektur: Man braucht weniger Rechenleistung, weil man nicht die ganze Kommunikation verschlüsseln sondern nur den nächsten Zustand einmal errechnen muss. Wink

Aber man muss bei jedem Start eine neue Sequenz berechnen (sonst hätte man wieder das Problem mit dem primitiven Replay). D.h. man braucht genügend Variation, der übermittelte Datenblock braucht eine gewisse Länge. D.h. aus dem zufälligen Zustand (z.B. 8 bit) muss man einen Datenblock machen, der etwa 32bit lang ist (4Bytes). Die übermittelt man dann, nicht mehr. Man nennt das einen Blockverschlüssler mit Blocklänge 32bit, und hat die ganze Kommunikation verschlüsselt. Was Du machen willst, ist Verschlüsselung, also warum nicht Code/Protokolle dafür verwenden, die getestet sind und deren Schwächen man beziffern kann?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 15:46    Titel: Antworten mit Zitat

Die benötigte Rechenleistung für eine DES Implementation in einem AVR ist übrigens recht gering. Mit weniger als 2kB Code bekommt man einen Durchsatz von 32Bytes/s/MHz. D.h. mit einem 8MHz Prozessor hast 256 Bytes pro Sekunde. Da kannst Du schon ganz schön viel verschlüsseln.

Quelle: http://www.atmel.com/dyn/resources/prod_documents/doc2541.pdf, dort findet man auch den meiner Meinung nach sehr sauber geschriebenen Code dazu (des.c im zugehörigen Source Code Archiv, der GCC macht daraus 1688 Bytes Maschinencode).


Zuletzt bearbeitet von Andreas Müller am Do 22 Dez 2005, 16:30, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Reinhard



Anmeldungsdatum: 18.04.2005
Beiträge: 346

BeitragVerfasst am: Do 22 Dez 2005, 16:06    Titel: Antworten mit Zitat

Hi,

also wenns um die Rechenleistung geht, die neuen ARMs von Atmel gibt es auch mit einer Kryptoengine für AES und 3DES Wink . Aber im Ernst, wie sieht denn das Bedrohungsszenario überhaupt aus. Der Vergleich mit den sabotierten RC-Fliegern hinkt ein wenig, weil dort ja Standartkomponenten verwendet werden, und das KnowHow das zur gezielten Störung notwendig ist gegen Null geht (welchen Quarz brauche ich). Hier müsste ein Angreifer zumindest wissen welche Transceiver verwendet werden und wie man den verwendet. Wie viele potentielle Angreifer gibt es denn überhaupt (KnowHow+Motivation)? Die Szene ist ja auch viel kleiner als bei den Flächenfliegern.
IMHO reicht da irgendeine kleine "Security by Obscurity"-Lösung aus (auaaua, bitte nicht schlagen), die auf geringe Rechenleistung hin optimiert ist. Also alles was weniger offensichtlich als ein XOR mit dem Schlüssel ist. Andererseits ist es vermutlich kein großer Aufwand eine freie Implementierung für ein anerkanntes Verfahren zu finden.

Ein Zufallsgenerator mit einem µC ist ganz einfach zu realisieren. Man nehme einen möglichst einfachen analogen Oszillator (z.B. R+C+Inverter; mit der Frequenz f1). Dessen Spannung (im analogen Teil) wird mit dem ADC gesampelt (Samplingfrequenz f2). Wenn gilt: f1>>f2, der Oszillator unabhängig vom µC schwingt und man nur das LSB des ADC-Wertes verwendet, kommt man Dank Temperaturdrift, Bauteiltoleranzen und dem Rauschen einem idealen Zufallsgenerator schon sehr nahe, bei einem minimalen HW-Aufwand.

Meine Vorgehensweise wäre folgende.
1. Glauben alle Menschen wären gut, und ev. Platz für einen HW-Zufallsgenerator lassen.
2a) (unwahrscheinliche) negative Erfahrungen machen, oder
2b) Langweile haben (schon wahrscheinlicher)
3) dann ein Update durchführen


Gruß
Reinhard
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Autor Nachricht
Andreas Müller



Anmeldungsdatum: 28.02.2005
Beiträge: 2493
Wohnort: Altendorf

BeitragVerfasst am: Do 22 Dez 2005, 17:38    Titel: Antworten mit Zitat

Reinhard hat folgendes geschrieben:
Aber im Ernst, wie sieht denn das Bedrohungsszenario überhaupt aus.

Selbstverständlich können wir darüber wieder diskutieren. Wir sind uns aber einig, dass man schon etwas machen sollte. Also warum nicht die beste Lösung machen, die mit dem unvermeidlichen Minimalaufwand zu realisieren ist? Warum XOR verwenden, wenn DES genau gleich einfach zu haben ist? Warum ein schwaches Protokoll verwenden, wenn das starke bereits beschrieben ist, und genau gleich viel zu tun gibt (oder sogar weniger, weil man Code wiederverwenden kann)? Warum ein schlechte Lösung, wenn die bessere nicht teurer ist?

Zitat:
Ein Zufallsgenerator mit einem µC ist ganz einfach zu realisieren. Man nehme einen möglichst einfachen analogen Oszillator (z.B. R+C+Inverter; mit der Frequenz f1). Dessen Spannung (im analogen Teil) wird mit dem ADC gesampelt (Samplingfrequenz f2). Wenn gilt: f1>>f2, der Oszillator unabhängig vom µC schwingt und man nur das LSB des ADC-Wertes verwendet, kommt man Dank Temperaturdrift, Bauteiltoleranzen und dem Rauschen einem idealen Zufallsgenerator schon sehr nahe, bei einem minimalen HW-Aufwand.

Sag ich doch: man muss etwas vorsehen, ein Microcontroller hat von Haus aus keine Entropie. Man könnte aber wie schon erwähnt auch den Benutzer dafür vorsehen und zum Beispiel mit einem Timer on Chip die Zeit bis zur ersten Benutzerinteraktion messen. Dann braucht man gar keine Hardware. Wir benötigen ja nicht dauernd Entropie in grosser Menge, sondern nur am Anfang etwa 32bit (das gibt dann über 4*10^9 Anfangszustände). Übrigens tragen die Bauteiletoleranzen nichts zur Entropie bei.

Zitat:
3) dann ein Update durchführen

Warum nicht gleich von Anfang an versuchen, es richtig zu machen? Denn
1. es kostet nichts: keine zusätzliche Hardware (wenn man die Entropie vom Benutzer nimmt)
2. es verlangt keinen zusätzlichen Programmieraufwand, eher sogar weniger, weil man wesentliche Teile der Zustandsmaschine, den Cryptocode, bereits hat
3. man erhält garantierte Eigenschaften
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 18:03    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Aber man muss bei jedem Start eine neue Sequenz berechnen (sonst hätte man wieder das Problem mit dem primitiven Replay).

Nö, Du kannst auch auf beiden Seiten den letzten Zustand im EEProm speichern.

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Autor Nachricht
Juerg
Site Admin


Anmeldungsdatum: 27.02.2005
Beiträge: 4545
Wohnort: Oberengstringen

BeitragVerfasst am: Do 22 Dez 2005, 18:14    Titel: Antworten mit Zitat

Andreas Müller hat folgendes geschrieben:
Warum nicht gleich von Anfang an versuchen, es richtig zu machen?

Da bin ich Dir einig, aber wenn ich alles umsetzen wollte, was hier beschrieben worden ist, müsste ich froh sein auf das Members-Only ALRS hin fertig zu sein! Wink
Ein einfaches, gegen Replay robustes Protokoll ist z.B. auch:
Sender: "Entsichern"
Pad: "Entsichert, timestamp" (Zeit hat beim Einschalten zu laufen begonnen)
Sender: "Fire, timestamp+x" (innerhalb von 20 Sek)
Pad: -> Zündung

Beim Replay würde der Zeitstempel nicht stimmen.
Sowas auszutricksen setzt dann schon sehr viel Wissen, Equipment und kriminelle Energie voraus.

Aber natürlich kann man den Kanal auch verschlüsseln.
Was damit bleibt ist die Anforderung nach einem relativ langen Zünd-Kommando um das Risiko von Uebertragungsfehlern auszumerzen. Diese wird aber wohl bereits mit dem ganzen Aufwand für die Verschlüsselung erschlagen.

Gruss

Jürg

_________________
http://www.SpacetecRocketry.com
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    EURocketry Foren-Übersicht -> Zubehoer Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite 1, 2, 3  Weiter
Seite 1 von 3
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Powered by phpBB © 2001, 2002 phpBB Group
mtechnik