Sinnvolle Methode zur Signierung von Postings?

[Marcel Logen]

Ich überlege, ob die im folgenden beschriebene Methode zur
Signierung von Postings sinnvoll und ausreichend ist:

1. Beim Einspeisen des Postings die "recommended Message-ID" vom
Server (hier ein INN) so auswerten, daß daraus die Prozeß-ID
des nnrpd des Servers in dezimal ermittelt wird.

2. Diese Prozeß-ID erscheint später - vom Server gesetzt - im
Header des Artikels als "logging-data".

3. Diese Pozeß-ID in eine Datei "logging-data" schreiben (mit
Zeilenende "LF").

4. Die Datei mit "signify" (ursprünglich von OpenBSD, aber AFAIK
auch auf Linux-Systemen verfügbar) signieren.

Geprüft werden kann die signify-Signatur vom Leser dann per

signify -V -p signify-key.pub -m logging-data -x logging-data.sig

wobei "logging-data.sig" die signify-Signatur ist.

Die Daten für "logging-data.sig" und mein öffentlicher signify-
Schlüssel stehen im Posting in den vier Zeilen nach dem "-- ":

- Die ersten beiden Zeilen gehören in die Datei "logging-data.sig"
und stellen die Signatur der Prozeß-ID dar.

- Die letzten beiden Zeilen (bleiben konstant) gehören in die Datei
"signify-key.pub". (Diese Datei könnte ich auch auf meine Website
setzen, damit der Bezug zu meiner Person enger wird.)

Die Dezimalzahl "logging-data" erscheint im Posting in runden Klam-
mern am Ende der Zeile vor dem "-- ".

Meine Vorstellung bei der Sache ist, eine Zuordnung des Artikels zum
Poster herzustellen, ohne daß in einem aufwendigen Verfahren Teile
des Headers und der gesamte Body signiert werden müssen (wie bei der
herkömmlichen Headersignatur (siehe z. B. die Admin-Postings)).

Ich vermute aber, daß diese Methode nicht ausreichend gegen Ver-
fälschungen des Artikels schützt, sondern wirklich nur einen Be-
zug zum Poster herstellt (wenn überhaupt). Wie seht Ihr das?

Marcel kc4i (667794)
--
untrusted comment: verify with signify-key.pub
RWRtFSfgVKrGOLo8vC0kvM01rl8TVjzPcUzf8bZaRU9mHvT0tWaU2cilDQ0H6WhGcG5x3I3qxLf+FAYfHYbQ4EmRXoMUP9Z2Hg8=
untrusted comment: signify public key
RWRtFSfgVKrGOIyQbZdQrLAC/v0O5KEkhkfdcs/Op5KUrQHmly7WugHG

[Eike Rathke]

* Marcel Logen, 2022-06-25 00:15 UTC:

> Ich vermute aber, daß diese Methode nicht ausreichend gegen Ver-
> fälschungen des Artikels schützt,

Absolut 0.

> sondern wirklich nur einen Be-
> zug zum Poster herstellt (wenn überhaupt).

Du signierst nur einen umgewandelten Teil der Message-Id, mehr nicht.
Alles andere in deinem Artikel ist austauschbar. Du kannst genau so gut
"dieser Text ist signiert" schreiben und die Signatur anhaengen um zu
zeigen, dass dein .sec key zu dem .pub key was signieren kann. Mehr ist
es nicht.

Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/

[Arno Welzel]

Marcel Logen:

[...]

> Meine Vorstellung bei der Sache ist, eine Zuordnung des Artikels zum
> Poster herzustellen, ohne daß in einem aufwendigen Verfahren Teile
> des Headers und der gesamte Body signiert werden müssen (wie bei der
> herkömmlichen Headersignatur (siehe z. B. die Admin-Postings)).
>
> Ich vermute aber, daß diese Methode nicht ausreichend gegen Ver-
> fälschungen des Artikels schützt, sondern wirklich nur einen Be-
> zug zum Poster herstellt (wenn überhaupt). Wie seht Ihr das?

