[jira] [Comment Edited] (FELIX-3610) Support runtime verification for signed bundles

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

    [ 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