wo soll der private schlüssel gespeichert werden?
<p>angenommen, ich möchte, dass einige teile meiner software verschlüsselt werden. zum beispiel die anmeldeinformationen für eine datenbank usw. ich muss diese werte irgendwo speichern, aber dies im klartext zu tun, würde es einem angreifer leicht machen, unbefugten zugriff zu erhalten.</p><p>wenn ich jedoch klartext verschlüssele, wo speichere ich dann den schlüssel? auf alles, worauf software zugriff hat, hätte ein entschlossener angreifer zugriff, unabhängig von der verschleierung:</p><ul> <li>angenommen, der schlüssel ist durch das sicherheitsmodell des dateisystems geschützt. aber was ist mit (böswilligen) superusern oder plattformen, die keine solche wiedergabetreue bieten?</li> <li>oder der schlüssel ist fest in software-binärdateien codiert, kann aber immer dekompiliert werden, und was ist mit open source-software oder interpretiertem code?</li> <li>wenn der schlüssel generiert wird, müsste ein solcher algorithmus (vermutlich) deterministisch sein, und dann gilt das gleiche problem für den startwert.</li> <li>usw.</li> </ul><p>kryptographie ist nur so stark wie das schwächste glied in seiner kette und dies scheint ziemlich locker zu sein! vorausgesetzt, es ist das richtige werkzeug für den job (humor mich), wie kann man dann solche informationen robust sichern?</p><hr><p>in bezug auf das richtige tool für den job: wahrscheinlich würden sie beispielsweise im fall des dienstzugriffs (dbs, authentifizierungsserver usw.) den zugriff auf dieser ebene mit einem dienstkonto einschränken, möglicherweise mit einem bestimmten service-level auditing usw. und damit die anmeldeinformationen im klartext zu haben, ist keine solche sorge.</p><p>für mich scheint das jedoch immer noch unzureichend: ich möchte nicht, dass jemand dort herumstochert, wo er nicht sein sollte!</p>
<p>zunächst einmal würde ich mich nicht als sicherheitsexperte bezeichnen, aber ich war in der lage, diese frage beantworten zu müssen. was ich herausgefunden habe, hat mich ein bisschen überrascht: <em> es gibt kein vollständig sicheres system</em>. nun, ich denke, ein völlig sicheres system wäre eines, bei dem alle server ausgeschaltet sind :)</p><p>jemand, der damals mit mir zusammenarbeitete, beschrieb das entwerfen eines sicheren systems in bezug auf <em> die messlatte höher legen</em> für eindringlinge. jede sicherungsebene verringert also die möglichkeit eines angriffs.</p><p>selbst wenn sie beispielsweise den privaten schlüssel perfekt sichern könnten, ist das system nicht <em> vollständig</em> sicher. die korrekte verwendung der sicherheitsalgorithmen und die aktualisierung der patches legen jedoch die messlatte höher. aber ja, ein supercomputer, der leistungsfähig genug ist und genügend zeit hat, kann die verschlüsselung unterbrechen. ich bin sicher, dass all dies verstanden wird, also werde ich die frage zurückbekommen.</p><p>die frage ist klar, also werde ich zuerst versuchen, jeden ihrer punkte anzusprechen:</p><blockquote> <p>angenommen, der schlüssel ist durch das sicherheitsmodell des dateisystems geschützt. aber was ist mit (böswilligen) superusern oder plattformen, die keine solche wiedergabetreue bieten?</p> </blockquote><p>ja, wenn sie etwas wie <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb204778%28v=vs.85%29.aspx">windows key store</a> oder einen kennwortverschlüsselten privaten tls-schlüssel verwenden, sind sie den benutzern ausgesetzt, die über das kennwort (oder den zugriff) auf die privaten schlüssel verfügen. aber ich denke, sie werden mir zustimmen, dass dies die messlatte höher legt. die dateisystem-acls bieten (wenn sie ordnungsgemäß implementiert sind) ein ziemlich gutes schutzniveau. und sie sind in der lage, ihre superuser persönlich zu überprüfen und zu kennen.</p><blockquote> <p>oder der schlüssel ist fest in software-binärdateien codiert, kann aber immer dekompiliert werden, und was ist mit open source-software oder interpretiertem code?</p> </blockquote><p>ja, ich habe fest codierte schlüssel in binärdateien gesehen. auch dies legt die messlatte ein wenig höher. jemand, der dieses system angreift (wenn es java ist), muss verstehen, dass java erzeugt bytecode (usw.) und versteht, wie man es dekompiliert, liest es. wenn sie eine sprache verwenden, die direkt schreibt beim maschinencode können sie sehen, dass dies die messlatte etwas höher legt. dies ist keine ideale sicherheitslösung, könnte aber ein gewisses maß an schutz bieten.</p><blockquote> <p>wenn der schlüssel generiert wird, müsste ein solcher algorithmus (vermutlich) deterministisch sein, und dann gilt das gleiche problem für den startwert.</p> </blockquote><p>ja, im wesentlichen wird der algorithmus dann zur privaten schlüsselinformation zum erstellen des privaten schlüssels. es müsste also jetzt geschützt werden.</p><p>ich denke, sie haben bei jeder sicherheitsrichtlinie ein kernproblem festgestellt: <strong> schlüsselverwaltung </strong>. die einrichtung einer schlüsselverwaltungsrichtlinie ist für die bereitstellung eines sicheren systems von zentraler bedeutung. und es ist ein <a href="http://en.wikipedia.org/wiki/key\_management">ziemlich breites thema</a> .</p><p>die frage ist also, wie sicher ihr system (und damit der private schlüssel) sein muss. wie hoch muss in ihrem system die messlatte höher gelegt werden?</p><p>wenn sie bereit sind zu zahlen, gibt es einige leute, die lösungen dafür finden. am ende haben wir ein <a href="http://en.wikipedia.org/wiki/hardware\_security\_module">hsm (hardware security module)</a> verwendet. es handelt sich im grunde genommen um einen manipulationssicheren server, der einen schlüssel in der hardware enthält. dieser schlüssel kann dann verwendet werden, um andere schlüssel zu erstellen, die für die verschlüsselung verwendet werden. die idee hier ist, dass (wenn richtig konfiguriert) der schlüssel <em> nie verlässt</em> das hsm. hsms kosten <em> viel</em>. in einigen unternehmen (z. b. beim schutz von kreditkartendaten) sind die kosten eines verstoßes jedoch viel höher. es gibt also ein gleichgewicht.</p><p>viele hsms verwenden schlüsselkarten aus der wartung und verwaltung der funktionen. ein quorum von schlüsselkarten (5 von 9, sagen wir) muss physisch in den server eingelegt werden, um einen schlüssel zu ändern. dies legt die messlatte also ziemlich hoch, indem nur dann ein verstoß zugelassen wird, wenn ein quorum von superusern zusammenarbeitet.</p><p>es gibt möglicherweise softwarelösungen, die ähnliche funktionen wie ein hsm bieten, aber ich weiß nicht, um welche es sich handelt.</p><p>ich weiß, dass dies nur einen weg zur beantwortung der frage darstellt, aber ich hoffe, dass dies hilft.</p>
hallo,

