felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FELIX-3610) Support runtime verification for signed bundles
Date Wed, 25 Jul 2012 19:48:36 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422547#comment-13422547
] 

Guillaume Nodet edited comment on FELIX-3610 at 7/25/12 7:48 PM:
-----------------------------------------------------------------

That's exactly the reason, to make sure bundles are not modified.

I don't think all bets are off because you can verify the signatures.  Signatures of trusted
sources can't be changed unless you know the private key to sign those.  So either  you unsign
the bundle (and it will be known because the bundle won't return signatures) or you sign it
with a different source which you'll know too.

The cpu consumption would only be there for signed bundles, and that's only about computing
the checksum of the zip entry, which is quite fast, there's no real cryptography involved
here, so I don't think that's a problem.  Besides, that's a decision for the user to take.

The use case, to give a bit more background, is to give a trusted framework to a third party
so that it will use it, but we need to ensure some stuff can't be modified by this third party.
 We don't trust the third party to not hack with our framework, so we need to secure it. 

Imagine a payment application where you provide a service that will do some billing.  You
don't want the third party to start hacking the bundle in order to bypass the billing for
example ;-)
                
      was (Author: gnt):
    That's exactly the reason, to make sure bundles are not modified.

I don't think all bets are off because you can verify the signatures.  Signatures of trusted
sources can't be changed unless you know the private key to sign those.  So either  you unsign
the bundle (and it will be known because the bundle won't return signatures) or you sign it
with a different source which you'll know too.

The cpu consumption would only be there for signed bundles, and that's only about computing
the checksum of the zip entry, which is quite fast, there's no real cryptography involved
here, so I don't think that's a problem.  Besides, that's a decision for the user to take.

The use case, to give a bit more background, is to give a trusted framework to a third party
so that it will use it, but we need to ensure some stuff can't be modified by this third party.
 We don't trust the third party to not hack with our framework, so we need to secure it. 
                  
> Support runtime verification for signed bundles
> -----------------------------------------------
>
>                 Key: FELIX-3610
>                 URL: https://issues.apache.org/jira/browse/FELIX-3610
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework, Framework Security
>            Reporter: Guillaume Nodet
>            Assignee: Karl Pauls
>
> Signed bundles are only checked when installed, but the goal of signed bundles is to
make sure no one has changed the jar.    This is not ensured unless bundle entries are verified
when loaded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message