Bei administrativen Postings mag das noch halbwegs gerechtfertigt sein,
weil da Mitteilungen gemacht werden, die eine "rechtliche" Bedeutung
haben und sichergestellt sein muss, dass der Urheber dieser Mitteilung
auch berechtigt dazu ist.

Sonst sehe ich aber kaum einen realistischen Anwendungsfall, wo es nötig
sein sollte, den Urheber eines Postings zweifelsfrei identifizieren zu
können. Das einzige denkbare Szenario: jemand missbraucht die Identität
eines Anderen (Name, Absenderadresse etc.) um den durch entsprechende
Postings zu diskreditieren. Allerdings fallen solche Aktionen auch
schnell auf, weil die Art und Weise wie jemand schreibt und auch die
üblicherweise genutzten Newsserver, Software etc. auch ohne Signatur
wiedererkennbar ist.

--
Arno Welzel
https://arnowelzel.de

[Marcel Logen]

Eike Rathke in de.comm.software.newsreader:

>* Marcel Logen, 2022-06-25 00:15 UTC:

[...]

>> sondern wirklich nur einen Be-
>> zug zum Poster herstellt (wenn überhaupt).
>
>Du signierst nur einen umgewandelten Teil der Message-Id, mehr nicht.

Einen Teil der *recommended* Message-Id, der (nach dem Posten) im
Header des Artikels als "logging-data" (gesetzt vom Server) er-
scheint - *und* den ich im Posting selbst auch noch einmal angebe.

Die Message-Id selbst kann eine ganz andere sein.

Nun könnte ein maliziöser (anderer) Server natürlich die Zahl im
Header und im Artikel ändern, aber dann stimmte die Signatur nicht
mehr.

OK, der restliche Posting-Text kann ausgetauscht werden, ohne daß
die Signatur sich ändert, so daß das Verfahren in der Tat nicht
gegen Verfälschungen des Inhaltes hilft.

Aber kann es nicht doch irgendwie die Urheberschaft belegen?
Grübel.

Marcel mvqi (753490)

--
untrusted comment: verify with signify-key.pub

RWRtFSfgVKrGOPUvB6yhdKzTvfyA7kiKc+KQd93Be3JeGb+t2PEQ/ak81+LuooIR762hDQO9o4AAnABPCvFIkxD9RjqqsNRNtwA=

[Marcel Logen]

Arno Welzel in de.comm.software.newsreader:

[...]

>Bei administrativen Postings mag das noch halbwegs gerechtfertigt sein,
>weil da Mitteilungen gemacht werden, die eine "rechtliche" Bedeutung
>haben und sichergestellt sein muss, dass der Urheber dieser Mitteilung
>auch berechtigt dazu ist.
>
>Sonst sehe ich aber kaum einen realistischen Anwendungsfall, wo es nötig
>sein sollte, den Urheber eines Postings zweifelsfrei identifizieren zu
>können. Das einzige denkbare Szenario: jemand missbraucht die Identität
>eines Anderen (Name, Absenderadresse etc.) um den durch entsprechende
>Postings zu diskreditieren. Allerdings fallen solche Aktionen auch
>schnell auf, weil die Art und Weise wie jemand schreibt und auch die
>üblicherweise genutzten Newsserver, Software etc. auch ohne Signatur
>wiedererkennbar ist.

Ja, da kann ich Dir eigentlich nur zustimmen.

Außerdem wird wohl kaum jemand die Signaturen prüfen (wollen), es
sei denn, er hätte einen Automatismus dafür (immerhin könnte man
jedoch im Ernstfall mal nachschauen/nachrechnen).

Das Ganze war so eine Idee von mir, weil ich dachte, daß man ein
"Token", das vom Server vergeben wird, irgendwie für den Zweck
der Prüfung der Urheberschaft eines Artikels gebrauchen könnte,
denn nur der Poster bekommt dieses "Token" ja beim Posten 'zuge-
teilt'.