jeder kann eine verschlüsselung entwickeln, die er selbst nicht brechen kann. das bedeutet allerdings keinesfalls, das diese sicher ist und einer cryptoanalyse standhält.

das erste, was mir an deinem chiffrierten text auffällt, ist das er nicht wirklich zufällig ist. verschlüsselte daten so… <blockquote> <p>angenommen, der server soll daten mit dem privaten schlüssel verschlüsseln und mit dem öffentlichen schlüssel entschlüsseln, um daten zu verteilen, von denen überprüft werden kann, dass sie vom richtigen server stammen.</p> </blockquote><p>sie können dies tun - auf eine sehr vereinfachte ebene funktioniert die rsa-signatur (anmerkung, vereinfacht - es steckt noch ein bisschen mehr dahinter).</p><blockquote> <p>kann ich den privaten schlüssel einfach veröffentlichen und den öffentlichen schlüssel geheim halten, anstatt den code zu ändern, um dies zu ermöglichen? beeinträchtigt dies die sicherheit des systems?</p> </blockquote><p>sie <strong> müssen den privaten schlüssel überhaupt nicht </strong> veröffentlichen - rsa ist eine trapdoor-permutation, was bedeutet:</p><ul> <li>wenn sie mit einem öffentlichen schlüssel verschlüsseln, können sie mit dem privaten schlüssel entschlüsseln.</li> <li>wenn sie mit einem privaten schlüssel verschlüsseln, können sie mit einem öffentlichen schlüssel entschlüsseln.</li> </ul><p>daher unterstützt rsa sowohl das signieren als auch das verschlüsseln, wobei der endbenutzer nur über den öffentlichen schlüssel verfügt.</p><p>wenn der client in ihrem fall überprüfen möchte, ob daten vom server stammen, wenden sie den zweiten fall von rsa an und entschlüsseln die signaturdaten mit dem bereits vorhandenen öffentlichen schlüssel.</p><p>da es sich um eine permutation handelt, sollten sie ihren code außerdem überhaupt nicht ändern müssen. beide tasten sollten mit derselben funktion arbeiten. ich würde erwarten, dass jede anständige kryptobibliothek apis zur überprüfung von signaturen gemäß den unterschiedlichen standards hat - eine davon wäre wahrscheinlich eine gute wahl.</p><p>rsa labs bieten ein nice <a href="https://web.archive.org/web/20130718172549/https://www.rsa.com/rsalabs/node.asp?id=2182">erklärung hierfür</a> .</p><p>wenn sie dies zwischen servern erweitern oder die clientkommunikation überprüfen möchten, generieren sie schlüssel für jede entität und tauschen sie die öffentlichen aus. das verfahren kann dann an beiden enden angewendet werden.</p><p>theoretisch sind e und d austauschbar (weshalb rsa funktioniert) (man muss als geheim bezeichnet und geheim gehalten werden), aber p und q müssen <strong> immer </strong> sein geheim gehalten, da diese es ihnen ermöglichen, d von e abzuleiten und umgekehrt. sie müssen jedoch beim verständnis des privaten schlüssels äußerst vorsichtig sein - speichert ihre software p/q im privaten schlüssel? wenn ja, können sie es nicht so veröffentlichen, wie es ist. auch wenn ich austauschbar sage - sobald sie eines dieser paare (e oder d zusammen mit ihrem modul n) veröffentlicht haben, müssen sie das andere <em> mit ihrem leben</em> schützen. praktisch gesehen <a href="https://stackoverflow.com/questions/696472/given-a-private-key-is-it-possible-to-derive-its-public-key">wie graeme in den kommentaren verlinkt</a> e wird oft als kleiner/fester wert gewählt. mein kommentar, dass e/d austauschbar ist, trifft eindeutig nicht zu, wenn e leicht zu bestimmen ist. wenn sie so etwas tun, kann dies zu verwirrung und fehlimplementierung führen. verwenden sie eine bibliothek eines drittanbieters/veröffentlichen sie keine privaten schlüssel.</p> Da musst du dich mit den Begriffen "digitale Signatur" (siehe <http://de.wikipedia.org/wiki/Digitale_Signatur>) und PKI bzw. Zertifikate auseinander setzen. Ist nicht sooo schwierig, wenn man einmal das Grundprinzip begriffen hat. Und es gibt auch genug Gratis-Lösungen wie z.B. PGP.


In einem Schnellverfahren erklärt:
Ein solcher digitaler "Schlüssel" besteht immer aus 2 Teilen, einem privaten Schlüssel (das ist dein Heiligtum, welches du nie weitergeben darfst) und einem öffentlichen Schlüssel (den müssen alle Beteiligten bekommen -> den musst du so viel wie möglich verbreiten bzw. sollte der auf einem Server im Internet für alle verfügbar gemacht werden).


Wenn du nun etwas verschlüsselst, musst du das **immer mit dem öffentlichen Schlüssel aller Empfänger** verschlüsseln (die musst du natürlich vorher von denen bekommen) -> denn nur diese können die E-Mail dann mit Hilfe ihres jeweiligen privaten Schlüssels wieder entschlüsseln.


Fazit: nur mit solchen Techniken lassen sich Manipulationen verhindern bzw. nachweisen. hallo,

habt ihr das gerät schon mal aus-und wieder eingeschaltet? so komisch das auch klingt, aus meiner erfahrung behebt das schon viele komische fehler.

als nächstes könnte man die daten des gerätes sichern. entweder in die cloud oder auf einen pc. anschließend kann man das gerät zurück setzen. … Hast du ein Backup deiner Daten? ...nein?  
Dann ist der Fall abgeschlossen ich hoffe du weist jetzt wofür Datensicherungen gut sind. <p>es ist keine schwäche für einen kurzen oder langen öffentlichen exponenten für rsa bekannt, solange der öffentliche exponent "korrekt" ist (dh relativ prim zu <em> p-1</em> für alle primzahlen <em> p </em> welche den modul teilen).</p><p><em> if</em> sie verwenden einen kleinen exponenten <em> und</em> sie verwenden kein padding für die verschlüsselung <em> und</em> sie verschlüsseln genau dieselbe nachricht mit bei mehreren unterschiedlichen öffentlichen schlüsseln ist ihre nachricht gefährdet: if <em> e = 3</em> und sie verschlüsseln die nachricht <em> m</em> mit öffentlichen schlüsseln <em> n<sub>1</sub></em>, <em> n<sub>2</sub></em> und <em> n<sub>3</sub></em>, dann hast du <em> c<sub>ich</sub> = m<sup>3</sup></em> mod <em> n<sub>ich</sub></em> für <em> i = 1</em> bis <em> 3</em>. mit dem <a href="http://en.wikipedia.org/wiki/chinese\_remainder\_theorem">chinesischer restsatz</a> können sie dann <em> m<sup>3</sup></em> mod <em> n<sub>1</sub>n<sub>2</sub>n<sub>3</sub></em>, was sich als <em> m herausstellt<sup>3</sup></em> (ohne modulo) weil <em> n<sub>1</sub>n<sub>2</sub>n<sub>3</sub></em> ist eine größere ganze zahl. eine (nicht modulare) kubikwurzelextraktion reicht dann aus, um <em> m</em> zu extrahieren.</p><p>die schwäche ist hier <strong> nicht </strong> der kleine exponent; vielmehr ist es die verwendung einer falschen auffüllung (nämlich überhaupt keine auffüllung) für die verschlüsselung. das auffüllen ist für die sicherheit von rsa sehr wichtig, egal ob verschlüsselung oder signatur. wenn sie keine ordnungsgemäße polsterung verwenden (wie die in <a href="http://www.rsa.com/rsalabs/node.asp?id=2125">pkcs # 1</a> beschriebenen), haben sie viele schwächen, und die im obigen absatz beschriebene ist bei weitem nicht die größte. wenn sich jemand jedoch auf eine schwäche im zusammenhang mit der exponentengröße bezieht, bezieht er sich mehr oder weniger direkt auf dieses ereignis. das ist ein bisschen alte und falsche überlieferung, die manchmal in ein verbot gegen <em> groß</em> exponenten umgewandelt wird (da es sich um einen mythos handelt, ist der umgekehrte mythos auch ein mythos und nicht mehr - und nein weniger begründet); ich glaube, das beobachten sie hier.</p><p>es gibt jedoch einige gründe, warum ein großer öffentlicher exponent vermieden werden sollte:</p><ul> <li> <p>kleine öffentliche exponenten fördern die effizienz (für public-key-operationen).</p> </li> <li> <p>es gibt sicherheitsprobleme, wenn ein kleiner exponent <em> privat</em> vorhanden ist. ein schlüsselwiederherstellungsangriff wurde beschrieben, wenn die länge des privaten exponenten nicht mehr als 29% der länge des öffentlichen exponenten beträgt. wenn sie erzwingen möchten, dass der private exponent kurz ist (z. b. um operationen mit privaten schlüsseln zu beschleunigen), müssen sie mehr oder weniger einen großen öffentlichen exponenten verwenden (so groß wie der modul). die forderung, dass der öffentliche exponent kurz sein muss, kann dann als eine art indirekte gegenmaßnahme angesehen werden.</p> </li> <li> <p>einige weit verbreitete rsa-implementierungen drosseln große öffentliche rsa-exponenten. z.b. der rsa-code in windows (cryptoapi, von internet explorer für https verwendet) besteht darauf, den öffentlichen exponenten in einem einzelnen 32-bit-wort zu codieren. es kann keinen öffentlichen schlüssel mit einem größeren öffentlichen exponenten verarbeiten.</p> </li> </ul><p>dennoch sieht "risiken können groß sein" wie die allgemeine rechtfertigung aus ("dies ist ein sicherheitsproblem" ist die übliche art zu sagen "wir haben es nicht implementiert, aber wir wollen keine art von faulheit zugeben").</p> > 
> Das Briefgeheimnis und das Recht auf Privatsphäre (Geheimsphäre) schützt Briefeschreiber vor einer Veröffentlichung ihrer Briefe. 
> 
> 
> 


Korrekt, wenn du die Wörter "Briefgeheimnis und das" streichst. 



> 
> Wenn ich bsw. meinem Chef einen Brief schreibe, so darf dieser den Brief nicht einfach herumzeigen oder gar veröffentlichen.
> 
> 
> 


Im Grundsatz schon. Das kommt ganz auf den Inhalt des Briefes und die äußeren Umstände an.



> 
> Doch wie sieht das mit Briefen von Ämtern oder der Stadt aus. Unterliegen Behörden und Ämter ebenso diesem Privacy-Schutz, oder ist dies wegen des Amtes da anders. 
> 
> 
> 


Behörden, Ämter usw. genießen keinen Persönlichkeitsschutz, wohl aber die Mitarbeiter. Außerdem kann sich aus der Natur der rechtlichen und sachlichen Beziehung zueinander ein Anspruch auf Geheimniswahrung ergeben.



> 
> Kann ich ein Schreiben meiner Stadt auf meine Website stellen ohne vorher um Erlaubnis zu fragen?
> 
> 
> 


Im Grundsatz ja. Aber es gibt einige Schranken zu beachten:


1. Du solltest aber den Namen des Mitarbeiters (auch sein Kürzel) unkenntlich machen, da du gegen sein Persönlichkeitsrecht verstoßen könntest.
2. Du könntest aufgrund Vertrages oder Gesetzes oder aufgrund deiner Aufgabe oder der Art der Beziehung zu der Behörde zur Geheimhaltung verpflichtet sein.
3. Das Schreiben könnte urheberrechtlichen Schutz genießen (bei einer alltäglichen Mitteilung allerdings unwahrscheinlich). Kein Problem !
Es gibt zwei Wege:
1. Beides ins Handgepäck ( Laptop-Rucksack ). Bei der Handgepäckkontrolle müssen beide Teile herausgenommen und auf das Prüfband gelegt werden.
2. Ins aufgegebene Fluggepäck ( gegen Stöße mittels Luftpolsterfolien oder weiche Gepäckstücke geschützt) und beim Einchecken mit aufgeben. Zum Diebstahlschutz vertrauliche Daten auf externen Datenträger auslagern und diesen ins Handgepäck stecken. Aufgegebenes Fluggepäck ist pro Gepäckstück nur begrenzt versichert ( von Fluggesellschaft zu Gesellschaft verschiedene Versicherungshöhen ) Sehr geehrte/r Ratsuchende/r,  
  

selbstverständlich darf der Arbeitgeber nicht einfach Ihren Spind räumen. Wenn der Arbeitgeber den Spind anderweitig vergeben möchte, muss er Sie bitten, dass SIE oder eine von Ihnen beauftragte Person den Spind räumen. Keinesfalls darf er, ohne Sie zuvor vergeblich unter Fristsetzung zur Räumung aufgefordert zu haben, den Spind einfach selber öffnen bzw. räumen. Erst recht darf er nicht Einsicht in Ihre persönliche Dokumente nehmen und / oder Dritte darüber in Kenntnis setzen. Dies stellt eindeutig eine Verletzung Ihres allgemeinen Persönlichkeitsrechts, darüber hinaus eine Verletzung der Bestimmungen des Bundesdatenschutzgesetztes, dar. Etwas anderes kann - in besonderen Ausnahmefällen- dann gelten, wenn gegen den Arbeitnehmer der konkrete Verdacht einer Straftat besteht und die "heimliche" Öffnung des Spinds zwingend erforderlich ist, um die Straftat aufzudecken. Ansonsten ist der Spind aber für den Arbeitgeber tabu. Ich hoffe, Ihnen mit meiner Antwort geholfen zu haben und wünsche Ihnen einen schönen Tag.  
  

Ihr   
  

Matthias Filz  

Rechtsanwalt Naja, der Quelltext von frei lizenzierter Software wird üblicherweise in einem Online-Quellcodeverwaltungssystem organisiert. Diese Verwaltungssysteme müssen von irgendjemandem gehostet werden, es gibt aber auch kostenlose Angebote wie SourceForge (Subversion) oder GitHub (git). Und von der dort eingesetzten Software hängt es dann auch mehr oder weniger ab, wie man idealerweise zwecks Beteiligung vorgeht. Bei SourceForge muss der Projekt-Administrator dem SourceForge-Account des Entwicklers Schreibberechtigung einrichten, damit letzterer, nachdem er mittels Subversion die aktuelle Fassung des Codes heruntergeladen und seine Änderungen vorgenommen hat, diese auch wieder ins Online-Repository hochladen kann. Bei GitHub klont man sich gleich den ganzen Code auf den eigenen GitHub-Account ("Fork" genannt), lädt sich mittels git die eigene Online-Kopie lokal herunter, ändert diese, lädt in den eigenen Fork hoch und hinterlegt dem Projekt-Administrator des Originals eine Benachrichtigung, dass dieser doch die Änderungen des Forks in die offizielle Version übernehmen soll. Es empfiehlt sich generell, über die Ticket-Systeme der Projekte die Arbeit an offenen Aufgaben abzusprechen oder für das eigene Anliegen ein neues Ticket zu öffnen, was vor allem bei SourceForge auch darum wichtig ist, um konfligierende Änderungen und das dadurch notwendige Merging möglichst zu vermeiden, sodass die "Bewerbung" bei GitHub-Projekten allgemein einfacher ist, weil man da erstmal unabhängig arbeiten kann.


Bei mir sieht das dann so aus:


<https://github.com/skreutzer>


ist aber nicht gerade als repräsentativ zu betrachten.