Hi Brane, i didnt get you. How can the server admin modify the content if
contents are signed? Let me give a scenario, suppose we implement Public
Key Infrastructure in SVN, where each client generates its private key and
public key and registers this public key with the server so that anyone can
access the public key to verify the contents.
Suppose algorithm works in this way.
1. Client computes hash of (contents concatenated with some revision
properties), then sign this hash with its private key and sends this signed
hash with the contents and revision properties.
2. So, now if server modifies any content, server dont know the private key
of client, so server cant generate valid signed hashed.
3. Hence i agree with, server can put some garbage data. But server wont be
able to do false accusation on some other clients. (Like in current SVN,
server can change the name of client in log files, and it can accuse some
other client for that particular commit.
4. But after implement PKI, server cant accuse another client. It just can
currupt data, which can be determined too at the time of verification of
signed hash using public key.
Regards,
Ruchir Arya
>
> If your server administrator is not trustworthy, then no amount of
> signing is going to help. Anyone with direct access to the repository
> storage (which a server admin will have) can modify revision contents
> even if they're signed; no cryptographic signature is proof against
> attack.
>
> > then there is a problem. Is there any future possibility to implement
> > digital signing of changeset to achieve integrity and non repudiation?
> > My focus is to implement some of the security related features in svn.
>
> Subversion's repository backend already goes a good way towards ensuring
> integrity: the client provides cryptographic hashes of all committed
> data and the server checks them before committing, and the reverse
> happens during checkout/update. The server also stores hashes for
> certain metadata (although not all; there's room for improvement here).
>
> Non-repudiation is a lot harder to achieve because it's not enough to
> control the server, you also have to prove that every client making
> commits is free from malicious software that could be inserting
> backdoors at the source of the commit.
>
> -- Brane
>
>
Received on 2015-06-12 04:25:55 CEST