Marcel n0bk (754036)

--
untrusted comment: verify with signify-key.pub

RWRtFSfgVKrGONf5PEQfj1J+r8L45IAZVwP2dlbRcpEwls5IfS0wtyL59ajW4WldAGw+NAk3KZLps7B9V2kzJxfVEwHpvPZDiQY=

[Michael Bäuerle]

Marcel Logen wrote:
>
> [...]

> OK, der restliche Posting-Text kann ausgetauscht werden, ohne daß
> die Signatur sich ändert, so daß das Verfahren in der Tat nicht
> gegen Verfälschungen des Inhaltes hilft.
>
> Aber kann es nicht doch irgendwie die Urheberschaft belegen?
> Grübel.

Die Frage ist was es bringen soll, wenn man prüfen kann, dass du
*irgendwas* geschrieben hast. Sinn macht doch hauptsächlich eine
Prüfung, dass du *etwas bestimmtes* geschrieben hast -- und das
von niemand geändert wurde.

[Marcel Logen]

Michael Bäuerle in de.comm.software.newsreader:

>Die Frage ist was es bringen soll, wenn man prüfen kann, dass du
>*irgendwas* geschrieben hast. Sinn macht doch hauptsächlich eine
>Prüfung, dass du *etwas bestimmtes* geschrieben hast -- und das
>von niemand geändert wurde.

Ihr alle habt natürlich recht.

Jetzt bleiben mir zwei Möglichkeiten:

- Ich signiere den Body und ausgewählte Headerzeilen. Dann hätte
ich so etwas ähnliches wie die herkömmliche PGP-Headersignatur,
nur eben auf signify-Basis.

Das hatte ich ja vor einiger Zeit mal getestet (Du erinnerst Dich
vielleicht), allerdings realisiert mit dem flnews-postprocessor
(und nicht per inews), was dann leider (theoretisch) nicht 100-%ig
OK war, weil die Unicode-Normalisierung durch flnews erst anschlie-
ßend vorgenommen wurde.

Aber ich fürchte, *niemand* wird diese Signaturen jemals prüfen.

- Ich lasse es bleiben. Dann kann ich mir den Aufwand sparen und
mir etwas anderes überlegen. ;-)

Marcel p2cp (821657)
--
╭──╮ ╭─────╮ ╭───────────╮ ╭───────╮ ╭───╮
╭────╯ ╰──╮ ╰───╮ ╰──╮ ╰────────╮ ╰─────╯ ╰─╯ │
╰─────╮ ╭─╯ ╭──╯ ╰────╮ ╭───╯ ╭─────────╯ ╭──╮
───────╯ ╰─────╯ ╰──╯ 6047da ╰───────────╯ ╰──────╮

[Helmut Waitzmann]

Marcel Logen <33320000...@ybtra.de>:

>Das Ganze war so eine Idee von mir, weil ich dachte, daß man ein
>"Token", das vom Server vergeben wird, irgendwie für den Zweck
>der Prüfung der Urheberschaft eines Artikels gebrauchen könnte,
>denn nur der Poster bekommt dieses "Token" ja beim Posten 'zuge-
>teilt'.

Ein von dir signiertes Token taugt dazu, zu beweisen, dass du den
zum Signieren notwendigen Signierschlüssel besitzest.  Wenn du der
einzige bist, der den Signierschlüssel hat, taugt es auch noch dazu,
zu beweisen, dass du und nicht etwa sonst jemand signiert hat.  Mehr
beweist es nicht, insbesondere nicht, dass der Rest des Artikels von
dir stammt.

Wenn du das Token abhörsicher vom Server erhalten hast und es einen
zufälligen Wert hat (damit es niemand außer dir kennt), kannst du
damit dem Server gegenüber beweisen, dass derjenige, dem der Server
das Token gegeben hat – also dir –, deinen Signaturschlüssel
besitzt.  Kurz:  Sind diese Voraussetzungen gegeben, beweist du
damit dem Server, dass der Signierschlüssel deiner ist.

