Moin,
aus den bereits genannten Gründen und Weiteren finde ich es wichtig, dass hier Freie Software und offene Standard bei den Schnittstellen zum Einsatz kommen.
Am Donnerstag 11 Januar 2018 14:42:32 schrieb Dr. Michael Stehmann:
beA ist IMO "broken by design"
Der Punkt ist mir noch nicht ganz klar, was meinst Du damit?
Aus den Medienberichten konnte ich entnehmen: * Es ist keine Ende-zu-Ende Verschlüsselung, da Umschlüsselung auf einem Server. * Bei der Softwareentwicklung und anschließenden Prüfung wurden größere Fehler gemacht oder nur intern besprochen. (Fehler kommen bei IT-Projekten oft vor, die Frage ist, wie damit umgegangen wird.)
Heise Artikel https://www.heise.de/newsticker/meldung/Fataler-Konstruktionsfehler-im-beson... "Das grundlegende Problem liegt darin, dass der Client sowohl das Zertifikat als auch das Kennwort dazu kennt. [..]Das lässt sich nur heilen, indem man den Client anders konzipiert. "
Das ließe sich technisch durchaus mit überschaubaren Aufwand tun: Der "Client" könnte ein geheimes Zertifikate selbst pro Anwender erzeugen und dann in den Browser importieren. Oder gleich einen Browser selbst mitbringen.
Wo ist als der fundamentale Design-Fehler?
Viele Grüße Bernhard
Am 24.01.2018 um 08:27 schrieb Bernhard Reiter:
Am Donnerstag 11 Januar 2018 14:42:32 schrieb Dr. Michael Stehmann:
beA ist IMO "broken by design"
Der Punkt ist mir noch nicht ganz klar, was meinst Du damit?
Aus den Medienberichten konnte ich entnehmen:
- Es ist keine Ende-zu-Ende Verschlüsselung, da Umschlüsselung auf einem Server.
Das ist der erste grundlegende Fehler, denn es wurde "Ende-zu-Ende-Verschlüsselung" versprochen.
Heise Artikel https://www.heise.de/newsticker/meldung/Fataler-Konstruktionsfehler-im-beson... "Das grundlegende Problem liegt darin, dass der Client sowohl das Zertifikat als auch das Kennwort dazu kennt. [..]Das lässt sich nur heilen, indem man den Client anders konzipiert. "
Das ließe sich technisch durchaus mit überschaubaren Aufwand tun: Der "Client" könnte ein geheimes Zertifikate selbst pro Anwender erzeugen und dann in den Browser importieren. Oder gleich einen Browser selbst mitbringen.
Wo ist als der fundamentale Design-Fehler?
Es wurde auf den Rechnern der Anwälte ein Webserver (Ja: "Server") installiert, der zwingend https können muss. Dessen Zertifikat muss dann vom Browser des Anwenders akzeptiert werden.
Für diesen Server gibt es sogar einen DNS-Eintrag bei der DENIC (der auf 127.0.0.1 verweist).
Hintergrund ist, dass die Clientsoftware auf den Cardreader zugreifen soll.
Es gibt ferner bewusst keine Kanzleipostfächer, sondern jeder Rechtsanwalt hat eins, manche (Syndikusanwälte mit allgemeiner Zulassung) AFAIK sogar zwei.
Wie merkwürdig das Ganze konzipiert ist, mag man daraus ersehen, dass man einstellen kann (was durchaus im Rahmen dieses Systems sinnvoll sein kann), dass man eine E-Mail (unverschlüsselt) mit einer Benachrichtigung bekommt, wenn im beA etwas eingegangen ist.
Was sich noch herausstellen wird, weiß man noch nicht (auch das könnte man unter Berücksichtigung des Standes der kryptographischen Wissenschaft seit 1883 einen Designfehler nennen [0]).
Wie das Ganze dann, wenn die Gerichte mit Anwälten nur noch über beA kommunizieren wollen, mit Anwälten aus anderen EU-Staaten funktionieren soll, die ebenfalls mit deutschen Gerichten kommunizieren dürfen (Dienstleistungsfreiheit), ist mir nicht bekannt. Dabei gibt es Kampagnen der Anwaltschaft, den "Justizstandort Deutschland" zu stärken.
Gruß Michael
[0] hierzu https://freie-software.org/betrieb-und-verwaltung/bea.html
Am Mittwoch 24 Januar 2018 09:41:30 schrieb Dr. Michael Stehmann:
Am 24.01.2018 um 08:27 schrieb Bernhard Reiter:
Das ist der erste grundlegende Fehler, denn es wurde "Ende-zu-Ende-Verschlüsselung" versprochen.
Ja, das halte ich in der Tat für ein Design-Problem, das nicht so leicht zu beheben ist und vermeidbar gewesen wäre.
[Zert Problem]
Das ließe sich technisch durchaus mit überschaubaren Aufwand tun: Der "Client" könnte ein geheimes Zertifikate selbst pro Anwender erzeugen und dann in den Browser importieren. Oder gleich einen Browser selbst mitbringen.
In der Tat scheinen die das nun so zu machen: https://heise.de/-3951936
Allerdings gehen sie nicht auf die anderen Probleme ein (z.B. veraltete Bibliotheken).
Gruß, Bernhard
# Bernhard E. Reiter [2018-01-26 15:37 +0100]:
Am Mittwoch 24 Januar 2018 09:41:30 schrieb Dr. Michael Stehmann:
Am 24.01.2018 um 08:27 schrieb Bernhard Reiter:
Das ist der erste grundlegende Fehler, denn es wurde "Ende-zu-Ende-Verschlüsselung" versprochen.
Ja, das halte ich in der Tat für ein Design-Problem, das nicht so leicht zu beheben ist und vermeidbar gewesen wäre.
Heute gab es dazu einen Artikel von Hanno Böck auf golem.de [^1], in dem er eine mögliche Lösung skizziert, die auf GPG und einem zentralen Schlüsselservice basiert.
Einzige technische Probleme, die ich daran sehe: - Kein Perfect Forward Secrecy - Kein AEAD [^2] - Kein einfacher Zugang zu definierbaren Nachrichten vor dem eingestellten Vertretungszeitraum (aber ist das so wichtig?)
Dazu gibt es tatsächlich meines Wissens nach noch keine Freie-Software-Lösungen (zumindest nicht so erprobt wie GPG). Man hätte die 38 Millionen Euro ja dafür verwenden können, aber naja...
An dieser Stelle noch der Hinweis, dass gestern auch DAVIT, die Arbeitsgemeinschaft IT des Deutschen Anwaltvereins, den Offenen Brief der FSFE [^3] unterzeichnet hat. Damit wird deutlich, dass die Forderung, das beA jetzt und für alle zukünftigen Entwicklungen als Freie Software zu veröffentlichen, langsam auch in "konservativere" Zirkel vordringt.
Viele Grüße Max
[^1]: https://www.golem.de/news/anwaltspostfach-die-unnoetige-ende-zu-mitte-versch... [^2]: https://en.wikipedia.org/wiki/Authenticated_encryption [^3]: https://fsfe.org/campaigns/publiccode/bea
On Fri, 26 Jan 2018 16:08, max.mehl@fsfe.org said:
- Kein Perfect Forward Secrecy
Geht bei Email sowieso nicht. Durch 9Unter-)Schlüsselrotation kann man bei OpenPGP aber leicht Forward Secrecy erreichen. Ob das überhaupt notwendig ist, hangt aber vom Bedrohungszenario ab. Da Anwaltspost sowies immer viele Leser der Dokumente hat, ist das m.E. völlig irrelevant.
- Kein AEAD [^2]
OpenPGP benutzt AE(AD) seit 2000, also bevor es diesen Begriff überhaupt gab. Es nennt sich hier MDC und leistet genau das was AE auch leistet. Cryptographen mögen solche ad-hoc Verfahren allerdings nicht so gerne. Im übrigen kommt AEAD bald bei OpenPGP auch zu Einsatz - im aktuellen Master von GnuPG ist der aktuelle Proposal seit ein paar Tagen implementiert.
Shalom-Salam,
Werner
Hallo Werner,
# Werner Koch [2018-01-26 17:28 +0100]:
On Fri, 26 Jan 2018 16:08, max.mehl@fsfe.org said:
- Kein Perfect Forward Secrecy
Geht bei Email sowieso nicht. Durch 9Unter-)Schlüsselrotation kann man [...]
- Kein AEAD [^2]
OpenPGP benutzt AE(AD) seit 2000, also bevor es diesen Begriff überhaupt [...]
Danke für die Infos, sehr interessant. Ich leite das auch mal an Hanno weiter, mit dem ich darüber diskutiert habe [^1].
Viele Grüße Max
[^1]: https://twitter.com/hanno/status/956803850731769858
Nabend,
On Wed, Jan 24, 2018 at 08:27:05AM +0100, Bernhard Reiter wrote:
Aus den Medienberichten konnte ich entnehmen:
- Es ist keine Ende-zu-Ende Verschlüsselung, da Umschlüsselung auf einem Server.
- Bei der Softwareentwicklung und anschließenden Prüfung wurden größere Fehler gemacht oder nur intern besprochen. (Fehler kommen bei IT-Projekten oft vor, die Frage ist, wie damit umgegangen wird.)
Heise Artikel https://www.heise.de/newsticker/meldung/Fataler-Konstruktionsfehler-im-beson...
ich würde noch diese beiden Vorträge empfehlen:
yt: Talk von Markus Drenger auf dem 34C3 zum beA (28.12.2017) https://www.youtube.com/watch?v=Od5WAah-ktk
elektronisches Anwaltspostfach - einfach. digital. kaputt. (19.01.2018) https://media.ccc.de/v/CCCDA-elektronisches_Anwaltspostfach-einfach_digital_...
weitere Vorträge, welche auch gestreamt und ggf. aufgezeichnet werden, folgen.