Help with signing messages

[Michael Stone]

On Thu, 3 Feb 2011 at 15:02:21 -0200, Esteban Bordon <ebordon at plan.ceibal.edu.uy> wrote:
> 2011/1/29 Michael Stone <michael at laptop.org>
>> On Fri, 28 Jan 2011 at 14:40:54 -0200 Esteban Bordon wrote:
>>
>>> I trying to make a notification system that reads messages from sqlite3
>>> database and show them via dbus notifications. I want to store a hash of
>>> the
>>> message inside the db to verify each message before show it, but I don't
>>> know how I do it.
>>>
>>> I think sign the message using sig01 of bios-crypto but I don't know how I
>>> can verify this hash. Can I use some mfg-data tag to verify it (msg signed
>>> with masterkey appropiate)?
>>>
>>> Which command I have to use?
>>>
>>
>> Can you please say a bit more about the system you're building? (The choice
>> of the right command almost certainly depends on some further details about
>> your goals.)

Hi Esteban,

Thanks for the detailed responses and apologies for my delay in replying to
you.

>> In particular:
>>
>>  * what does a typical message say?
>>
>
> Institutional or relevant messages about XO and children. For example, "New
> OS version is released" or "Your laptop will be blocked tomorrow, please
> update your blacklist"
>
>>
>>  * how are messages transmitted?
>>
>
> Laptop download a XML from their school server with the messages.
>
>>
>>  * are the messages addressed to one, many, or all possible recipients?
>> (unicast, multicast, broadcast)
>>
> All laptops should receive the same messages

I'm confused here because, above, you said that a typical message might be
"Your laptop will be blocked tomorrow, please update your blacklist."

Is this kind of message supposed to be:

   * received and displayed by all laptops?
   
   * received by all laptops and displayed by one or more "addressed" laptops?
   
   * received and displayed only by addressed laptops?
  
>>
>>  * are the notifications one-way or will there be replies?
>>
> one-way, for now.
>
>>
>>  * are the messages solely intended for humans to read or are they also
>>    machine readable?
>>
> This application is only for humans.
>
>>
>>  * do you care if other people read the messages in transit?     (secrecy)
>>
> No matter, messages  can be puclic.
>
>>
>>  * do you care if the messages are modified in transit?     (integrity)
>>
>
> Yes.  It's one reason for I want sign the messages.
>
>>
>>  * is the recipient supposed to know who sent a message?     (agreement on
>> sender identity)
>>
> Only school server should to send messages
>
>>
>>  * is the sender supposed to know who received a message?     (agreement on
>> receiver identity)
>>
> This feature isn't already implemented
>
>>
>>  * do you care if a message is never delivered?
>>    (availability / reliability)
>>
> If XO connect to server should get the XML. I don't think it as independent
> messages, all messages are into XML
>
>>
>>  * do you care if a message is delivered multiple times?
>>    (replay)
>>
> No, laptop application delete duplicate messages
>
>>
>>  * do you care if messages are reordered in transit?
>>    (ordering)
>>
> No. the application stores the messages into db file.
>
>>
>>  * do you have other security goals not mentioned above?
>>    (availability, resource usage limits, non-repudiation, privacy...)
>>
>> Regards,
>>
>> Michael
>>
>
>Regards,
>Esteban.

Okay. Based on what you've told me here, I see three approaches that seem like
they might do what you want at reasonable cost:

   a) Online signing w/ HTTPS: 
   
      If you trust your school servers and your school-server technicians to
      keep secrets, then you can meet your goals with something like:
      
        "curl --cacert <...> https://my.school.server/messages.xml" 

      The point is to
      
        1) open an HTTPS connection to your school-server,
        2) verify the cert-chain that you receive against a previously
           distributed CA cert that you issued, and,
        3) download your XML over this authenticated, integrity-preserving
           connection

   b) Offline signing w/ OpenSSL:
   
      If you really want to do offline signatures, for example, because you
      don't trust your school server to keep secrets, then the OpenSSL command
      line tools like "openssl rsautl" can probably help. 

   c) Offline signing w/ bios-crypto

      If you want to do offline signatures with the same crypto tools used for
      OFW and build signatures, then bios-crypto's cli_tool

        http://dev.laptop.org/git/bios-crypto/tree/cli.README

      may be what you want.

Do any of these approaches look like they might work for you?

Regards,

Michael