Der Serverbetreiber könnte dann das öffentliche Gegenstück deines
Signierschlüssels, also deinen öffentlichen
Signaturprüfungsschlüssel, zertifizieren und den Anfang eines Webs
of Trust aufbauen.

[Marcel Logen]

Helmut Waitzmann in de.comm.software.newsreader:

>Wenn du das Token abhörsicher vom Server erhalten hast und es einen
>zufälligen Wert hat (damit es niemand außer dir kennt), kannst du damit
>dem Server gegenüber beweisen, dass derjenige, dem der Server das Token
>gegeben hat – also dir –, deinen Signaturschlüssel besitzt.  Kurz: 
>Sind diese Voraussetzungen gegeben, beweist du damit dem Server, dass
>der Signierschlüssel deiner ist.

Danke. Das erinnert mich irgendwie an den TLS-Handshake, bei dem ja
AFAIK auch gewisse Daten, die nur Server und Client kennen, signiert
werden, um die Inhaberschaft des im Zertifikat genannten öffentlichen
Schlüssels zu beweisen.

>Der Serverbetreiber könnte dann das öffentliche Gegenstück deines
>Signierschlüssels, also deinen öffentlichen Signaturprüfungsschlüssel,
>zertifizieren und den Anfang eines Webs of Trust aufbauen.

Ja. (Aber hoffentlich nicht so wie beim herkömmlichen WoT, wo
man auf den Schlüsselservern beliebige (Müll-)Signaturen an einen
Schlüssel anhängen konnte.)

Marcel ot6n (816343)
--
╭─╮ ╭────────╮ ╭───────╮ ╭───╮
─╯ ╰────╯ ╭────╯ ╰────╮ ╰─╮ ╭──╯ ╰──╮
╭───╯ ╭──╮ ╭──╮ │ ╰─╯ ╭─────╯ ╭──╮ ╭────╮ ╭──╮
╰─────╯ ╰──╯ ╰─╯ da4853 ╰───────────────╯ ╰──╯ ╰──╯ ╰──

[Henning Hucke]

Marcel Logen <33320000...@ybtra.de> wrote:

Hallo Marcel,

> [...]

> Danke. Das erinnert mich irgendwie an den TLS-Handshake, bei dem ja
> AFAIK auch gewisse Daten, die nur Server und Client kennen, signiert
> werden, um die Inhaberschaft des im Zertifikat genannten öffentlichen
> Schlüssels zu beweisen.

Du verbusselst da augenscheinlich ein paar Sachen.

Im Rahmen des Deffie Hellman Key Exchange wird in der Tat etwas nicht
gekryptetes ausgetauscht.
(https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch)
Aber nicht für den Beweis der Inhaberschaft des im Zertifikat genannten
public key; diese wird mittels des im certificate store hoffentlich
vorhandenen root certificate und der hoffentlich übermittelten key chain
verifiziert!

> [...]

MfG Henning
--
In theory there is no difference between theory and practise.
In practise there is.
Yogi Beer

[Marcel Logen]

Henning Hucke in de.comm.software.newsreader:

>Marcel Logen <33320000...@ybtra.de> wrote:

>> Danke. Das erinnert mich irgendwie an den TLS-Handshake, bei dem ja
>> AFAIK auch gewisse Daten, die nur Server und Client kennen, signiert
>> werden, um die Inhaberschaft des im Zertifikat genannten öffentlichen
>> Schlüssels zu beweisen.
>
>Du verbusselst da augenscheinlich ein paar Sachen.
>
>Im Rahmen des Deffie Hellman Key Exchange wird in der Tat etwas nicht
>gekryptetes ausgetauscht.

Ich meinte nicht einen DH Key Exchange, sondern das
"CertificateVerify" aus RFC8446 (TLSv1.3):
<https://datatracker.ietf.org/doc/html/rfc8446#section-2>,
Seite 12:

