Built for Business - Learn more about BlackBerry KEY2
  1. moxob's Avatar

    Got myself a Priv and while happy in general, I'm struggling with the s/mime setup of its Hub. I can sign e-mails but can neither read encrypted e-mails sent to me nor encrypt to recipients even though I have their signed mails (p7s) in my inbox. Priv tells me I need to first import their [public] certificate which would be a p7c and which is embedded in a signature (p7s). The Hub does apparently not automatically extract the public certificates from signatures - which is a bit odd because all other mail clients I have been using do that.

    Also, I have not found out how to manually import a sender's public certificate into my device. Specifically, Settings/Security/Install From SD Card only supports other formats and rather seems to be for my private p12 which I got onto the device all right and which is now used to e.g. sign e-mails I send through the Hub (that works ok).

    How do you handle s/mime messages you receive? How do you send s/mime encrypted mails to your contacts? Where do you store contacts' public certificates?

    If this doesn't work in Hub I would have to revert to another mail client sadly. On my old device I used Maildroid and that can do all of it (plus PGP which I have but apparently nobody else so could spare that). Might also consider SecurePIM which seems to be newer and I would then obviously have to buy yet another mail client.

    Thx much!
    01-04-17 04:17 AM
  2. moxob's Avatar
    Have tried to install recipients' public keys in *.pem format as described in https://help.blackberry.com/en/priv/...806770410.html but they get rejected. Would be too much hassle anyway, these certs should be extracted by the mail client not by me.
    Given that Maildroid fails at https://www.emailprivacytester.com, I may indeed go for SecurePIM and loose the Hub if I cannot get this sorted. Would also have the benefit of not longer being tied to ActiveSync. BB can only do s/mime on ActiveSync accounts not IMAP - cannot see any proper reason for that either.
    01-04-17 07:57 AM
  3. moxob's Avatar
    Ok not many seem to be using s/mime here. Anyway this is solved for me for the time being and these are my findings:

    Through its native e-mail app:
    • Priv can do s/mime on activesync accounts only, not imap. This is documented and not my problem - even though there is no technical necessity for this restriction.
    • On activesync accounts, Priv apparently cannot extract public certificates from signed e-mails you receive. It just shows a .p7s attachment but does not seem to be able to do anything sensible with them (or at least I could not make it to extract them).
    • Result: I can sign my e-mails but can neither check signed e-mails I receive nor encrypt e-mails to my contacts.

    Maybe the Priv native mailer can do it when working under a BES, have not tested that.
    I solved this for me using SecurePIM, it handles s/mime properly both on activesync and on IMAP accounts.
    Last edited by moxob; 01-09-17 at 04:05 AM.
    01-09-17 03:43 AM
  4. tickerguy's Avatar
    You should not ever have to actually extract the signature to get the public key.

    S/MIME as a paradigm says that if you have a signed message that verifies (trust is good and the signature is good) then you can always reply encrypted to that correspondent because his or her public key and the list of ciphers and MACs his end supports is in the signature. You therefore need nothing further (provided you can use at least one of the ciphers he claims to support) -- not only should you not need to extract and store their public key (certificate) you should never, ever do so because their certificate may change over time and when you reply you should thus always use the certificate in the message you are replying to.

    This is a (very severe) bug and I've reported it.

    BTW the reason the Priv (and other BlackBerry phones, including BB10 phones) require Exchange to work for S/MIME has to do with how Exchange treats multi-part messages and attachments .vs. how IMAP considers "a message (in its entirety)" to be its basic unit of consideration. It was a decision that BlackBerry apparently made at least as far back as BB10.
    Last edited by tickerguy; 01-09-17 at 08:31 AM.
    moxob likes this.
    01-09-17 08:19 AM
  5. moxob's Avatar
    Cool and yes I was just experimenting there re extracting certificates, am used to automatic extraction anyway, as mentioned my first post.
    Thanks much for your attention and for filing the bug! Will be happy to return to the Hub for s/mime once that is fixed. ActiveSync will not be an issue, can use that as well.
    01-09-17 08:45 AM
  6. tickerguy's Avatar
    You should NEVER, EVER actually extract the public key from a signature and then attempt to use it (except transiently for the individual message you're sending.)

    The reason for this is that the sender may, at a time of his own choosing, change his certificate and/or key. He may do it because his old key was compromised, it may expire, or he may simply want to change it for some other reason. If you send using a local certificate (public key) you kept around you may be sending using a public key that is either no longer valid (in the worst case it was revoked!) or has been voluntarily abandoned.

    Of course the correspondent should keep his old private key(s) around so he can read older emails that are encrypted, but that's on him. In the event of a compromise he may choose to destroy both the key and all stored messages encrypted on it, plus all backups of same (since it's the best he can do to try to prevent someone from being able to read same - - not perfect of course since other copies may exist, but it's all he's got.) What's never appropriate is for you to "back-date" a transmission by using an old public key when you have a (possibly) newer one available to you because you may well be sending a message for which the private key has been compromised and thus your transmission would not be secure -- and you have no way to know if that happens!

    Indeed if a material amount of time has passed between your last transmission from a given correspondent you should solicit a (newly) signed message from him or her before sending encrypted content, since in that case you have no way to know if his private key is current -- or was revoked -- since a privately-stored key is not normally validated against either a CRL or OCSP server before being used. After all, you vouched for it when you put it in the local certificate store as a trusted certificate! That is simply never appropriate in this use case since you are not the entity that holds knowledge as to whether it's valid or not. (This is why CA security is so important; if a CA is compromised there will be a huge number of people who will trust signatures from it anyway since they have no reasonably way to know something bad has happened to it.)

    I would argue that an S/MIME email application that is willing to extract certificates and save them is broken because it enables user behavior that has the potential to be ruinously bad. It is not only unnecessary to do so since any signed message has the public key of the sender embedded in it, along with the available MAC and cipher set the sender can accept, it is dangerous to do so because it transfers control of the validity of that certificate from the holder of it, who has the knowledge of same, to you who do not have any way to know if it has been revoked or obsolesced other than through the expiration date. Even if the app attempts to mitigate this risk by checking revocation status "when used" it doesn't cover the case where a certificate was abandoned after a compromise without publication of a revocation notice (such as, for example, when the person who would otherwise publish such a notice can't do to physical inability!)
    01-09-17 11:07 AM
  7. moxob's Avatar
    Well let's rephrase - I'm used to e-mail clients that handle X.509 certificates automatically and that does of course include checking them against CAs and nullify withdrawn / expired certificates. On my desktop I can monitor that for all certificates (PGP, s/mime - each private and public and chains, validities etc.) through a program called kleopatra (part of KDE). It interacts with my desktop mailer (kmail) but is no direct part of it. Works and watches out for invalid stuff of course. If I import a certificate into kleopatra (and I can do that of course), it still checks it against CAs and monitors revocations / validities for it. With s/mime kmail + kleopatra handle everything themselves and I might only go there and delete a public certificate that I no longer need for instance (happened only once to date).
    I thought there is a comparable functionality on the Priv which is why I tried importing. Now I know there isn't - wouldn't have tried if Hub just worked as advertised
    Last edited by moxob; 01-09-17 at 01:23 PM.
    01-09-17 12:27 PM
  8. tickerguy's Avatar
    Nope. Nor, in reality for S/MIME use, should there be for nearly all use cases.

    S/MIME was designed the way it was for a reason. Every time you open a S/MIME email the signature is checked for validity, including chasing the chain of trust. The MUA thus knows at the time you read the email whether the certificate in the signature is valid and trusted, and thus whether it can (and should) use it for an encrypted reply.

    Anything that potentially short-circuits those checks risks you sending a message I can't read or (possibly worse) one that can be read by others. The only "use case" that requires storing certificates "mined" out of .p7s attachments is the instance where you wish to send an encrypted initial message to someone who you have corresponded with in the past, not as a reply, but who in their previous email(s) to you included a digital signature. Rather than chase any previous conversation chain you may have (and validate the .p7s file in the most-recent message) what your software does is acceptable, provided it performs the same set of checks (and it sounds like it does.) However, that only enables the one individual use case of initiating a new email chain with someone you previously corresponded with (without having to find one of their previous emails to reply to, or ask them to send you a signed message) and in a "world" where most people "sign" their emails will quickly lead you to have an utterly enormous certificate store.

    There's potential value in such an implementation but some sort of background "cleanup" would probably be necessary to keep the overhead reasonable, such as (for example) a daemon to flush expired personal certificates.

    Just for scope I get a couple hundred non-spam emails a day, most from various development mailing lists. If each of those was signed by the sender and my phone tried to strip and store all the certificates it saw...... yeah, that could get kinda ugly in a fairly big hurry.

    Hopefully BlackBerry considers this particular fault a serious enough one to require immediate remediation because as it stands right now you have to get the public key for your correspondents and import it, which is both ridiculous and intended to be unnecessary in the S/MIME specs.
    01-09-17 01:38 PM
  9. moxob's Avatar
    I never talked about a mere offline storage that is unsynced. Kleopatra does not shortcut any checks. Other solutions store certificates along with contacts and somehow have to because you archive an inbound e-mail at some point and may wish to send encrypted to that contact later - I try to have a small inbox and automatically save e-mails into the DMS. Or you may be offline when preparing the email. All key management solutions I know talk to X.509 servers whenever they can. Storage isn't bad in my view as long as it is synced but I don't want to be dogmatic here I just need to be able to work. I'm a user not a developer. I've been using both PGP (since 1997) and s/mime (since 2004) for quite a bit and ran into an apparently severe bug on the Priv that I have owned for about 2 weeks now. Interesting that no one else spotted that earlier, with Priv being in the market for quite a bit. I thought "user error" and just did some experiments then to make it work using unimportant certificates - because I thought there may be a function somewhere similar to Maildroid's Crypto Plugin. Didn't work as there isn't and it simply is a bug rather than user error. Lesson learned. Hope BB get their act done.

    Anyway I can't wait for them and have found a solution to be able to work - as stated SecurePIM works as advertised and automatic so I don't have to fiddle around. FYI it does of course still allow me to go to (/settings/keys and certificates/recipient certificates) and view/manage certificates I have received - it has hence extracted them from e-mails into a local keystore. Keeps them synced with servers of course but still has them available if I delete the inbound message that provided it. When I click on a certificate, it shows details such as CA, fingerprint, expiry, status and offers me to delete it. I can also import recipient certificates from internal memory (and it would check them against servers). This is a proper implementation. It has been certified by BSI btw - you will not know them but they are relevant in terms of what the DE government may or may not use.
    Last edited by moxob; 01-10-17 at 03:01 AM.
    01-10-17 02:09 AM
  10. tickerguy's Avatar
    I understand where you're coming from in that regard but my point is that client extraction and caching of S/MIME certificates covers one use case (initiating a new, encrypted email conversation to someone who you have corresponded with before during the valid period of their certificate, which is typically one year for the "bulk issuers.") In addition using cached certificates instead of .p7s files when the latter is available (e.g. as a reply) is a generally-bad practice.

    None of the other use cases require or benefit from it at all:

    1. If sending to someone after said time period has run (again, it's typically one year from date of issue) then the certificate is invalid. This means that on average if you haven't talked to someone for 6 months their certificate will be invalid and unusable and thus the cached data is worthless.

    2. If you are replying to someone who has a valid certificate in a signed message then local certificate caching is of no value because you have their certificate in the message you're replying to.

    That BlackBerry missed this has more to do with the dearth of people actually using S/MIME than anything else. Their "general use case" tends to be regulated industries which are BES-enabled, and BES can push certificates. This caused problems in the BB10 days and I reported a number of issues when we lived in a BB10 world -- but there have been material incremental improvements since Android showed up on their handsets.

    I've been sending all my emails with attached S/MIME signatures now for the last few years and yet I can count on the fingers of one hand the number of people who I correspond with (and I easily handle a hundred emails a day during most workdays) who also sign their emails. It's unfortunate, but reality.

    PGP's biggest issue is key management. The public keyservers are not really a solution since anyone can publish a key allegedly from a person and the validation of that key being "good" is left to other means, for which there is no infrastructure in the PGP environment. S/MIME promised a solution to this in the general case by using the existing chain of trust mechanism that the CA infrastructure provides but it just hasn't caught on to any material degree.

    If, for example, I had correspondents who used S/MIME I would have caught this problem with the Hub over a year ago and reported it because it would have been instantly obvious.

    In any event it's been reported now (I caught another problem that BB's implementation has and I understand a fix has been committed to the codebase for it -- it should show up in the next turn of the code.) Hopefully this issue gets reasonably-rapid attention as I agree entirely with you that it's serious. However, where we disagree is as to what is required to actually resolve the issue from BlackBerry's point of view.

    Specifically, I argue that certificate extraction from .p7s attachments and storing them to the local certificate store is unnecessary in an Exchange environment (the only environment BlackBerry currently works with S/MIME in) because Exchange supports the rapid grabbing of attachments from the server on-demand without transmitting the entire message and threads conversations (if you maintain the conversation entirely within exchange.) Since user (and machine) certificates in general are relatively fragile (they have a reasonably short lifetime) unlike CA certificates, and the use case in which they're of value both is reasonably infrequent and has a moderately low-hassle workaround I would argue that building that code infrastructure is probably unnecessary.

    More to the point on-demand use of a .p7s signature as a means of acquisition of the recipient's public key is not only appropriate it's fundamentally necessary. Indeed there's a basic problem with using cached certificates standing alone for such a purpose because the certificate does not carry the supported message exchange ciphers or MACs the other end supports - but the .p7s file does. While in practice this should not hose you, it can. Specifically AES-128 for content encryption is now considered a "must" by basically everyone but there may be clients still out there in the wild that cannot handle it, whether due to age or government restriction (in certain parts of the world) and require DES-3EDE. In addition there are both signature and digest algorithms to consider. None of this (other than the digest on the certificate) is in the certificate, but all of it is in the .p7s signature. As such sending an encrypted message "blind" to someone using only their certificate runs the risk of them being unable to read what you send.

    RFC5751 delineates some of the differences in what clients may be expected to support in terms of both what they must and what they should. There are material differences if you wish to be able to freely communicate between different implementations of S/MIME of varying implementations from the myriad publishers of same. The only way for a client to know what the other end can handle is to have a .p7s signature on a plain text transmission (or embedded signature in an encrypted message) because that's the only place the full set of that data is contained.

    It's perfectly legitimate to cache the the .p7s in its entirety and in fact RFC5751 expresses this as a "SHOULD." However, merely caching the certificate does not meet that requirement and in fact explicitly violates that RFC because the attributes thus available are incomplete and the assumptions this forces are potentially "wrong enough" to prevent the recipient from reading what you send.
    Last edited by tickerguy; 01-10-17 at 10:48 AM.
    01-10-17 09:56 AM
  11. moxob's Avatar
    Well I don't think we actually disagree on how Blackberry should solve this either because as mentioned I'm just a user and want them to fix it along best practices so that I can use it.
    Btw all my documents are encrypted at rest as well - there are enough corporate customers these days who actually request that. Truly most of the time they are the ones who also communicate using s/mime and accept no certificate that runs for more than a year.
    01-10-17 10:48 AM
  12. tickerguy's Avatar
    BTW it DOES work.

    Read message.
    Touch large ribbon at top with the "Checked" seal.
    Touch the SEAL at the bottom in the S/MIME details
    Then touch the DOWNLOAD ARROW (top right) and it will be put into the certificate store.

    It then works.

    But... it shouldn't be necessary.

    However... it does work although it's VERY not-obvious how to do it!

    (Got a reply back on my bug report.)
    Attached Thumbnails SMIME works only half way... does not seem to import sender certs from p7s-2017-01-10-17.50.18.jpg   SMIME works only half way... does not seem to import sender certs from p7s-2017-01-10-17.50.21.jpg   SMIME works only half way... does not seem to import sender certs from p7s-2017-01-10-17.50.25.jpg  
    Last edited by tickerguy; 01-10-17 at 12:13 PM.
    01-10-17 11:52 AM
  13. moxob's Avatar
    Thanks for figuring out but yes this is unusable. When I said the key managers I use on other devices allow me to import I didn't mean I want to import every single certificate - this should be an automatic process. I touch the key manager only in pretty exceptional cases.
    01-10-17 12:35 PM
  14. tickerguy's Avatar
    Thanks for figuring out but yes this is unusable. When I said the key managers I use on other devices allow me to import I didn't mean I want to import every single certificate - this should be an automatic process. I touch the key manager only in pretty exceptional cases.
    Well I disagree with THAT, as I've pointed out -- there should be no import by default to the device's certificate store. The option to do so, yes. The default action to do so, no, because you have then created a maintenance requirement that may get wildly out of hand (and would ​in my case, in that I am on mailing lists where a large percentage of users, including myself, sign all our emails!)

    But... you shouldn't need to import the key to reply encrypted since you already have it in the message itself -- automatically or otherwise.

    I've communicated this back....
    01-10-17 12:43 PM

Similar Threads

  1. 2017 January 5th Sec-Fixes on the way to BB devices
    By gizmo21 in forum BlackBerry Android OS
    Replies: 40
    Last Post: 01-20-17, 12:56 PM
  2. Replies: 4
    Last Post: 01-04-17, 03:47 PM
  3. my blackberry 9300 curve 3g. i,d,t,y buttons are not working
    By Jawad Naseer in forum Ask a Question
    Replies: 2
    Last Post: 01-04-17, 03:44 PM
  4. Time to buy BlackBerry stocks before Mercury comes out
    By Zed Xxx in forum BlackBerry KEYone
    Replies: 4
    Last Post: 01-04-17, 10:06 AM
  5. Modified Q5 alt key not working - help
    By evodevo69 in forum BlackBerry Q5
    Replies: 2
    Last Post: 01-04-17, 08:31 AM