1 / 22

1609.2

1609.2. William Whyte, 1609.2 editor Troy, MI June 2009. Status. SoW agreed with USDoT, ARINC Security standards work = Task 2 2.1: Prepare “quick fix” / 1609.2 v2 for sponsor ballot Target completion date: January 2010 2.2: Manage standard through IEEE ballots January 2010 – June+ 2010

geri
Download Presentation

1609.2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1609.2 William Whyte, 1609.2 editor Troy, MI June 2009

  2. Status • SoW agreed with USDoT, ARINC • Security standards work = Task 2 • 2.1: Prepare “quick fix” / 1609.2 v2 for sponsor ballot • Target completion date: January 2010 • 2.2: Manage standard through IEEE ballots • January 2010 – June+ 2010 • 2.3: Identify and Evaluate Incorporation of Additional Security Schemes • Output: Project plan for v3 • Target completion date: January 2010 • 2.4: Development of Strategy for Incorporating Anonymity • Targeted start date: January 2010

  3. Website! • http://v2x-security.wikidot.org • Contains project plan (http://v2x-security.wikidot.com/local--files/1609dot2revision/1609.2-Schedule-2009.doc) and sections for each of the tasks • Lets us consolidate comments from comments sheet, email discussion, and WG minutes, and tag comments to make them easier to categorize • Intended to become a repository of notes etc as time goes on • Currently only editable by WW but this can be changed

  4. Task 2.1: “Quick Fix” / 1609.2 v2 • Produce standard suitable for approval by WG, consistent with other 1609s and with changes made in PoC. • 2.1.1: Incorporate changes made in PoC to existing message types • 2.1.2: Synchronise .2 with other standards in the series • 2.1.3: Review Comments • 2.1.4: Specify SAPs • Calendar: • June: start process • August: finish resolving comments and ensure editor has guidance on open issues • October : first “full” revised v2 • January (?): ready for sponsor ballot

  5. 2.1.1 Changes made in PoC • Del-2.1.1.1: Prepare modifications for presentation to Working Group • Full details on http://v2x-security.wikidot.com/1609dot2:pocmods • Extend types of secure message to more fully support cert management • Improve privacy in encrypted messages • Use of PSID consistent with other 1609s (1609.2-2006 has ACID) • Cert requests can request encrypted response and include a fresh response-encryption key in every request • This was optional in PoC: suggest mandatory in this case • CertificateRequestError and CRLRequest • Anonymous certificate management • Provisional on choice of anonymous cert mechanism

  6. 2.1.1 Secured Messages • SecuredMessage • Used to be of type unsecured, signed or encrypted • Now: unsecured, signed, encrypted, crl_request, crl • = encrypted + all message types that can safely be sent in clear • ContentType expanded to support unsecured, signed, encrypted, certificate_request, certificate_response, anonymous_certificate_response, certificate_request_error, crl_request, crl • ApplicationID and FullySpecifiedAppID now use PSID instead of ACID • Default is to just use PSID, where previously it was to use ACID and ACM

  7. 2.1.1 Encrypted Messages • EncryptedMessage • Used to have an EncryptedContentType field in cleartext • Replaced with a ContentType field inside the encrypted envelope • Privacy reasons: an eavesdropper should not know that you’re making an unusually large number of cert requests • Requires defining a ToBeEncrypted type, consisting of the ContentType field followed by the content. • AESCCMCiphertext maximum length increased to 232-1, to make it consistent with length of unsecured data • Penalty: two additional rarely-used bytes to encode the length • Alternative: assume that all messages will be a maximum of 216-1 bytes and reduce length fields apprporiately

  8. 2.1.1 Certificate request and response • CertificateRequest • 1609.2 didn’t allow a request to include two keys, but did allow a cert to include two keys – fix that. • Request can specify that the response should be encrypted • Ensure that each such request contains a fresh response-encryption key • Otherwise attackers could link requests from a single device • WAVECertificateResponse: Add request hash to response to let a receiver distinguish between responses obtained when there are multiple outstanding requests • CertificateRequestError – lets the CA tell a unit why a request failed • Added at Telcordia’s suggestion • Always encrypted • CRLRequest – lets a unit request a CRL if it thinks it might not be up to date

  9. 2.1.1 Anonymous certificates • The document includes Anonymous certificate formats, but they are dependent on the specific anonymous certificate mechanism chosen • Proposal: do not incorporate this part of the doc into the standards yet.

  10. 2.1.1 WSAs • In 1609.2-2006, WSAs are subject to the same security processing as other secured messages • Problem: this results in “replays” being rejected… but WSA signing is specifically designed to cause replays. • This section needs rewriting to ensure that replays are not rejected and cached WSAs are used correctly (i.e., to accept, not reject, a new incoming WSA).

  11. 2.1.1 Next steps • Take comments on this document until two weeks before August meeting • Resolve the comments at August meeting

  12. 2.1.2 Synch with other DSRC/WAVE standards • Del-2.1.2.1: List of areas to be addressed • http://v2x-security.wikidot.com/1609dot2:align • ACID and ACM become PSID; ACF (not used in 1609.2) becomes PSC (also not used in 1609.2). • Some comments on .3 that don't require changes to .2 • Security for timing advertisements requires further consideration. • Next deliverable: incorporate changes into 1609.2

  13. 2.1.3 Comments • Delivery Del-2.1.3.1: List of comments and proposed resolutions • http://v2x-security.wikidot.com/1609dot2comments • Total: 80 • Some submitted on form, some submitted in Word docs, some reverse-engineered from mailing list or email… • Proposed status: • Accepted: 41 • Deferred: 7 • Countered: 0 • Rejected: 4 • Superseded: 5 • Withdrawn: 0 • For further discussion: 23

  14. 2.1.3 Next Steps • Comments still being accepted until August meeting • For example, the following editorial ones • Be consistent with capitalization of type names – use uppercase only to separate “words” • “AESCCMCiphertext” -> “AesCcmCiphertext” • Some types have “WAVE”, some don’t – what’s up with that? • Additional consistency checks • “Certificate” or “Cert” • “ToBeEncrypted” used for only some types that are always encrypted • Are “OBU”, “RSU” still the preferred terms? • August meeting: review all unresolved comments; following this meeting WW should be able to produce first draft of complete revised 1609.2.

  15. 2.1.4 SAPs • http://v2x-security.wikidot.com/1609dot2-saps.html • Security libraries in VII PoC provided APIs for • Sign message • Encrypt message • Process incoming secured message • Sign WSA • Verify WSA • Certificate management • Proposal: provide SAPs for all except certificate management • Del-2.1.4.1: List of mechanisms that require SAPs

  16. 2.1.4: Inputs • Security operations are performed on messages, which are byte arrays • Security operations use a number of additional inputs • some must come from application, some from other sources • some hard to encode, some easier. • Process incoming: • A received secured message • The set of keys that might be used to decrypt an encrypted message • The set of certificates that might be used to construct and verify a cert chain back to the root cert • The list of revoked certificates • Current time • Current position • Replay cache • Do we expect to see generation time? • Do we expect to see transmission location? • Do we expect to see expiry time? • Acceptable PSID • Sign: • An application data payload to sign • The set of private keys and certificates belonging to the application that might be used to sign a message • The list of revoked certificates • Current time • Current position • Do we use generation time? • Do we use transmission location? • Do we use expiry time? • PSID associated with the message

  17. 2.1.4: Inputs: next steps • Be explicit about assumptions about what is available within security processing • Think about how to encode hard-to-encode data • Current document distinguishes between “inputs” and “parameters”; this is probably not sustainable.

  18. 2.1.4: Outputs / Errors • Protocol version mismatch • Nonsensical length • Problem with signed message • Processing error • Duplicate message, possible replay attack • Possible parse error, possible genuine error • Cryptographic verification failed • Message too old • Message from future • Message from too far away • PSID was not acceptable • Expected but did not find field: • Generation time • Transmission location • Expiry time • Cert / message mismatch error • Message outside geographic bounds in cert • Message PSIDs not matched by cert PSIDs • Problem with some certificate in chain for signed message (note: can distinguish between signer cert and CA cert if necessary) • Could not construct cert chain to known root • Maybe parse error • Cryptographic verification failed • Invalid subject type • Invalid key • Invalid key algorithm • Scope fields have unexpected form • AppID • Location • Genuine error • Expired • Revoked • Encrypted Message: Problem with decryption key • Couldn’t find decryption key • Key corresponds to expired local cert • Key corresponds to revoked local cert • Encrypted Message: Crypto processing error • Error decrypting symmetric key with private key • Error decrypting message with private key • Potentially lots of errors, esp. on incoming messages… • How much granularity do we need?

  19. 2.1.4 Next Steps • Draft SAPs document for review at August meeting

  20. Other • Work with .1, .3, .4 to ensure security support is adequate • “Security considerations” section in each document?

  21. Subtask 2.3: Prepare plan for v3 • 2.3.1 Application Security • 2.3.2 Security Management • 2.3.3 Platform assurance • 2.3.4 Interop with other standards • Full plan in http://v2x-security.wikidot.com/local--files/1609dot2revision/1609.2-Schedule-2009.doc • Del-2.3.1.1, list of applications, is the only deliverable for the current meeting

  22. Application security • Review output of VIIC PoC and other projects • VSCC, DIC-SEC, VSC (A) • SeVeCom, Car2Car Comms Consortium, ComESafety • Identify different classes of application based on • Security requirements • Performance requirements • Communication patterns • Determine high-level requirements for each app • Del-2.3.1.1: http://v2x-security.wikidot.com/1609dot2_del-2-3-1-1.html • List of 132 applications! • Sources: US State DoTs, SeVeCom, ETSI. • List needs a bit of editing… part of the work for Del-2.3.1.2

More Related