Hallo zusammen
ich bin Anfänger aber habe inzwischen ein paar Geräte von Homematic mit dem HM-USB zum laufen gebracht. Fhem läuft dabei bei mir auf einem Raspberry PI.
Heute habe ich mich einem HM-Sec-SCo Türsensor-Bausatz gewidmet und ihn zusammengelötet. Ist ja recht einfach. Was mich gewundert hat, ich habe den Türsensor nach dem Zusammenbau bereits in FHEM auffinden können. Ich habe bisher alle Geräte via autocreate hinzugefügt. Es war aber dieses mal nicht nötig einen
set hmusb hmPairForSec 60 abzusetzen.
Ist das normal?
Das wollte ich zum Anlass nehmen, um euch zu fragen ob ich "als Anfänger" vielleicht irgendeinen Sicherheitsmaßnahme vergessen haben könnte? Auch falls es normal sein sollte, dass sich der Türsensor automatisch finden ließ ohne einen Pairing-Befehl abzusetzen.
Was ich bisher gemacht habe: meine Netzwerk ist von außen nur mittels VPN erreichbar. FHEM Port Weiterleitung habe ich auch nicht. ist ja bei einer VPN auch nicht notwendig. Kann ja sein, dass es noch andere Sachen gibt. Hauscodes gibt es ja nicht bei Homematic so wie ich das verstanden haben. Über die AES Encryption (http://fhemwiki.de/wiki/AES_Encryption) habe ich gelesen. Würde mich interessieren ob ihr es nutzt. Vielleicht fällt euch was ein was man unbedingt für die Sicherheit tun sollte.
Gruß Tinko
Dein Türsensor ist nicht mit fhem gepaired.
Du kannst lediglich dessen Statusmeldungen sehen. Das geht bei HM eigentlich immer.
Wenn du ein list vom Sensor machst, steht da im Moment sinngemäß: paired to 0000000.
Ergo:
Du kannst ihn weder abfragen, noch mit anderen Devices peeren....
Moin Tinko,
Zitat von: Tinko am 01 April 2016, 21:31:01
Über die AES Encryption (http://fhemwiki.de/wiki/AES_Encryption) habe ich gelesen. Würde mich interessieren ob ihr es nutzt. Vielleicht fällt euch was ein was man unbedingt für die Sicherheit tun sollte.
Gruß Tinko
HM unterstützt keine AES Encryption, sondern nur AES Signing. Das bedeutet, dass die HM-Komponenten, wenn sie AES Signing können, nur Kommandos akzeptieren, welche mit dem geheimen AES Key "ge-signed" sind. Und ja, ich setzte das bei allen HM-Geräten ein, wenn sie es können.
Gruß,
Stephan
AES setze ich nur bei der Haustür ein. Da geht es auch gar nicht anders btw.
Ansonsten nicht. HM macht bei mir hauptsächlich Licht.
Zitat von: Rince am 01 April 2016, 22:13:04
Dein Türsensor ist nicht mit fhem gepaired.
Du kannst lediglich dessen Statusmeldungen sehen. Das geht bei HM eigentlich immer.
Wenn du ein list vom Sensor machst, steht da im Moment sinngemäß: paired to 0000000.
Ergo:
Du kannst ihn weder abfragen, noch mit anderen Devices peeren....
Mhh ist mit bisher nicht aufgefallen. Hatte den Sensor aber trotzdem sicherheitshalber noch mal gepaired. Ich kann mit ihm auch etwas steuern. Derzeit geht das Licht an wenn die Haustür geöffnet wird. Was mich aber wundert und vielleicht kannst du mir helfen es zu verstehen: ich wollte nach deinem Hinweis das Pairing überprüfen. Habe ein List auf den Sensornamen ausgeführt.
Internals:
CFGFN
DEF 4669A8
IODev hmusb
LASTInputDev hmusb
MSGCNT 85
NAME HM_E_Door
NR 1504
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 85
hmusb_RAWMSG E4669A8,0000,666ED48C,FF,FFB2,6E86104669A800000006010000
hmusb_RSSI -78
hmusb_TIME 2016-04-02 07:35:35
lastMsg No:6E - t:10 s:4669A8 d:000000 06010000
protCmdDel 4
protLastRcv 2016-04-02 07:35:35
protNack 1 last_at:2016-04-01 20:23:12
protSnd 1 last_at:2016-04-01 20:23:12
protState CMDs_done_Errors:1
rssi_at_hmusb avg:-69.65 min:-92 max:-55 lst:-78 cnt:85
Readings:
2016-04-02 06:52:58 Activity alive
2016-04-01 20:23:12 CommandAccepted no
2016-04-01 20:22:52 D-firmware 1.0
2016-04-01 20:22:52 D-serialNr NEQ0063181
2016-04-02 07:35:35 alive yes
2016-04-02 07:35:35 battery ok
2016-04-02 07:35:35 contact closed (to broadcast)
2016-04-02 07:35:35 recentStateType info
2016-04-02 07:35:35 sabotageError off
2016-04-02 07:35:35 state closed
2016-04-01 20:55:14 trigDst_broadcast noConfig
2016-04-01 20:55:14 trigger_cnt 98
Helper:
HM_CMDNR 110
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4669A8,00,00,00
nextSend 1459575335.94572
prefIO
rxt 2
vccu
p:
4669A8
00
00
00
Mrssi:
mNo 6E
Io:
hmusb -76
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -69.6588235294117
cnt 85
lst -78
max -55
min -92
Attributes:
IODev hmusb
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
room Entrance,HomeMatic
serialNr NEQ0063181
subType threeStateSensor Laut FHEM Wiki http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen) sollte ein Eintrag "R_pairCentral 0xABCDEF" auftauchen. Denn sehe ich aber gar nicht. Heißt das der Sensor ist nicht gepaired?
Zitat von: Rince am 02 April 2016, 08:17:04
AES setze ich nur bei der Haustür ein. Da geht es auch gar nicht anders btw.
Ansonsten nicht. HM macht bei mir hauptsächlich Licht.
Wie sieht es mit der HMID aus. Ich glaube die ist bei mir noch die Standardaddresse. Gefunden hier:
http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen)
Zitat...dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit:
attr <CUL> hmId <6-stellige Hexadresse>
zu individualisieren.
Zitat von: Tinko am 02 April 2016, 08:31:16Laut FHEM Wiki http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen sollte ein Eintrag "R_pairCentral 0xABCDEF" auftauchen. Denn sehe ich aber gar nicht. Heißt das der Sensor ist nicht gepaired?
wahrscheinlich nicht. es gab auch fehler während der kommunikation, siehe internals
protState CMDs_done_Errors:1also drüberpairen bis es funktioniert.
Zitat von: budy am 01 April 2016, 23:20:38
HM unterstützt keine AES Encryption, sondern nur AES Signing. Das bedeutet, dass die HM-Komponenten, wenn sie AES Signing können, nur Kommandos akzeptieren, welche mit dem geheimen AES Key "ge-signed" sind. Und ja, ich setzte das bei allen HM-Geräten ein, wenn sie es können.
sicher ist es nur, wenn du einen eigenen key benutzt, da der default-key gehacked ist.
ZitatCommandAccepted no
Du kannst ihn offenbar nicht abfragen. Er ist nicht gepaired.
Hi,
ich habe zwar einen Cube als CUL hatte aber auch Schwierigkeiten diesen Sesnor zu pairen
und sah das nur an einem fehlenden (leeren) PairedTo, dass er nicht gepaired ist
Man muss das Perlmodule Crypt::Rijndael nachinstallieren und dann pairen. (cpan -i Crypt::Rijndael).
Anschließend musste ich die readings löschen und dann den Connect Taster des Sensors nochmal drücken,
um alle readings richtig zu sehen.
Der Sensor signiert automatisch mit einem Std. Key. Ohne scheint das nicht zu gehen.
https://forum.fhem.de/index.php/topic,51480 (https://forum.fhem.de/index.php/topic,51480)
https://forum.fhem.de/index.php/topic,51629 (https://forum.fhem.de/index.php/topic,51629)
:)
linuxpaul
Edit: ggf. musst du bei deinem HM USB AES einrichten?
Zitat von: Rince am 02 April 2016, 09:44:00
Du kannst ihn offenbar nicht abfragen. Er ist nicht gepaired.
??? kapier ich gerade nicht. Was meint ihr mit "abfragen"? Er steuert gerade meine Flur-Lampe. Es ändert seinen Status of "open" sobald ich die Tür öffne und auf "closed" sobald sie zu ist. Bei "open" wird ein notify ausgelöst, dass wiederum den Flurlicht-Schalter für 5 min anstellt. Das funktioniert - darum bin ich verwirrt.
Sorry wenn ich gerade nix kapiere.
Drüber-Pairen schadet natürlich nicht. Kann ich später noch mal probieren.
Der Sensor bläst halt seine Nachrichten auch so hinaus und wenn du in FHEM ein Notify auf diese Events eingerichtet hast, dann wird es auch "abgearbeitet". Die eigentliche Frage nach der Sicherheit ist also, was die AES-signierte Kommunikation hier an Sicherheit bringt.
Und da kann es ja nur heißen, dass der FEHM nur noch auf signierte Funk-Telegramme reagiert, also niemand einfach eine Art Replay-Attacke fahren kann, weil er den geheimem AES-Key nicht kennt und somit dem FHEM keinen falschen Status vorspielen kann.
Command accepted: no bedeutet einfach nur, dass der FEHM dem Sensor ein Kommando geschickt hat, welches der Sensor nicht akzeptiert hat, was sich nur durch fehlendes pairing erklären lässt. Das ganze ist natürlich bei einem Sensor, der sonst nix macht etwas weniger offensichtlich, als bei einem Aktor, der dann einfach nicht schaltet.
Frage zum Replay:
Wenn ich den Verkehr für ein Replay sniffen kann, habe ich dann nicht auch die Signatur?
@Tinko
Ich kann nur empfehlen den Sensor ordentlich zu pairen. Ohne hatte ich Stress mit Missing Acks
und Deads. Lustiger Weise auch bei meinem Thermostat was zwichendurch mal die Arbeit eingestellt hat.
Seit dem der Sensor gepaired ist, funktioniert mein FHEM ohne zucken.
:)
linuxpaul
ZitatFrage zum Replay:
Wenn ich den Verkehr für ein Replay sniffen kann, habe ich dann nicht auch die Signatur?
Nein.
vg
joerg
Zitat von: herrmannj am 02 April 2016, 20:22:02
Nein.
vg
joerg
Ha ha - geile Antwort! Kurz, richtig - aber hilft nicht. ;)
Gruß,
Stephan
Zitat von: frank am 02 April 2016, 09:38:54
wahrscheinlich nicht. es gab auch fehler während der kommunikation, siehe internals
protState CMDs_done_Errors:1
also drüberpairen bis es funktioniert.
sicher ist es nur, wenn du einen eigenen key benutzt, da der default-key gehacked ist.
Also noch zwei mal gepaired und nun sieht es besser aus.
Internals:
CFGFN
DEF 4669A8
IODev hmusb
LASTInputDev hmusb
MSGCNT 208
NAME HM_E_Door
NR 1504
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 208
hmusb_RAWMSG RD8D631D3,0021,69CCDCF9,00,FFB6,E680024669A812345600007D94B4
hmusb_RSSI -74
hmusb_TIME 2016-04-02 23:17:09
lastMsg No:E6 - t:02 s:4669A8 d:123456 00007D94B4
protCmdDel 4
protEvt_AESCom-ok 3 last_at:2016-04-02 23:17:09
protLastRcv 2016-04-02 23:17:09
protNack 1 last_at:2016-04-01 20:23:12
protSnd 4 last_at:2016-04-02 23:17:09
protState CMDs_done
rssi_at_hmusb lst:-74 cnt:202 avg:-72.02 min:-95 max:-55
Readings:
2016-04-02 23:17:08 Activity alive
2016-04-02 23:17:09 CommandAccepted yes
2016-04-02 23:17:08 D-firmware 1.0
2016-04-02 23:17:08 D-serialNr NEQ0063181
2016-04-02 23:17:08 R-pairCentral set_0x123456
2016-04-02 23:17:09 aesCommToDev ok
2016-04-02 23:17:09 aesKeyNbr 00
2016-04-02 22:54:35 alive yes
2016-04-02 23:07:48 battery ok
2016-04-02 23:07:48 contact closed (to broadcast)
2016-04-02 22:54:35 recentStateType info
2016-04-02 22:54:35 sabotageError off
2016-04-02 23:07:48 state closed
2016-04-02 23:07:48 trigDst_broadcast noConfig
2016-04-02 23:07:48 trigger_cnt 198
Helper:
HM_CMDNR 230
cSnd 011234564669A8000802010A120B340C56,011234564669A80006
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4669A8,00,00,00
nextSend 1459631829.59149
prefIO
rxt 2
vccu
p:
4669A8
00
00
00
Mrssi:
mNo E6
Io:
hmusb -72
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -72.0297029702971
cnt 202
lst -74
max -55
min -95
Shadowreg:
RegL_00. 02:01 0A:12 0B:34 0C:56
Attributes:
IODev hmusb
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
room Entrance,HomeMatic
serialNr NEQ0063181
subType threeStateSensor Also AES Signing macht Sinn. :) Danke für die Erklärungen. Muss jetzt mal überlegen ob ich das mache. Bisher habe ich nur Licht gesteuert. Aber wenn sich das ändert wird es spätestens Zeit dafür.
Noch mal zurück zu der Frage bezüglich HMID. Default Wert ändern oder nicht weil es ohne AES Signing eh nix bringt?
ZitatNoch mal zurück zu der Frage bezüglich HMID. Default Wert ändern oder nicht weil es ohne AES Signing eh nix bringt?
egal, wer will kann es sowieso "sehen". nur wenn du vielle homematic nachbarn hast, wäre es ungeschickt, wenn alle 0xABC123 haben. ;)
Sorry, wieder nix,
Hier würde der CUL und nicht broadcast stehen
contact closed (to broadcast)
Zum Vergleich:
Internals:
CUL_Cube_serial_MSGCNT 93
CUL_Cube_serial_RAWMSG A0D62A6104342A44091370601C800::-75:CUL_Cube_serial
CUL_Cube_serial_RSSI -75
CUL_Cube_serial_TIME 2016-04-03 12:31:02
DEF 4342A4
IODev CUL_Cube_serial
LASTInputDev CUL_Cube_serial
MSGCNT 93
NAME Haustechnik_Tuer
NR 53
STATE open
TYPE CUL_HM
lastMsg No:62 - t:10 s:4342A4 d:409137 0601C800
protLastRcv 2016-04-03 12:31:02
protSnd 93 last_at:2016-04-03 12:31:02
protState CMDs_done
rssi_at_CUL_Cube_serial avg:-75.77 lst:-75 cnt:93 min:-86 max:-70.5
Readings:
2016-03-31 18:43:19 Activity alive
2016-03-31 16:31:00 CommandAccepted yes
2016-03-31 16:55:59 D-firmware 1.0
2016-03-31 16:55:59 D-serialNr MEQ1725261
2016-03-31 16:56:00 PairedTo 0x409137
2016-03-31 16:56:00 R-cyclicInfoMsg on
2016-03-31 16:56:00 R-eventDlyTime 0 s
2016-03-31 16:56:00 R-pairCentral 0x409137
2016-03-31 16:56:00 R-sabotageMsg on
2016-03-31 16:56:00 R-sign on
2016-03-31 16:55:59 RegL_00. 02:01 09:01 0A:40 0B:91 0C:37 10:01 14:06 00:00
2016-03-31 16:56:00 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-03-31 16:31:00 aesCommToDev ok
2016-03-31 16:31:00 aesKeyNbr 00
2016-04-03 12:31:02 alive yes
2016-04-03 12:31:02 battery ok
2016-04-03 12:31:02 contact open (to Friseur_Tuer)
2016-03-31 16:56:47 powerOn 2016-03-31 16:56:47
2016-04-03 12:31:02 recentStateType info
2016-04-03 12:31:02 sabotageError off
2016-04-03 12:31:02 state open
2016-04-03 10:44:33 trigDst_Friseur_Tuer noConfig
2016-04-03 10:44:33 trigger_cnt 23
Attributes:
IODev CUL_Cube_serial
actCycle 001:05
actStatus alive
autoReadReg 4_reqStatus
devStateIcon closed:fts_door_right@green open:fts_door_right_open@red
expert 2_raw
firmware 1.0
group Alarm Sensor
icon IR
model HM-SEC-SCo
peerIDs 00000000,
room Haustechnik,Hardware
serialNr MEQ1725261
subType threeStateSensor
PairedTo und R-pairCentral müssen die richtige ID haben.
Hast du das PerlModul installiert?
:)
linuxpaul
Zitat von: linuxpaul am 03 April 2016, 13:02:33
Sorry, wieder nix,
Hier würde der CUL und nicht broadcast stehen
contact closed (to broadcast)
PairedTo und R-pairCentral müssen die richtige ID haben.
Hast du das PerlModul installiert?
:)
linuxpaul
Sorry für meine späte Reaktion. Die letzten Tage war viel los und ich bin nicht dazu gekommen. Heute Abend habe ich es noch mal probiert. Noch mal zweimal gepaired (einfach nur um es zu testen ob sich was ändert) und dann noch der Anleitung im Wiki gefolgt.
Zitat
- [noch einmal probieren, ein getConfig auszulösen - vielleicht hat das Lesen nicht funktioniert
- noch einmal pairen - das schadet nichts
- [die Anlerntaste / Configtaste / irgendeine Taste am Gerät (hängt vom konkreten Device ab) wiederholt drücken um die Datenübertragung anzustoßen.
Jetzt sieht es so aus:
Internals:
CFGFN
DEF 4669A8
IODev hmusb
LASTInputDev hmusb
MSGCNT 393
NAME HM_E_Door
NR 1504
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 393
hmusb_RAWMSG RE7AFABE4,0001,78A65EF6,FF,FFB7,8EA0104669A81234560100000000
hmusb_RSSI -73
hmusb_TIME 2016-04-05 20:29:23
lastMsg No:8E - t:10 s:4669A8 d:123456 0100000000
protCmdDel 4
protEvt_AESCom-ok 6 last_at:2016-04-05 20:15:03
protLastRcv 2016-04-05 20:29:23
protNack 1 last_at:2016-04-01 20:23:12
protResnd 1 last_at:2016-04-05 20:29:02
protSnd 177 last_at:2016-04-05 20:29:23
protState CMDs_done
rssi_at_hmusb avg:-73.62 min:-95 max:-55 lst:-73 cnt:381
Readings:
2016-04-05 20:29:21 Activity alive
2016-04-05 20:15:03 CommandAccepted yes
2016-04-05 20:29:21 D-firmware 1.0
2016-04-05 20:29:21 D-serialNr NEQ0063181
2016-04-05 20:29:22 PairedTo 0x123456
2016-04-03 00:44:09 R-cyclicInfoMsg on
2016-04-03 00:44:09 R-eventDlyTime 0 s
2016-04-05 20:28:47 R-pairCentral 0x123456
2016-04-03 00:44:09 R-sabotageMsg on
2016-04-03 00:44:09 R-sign on
2016-04-05 20:29:22 RegL_00. 02:01 09:01 0A:12 0B:34 0C:56 10:01 14:06 00:00
2016-04-05 20:29:22 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2016-04-05 20:15:03 aesCommToDev ok
2016-04-05 20:15:02 aesKeyNbr 00
2016-04-05 20:10:44 alive yes
2016-04-05 20:10:44 battery ok
2016-04-05 20:10:44 contact closed (to hmusb)
2016-04-05 20:10:44 recentStateType info
2016-04-05 20:10:44 sabotageError off
2016-04-05 20:10:44 state closed
2016-04-05 19:49:50 trigDst_123456 noConfig
2016-04-02 23:07:48 trigDst_broadcast noConfig
2016-04-05 19:49:50 trigger_cnt 16
Helper:
HM_CMDNR 142
cSnd 011234564669A801040000000001,011234564669A80103
mId 00C7
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newCh 1
newChn +4669A8,00,00,00
nextSend 1459880963.18556
prefIO
rxt 2
vccu
p:
4669A8
00
00
00
Mrssi:
mNo 8E
Io:
hmusb -71
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmusb
flg A
ts 1459880963.12276
ack:
HASH(0x19840a0)
8E80021234564669A800
Rssi:
At_hmusb:
avg -73.6246719160105
cnt 381
lst -73
max -55
min -95
Shadowreg:
Attributes:
IODev hmusb
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,
room Entrance,HomeMatic
serialNr NEQ0063181
subType threeStateSensor Das von dir erwähnte Perl Modul habe ich noch nicht installiert. Brauche ich es jetzt trotzdem noch??? Ich kann jetzt nicht mehr erkennen, dass das Pairing nicht geklappt hat. Aber ihr habt mehr Erfahrung... :-\
Gruß Tinko
PS: Hast du einen Friseur? ;D
Na ja, das Device ist mit folgendem gepaired:
2016-04-05 20:29:22 PairedTo 0x123456
Du solltest am besten wissen, welches Device 123456 ist - hoffentlch dein FHEM... ;)
Gruß,
Stephan
laut Wiki (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen#Pairing_verifizieren) sollte unter PairedTo 0x<HMID des IO Device> stehen.
Mein HM-USB hat den Readings-Eintrag:
D-HMIdAssigned 123456
Also für mich als Laie sieht es jetzt gut aus. Auch ohne Pearl-Modul. Dann kann ich da jetzt einen Haken dran machen?
Da du ein HM_USB hast, kann das schon sein, dass das ohne Modul geht,
da die HW AES kann. Hab ich zumindest hier wo gelesen, glaube ich.
Wenn die ID passt, schaut der Rest auch gut aus, zumindest für mich.
:)
linuxpaul
Na da bin ich aber froh. ;D
danke für eure Hilfe
@budy: Es ist absoluter Käse, bei jedem HM-Device AES einzusetzen, davon rät sogar der Hersteller ab. Erstens vergrößert das die Funklast (siehe 1%-Regel...), zweitens sorgt das für merkbare Verzögerungen bei Schaltbefehlen. Vom Batterieverbrauch ganz zu schweigen...
Darüber hinaus ist das Verfahren auch kein Signaturverfahren im strengen Sinn. Alle Schaltbefehle und Daten sind im Klartext mitlesbar, sie werden auch nicht signiert. Sondern es handelt sich um ein Challenge-Response-Verfahren, nur die Challenge wird mit dem AES-Key verschlüsselt und als Response zurückgesandt.
LG
pah
P.S.: @Tinko: Nur der Vollständigkeit halber: Es heißt Perl.
Zitat von: Prof. Dr. Peter Henning am 08 April 2016, 04:40:29
P.S.: @Tinko: Nur der Vollständigkeit halber: Es heißt Perl.
;D Aber gegen eine echte Perle hätte ich auch nix!!! ::)