STRONG security that fits everywhere. 1609.2 William Whyte, 1609.2 editor Troy, MI June 2009

STRONG security that fits everywhere.

1609.2

William Whyte, 1609.2 editorTroy, MIJune 2009


NTRU CRYPTOSYSTEMS, INC. COPYRIGHT © 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



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



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



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



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



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



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



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.



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).



2.1.1 Next steps

Take comments on this document until two weeks before August meeting

Resolve the comments at August meeting



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



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



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.



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



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.

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

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



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.



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?



2.1.4 Next Steps

Draft SAPs document for review at August meeting



Other

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



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



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

Documents

STRONG security that fits everywhere. 1609.2 William Whyte, 1609.2 editor Troy, MI June 2009