| CertificateVerify: A signature over the entire handshake using the
| private key corresponding to the public key in the Certificate
| message. This message is omitted if the endpoint is not
| authenticating via a certificate. [Section 4.4.3]

Siehe auch:
<https://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol>

| 2. Der Server identifiziert sich gegenüber dem Client. Hierzu
| wird per Certificate ein X.509v3-Zertifikat an den Client ge-
| schickt, gefolgt von einem CertificateVerify (in einigen TLS
| Versionen). Die CertificateVerify Nachricht enthält eine Unter-
| schrift von zuvor ausgetauschten Nachrichten. Damit beweist der
| Server, dass er einen Secret-Key besitzt, der zu dem auf dem
| Server-Zertifikat enthaltenen Public-Key passt. Der Client
| prüft das Zertifikat und die Unterschrift. Bei Misserfolg
| bricht der Client die Verbindung ab.

Marcel p1ii (820818)
--
╭─╮ ╭─╮ ╭─╮ ╭─╮ ╭───╮ ╭───
╭───╯ │ ╭─╯ ╰─╮ ╭─────╮ ╭──╮ ╭──╮ ╭─╯ ╰──╯ ╰───╯ ╰──╮ │
╯ ╭──╯ ╰─╮ ╰──╮ ╭─╮ │ ╭──╯ │ ╰─╯ ╰──╯ ╭─╯ │
╰───────╯ ╰─╯ ╰─╯ ╰─────╯ 5e41ac ╰─────╯

[Marcel Logen]

Henning Hucke in de.comm.software.newsreader:

>Marcel Logen <33320000...@ybtra.de> wrote:

>> Danke. Das erinnert mich irgendwie an den TLS-Handshake, bei dem ja
>> AFAIK auch gewisse Daten, die nur Server und Client kennen, signiert
>> werden, um die Inhaberschaft des im Zertifikat genannten öffentlichen
>> Schlüssels zu beweisen.
>
>Du verbusselst da augenscheinlich ein paar Sachen.
>
>Im Rahmen des Deffie Hellman Key Exchange wird in der Tat etwas nicht
>gekryptetes ausgetauscht.

Ich meinte nicht einen DH Key Exchange, sondern das
"CertificateVerify" aus RFC8446 (TLSv1.3):
<https://datatracker.ietf.org/doc/html/rfc8446#section-2>,

Seite 13:

| CertificateVerify: A signature over the entire handshake using the
| private key corresponding to the public key in the Certificate
| message. This message is omitted if the endpoint is not
| authenticating via a certificate. [Section 4.4.3]

Siehe auch:
<https://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol>

| 2. Der Server identifiziert sich gegenüber dem Client. Hierzu
| wird per Certificate ein X.509v3-Zertifikat an den Client ge-
| schickt, gefolgt von einem CertificateVerify (in einigen TLS
| Versionen). Die CertificateVerify Nachricht enthält eine Unter-
| schrift von zuvor ausgetauschten Nachrichten. Damit beweist der
| Server, dass er einen Secret-Key besitzt, der zu dem auf dem
| Server-Zertifikat enthaltenen Public-Key passt. Der Client
| prüft das Zertifikat und die Unterschrift. Bei Misserfolg
| bricht der Client die Verbindung ab.

Marcel p1jn (820855)

[supersedes]
--
╭─────╮ ╭─╮ ╭───────────────╮ ╭─╮ ╭───╮
╰─╮ ╰──╮ ╭──╯ │ ╰─────────────╮ ╰─╯ ╰──╮ │ ╰────╮ ╭────╮
╮ │ ╭──╯ │ ╭─╯ ╭───╮ │ ╭─────╯ ╰─╮ ╭───╯ │ ╰─╮
╰──╯ ╰────╯ ╰────╯ ╰─────────╯ ╰──────────╯ ╰───────╯8aa5fb╰────╮