CWE/SANS TOP 25 Most Dangerous Programming Errors
-
#1: VB #2: Letting a VB programmer near a keyboard Marc
Available for consulting and full time employment. Contact me. Interacx
-
#1: VB #2: Letting a VB programmer near a keyboard Marc
Available for consulting and full time employment. Contact me. Interacx
VB jokes never get old, do they?
I didn't get any requirements for the signature
-
VB jokes never get old, do they?
I didn't get any requirements for the signature
ToddHileHoffer wrote:
VB jokes never get old, do they?
Nope. And count on me to take every opportunity to make them. :) Marc
Available for consulting and full time employment. Contact me. Interacx
-
VB jokes never get old, do they?
I didn't get any requirements for the signature
-
crudeCodeYogi wrote:
Actually it was in the 13th Jan newslater
Either way, my apologies. I would have deleted the thread, but it looks funny when someone responds to a deleted thread. I'll take it on the chin :)
I'll take it on the chin :) :thumbsup: (my attempt at a chin thump) :)
Steve _________________ I C(++) therefore I am
-
Hiyah Jeffrey - long time no hear - hope you're well and happy. Do you know of any good reference material on OTP/2FA ? (there's a small amount of material out there on the net, seems centered around rfc2289 etc) Im trying to figure out the best way to have a human client insert 'a code' (?otp/digital signature) into an email that gets sent to a server for auto processing. The server would ideally authenticate/verify the otp/signature using the email meta-data as well and allow/disallow the email request. The main crux I guess is that the email meta-data on its own is not enough/reliable - anyone can forge the sender for example (I'd also not like to tie the process down to particular machines and have digital certs stored on them, although certs etc could be on a token) Im quite happy to have a client on the user's desktop that creates the signature or calls an OTP server remotely, to create the data to be inserted into the email - and I would like it to be email based. any reference info you can point me at would be appreciated Thanks, Garth
-
Hiyah Jeffrey - long time no hear - hope you're well and happy. Do you know of any good reference material on OTP/2FA ? (there's a small amount of material out there on the net, seems centered around rfc2289 etc) Im trying to figure out the best way to have a human client insert 'a code' (?otp/digital signature) into an email that gets sent to a server for auto processing. The server would ideally authenticate/verify the otp/signature using the email meta-data as well and allow/disallow the email request. The main crux I guess is that the email meta-data on its own is not enough/reliable - anyone can forge the sender for example (I'd also not like to tie the process down to particular machines and have digital certs stored on them, although certs etc could be on a token) Im quite happy to have a client on the user's desktop that creates the signature or calls an OTP server remotely, to create the data to be inserted into the email - and I would like it to be email based. any reference info you can point me at would be appreciated Thanks, Garth
Hi Garth, From what I gather, confidentiality (encryption) is not a requirement; but authenticity is. There are no free lunches, and key exhange [even by another name] is thorny at best. From RFC 2289: The server must also facilitate the changing of the user's secret pass-phrase in a secure manner Let's side step the whole key exchange issue for now, and assume the client and server have a shared secret (i.e., a master key from which a session key can be generated). The session key will not be used for encryption - only authentication. > The server would ideally authenticate/verify > the otp/signature In the past, we would use an HMAC on a session key derived from the master key. However, HMACs have a defect under certain situations (it's somewhat obscure, but from the description of *this system* I believe it is easier to realize). NIST now recommends a CMAC. You can also use other NIST primitives such as CCM or GCM mode and only request authentication (CCM and GCM offers both encryption and authentication). Key exchange is a minefield because of active acttacks during exchange, key separation, and key management (archival and retrieval). The most common infrastructure is PKI and it uses X.509 certificiates. However, it is difficult to use at times. *If* your problem domain allows, plant the shared master key on the client during install. Have the setup program communicate it securely to the server on the fly (via a hard coded public key), or drop it on the server using sneaker-net. With a shared secret (master key/master secret) in place from setup, derive a per email session key using the email meta data. Given the session key, create a signature. Then transmit the email and signature. The tricky business is the session key. Generally, we have to be careful about how keys are derived so that keys are independent. Also, given the same message, we always have the same authenticator. So you will probably need some additional entropy below - based on a time variant. But, if you have the email message header available in adavance, you have your entropy since the message ID must be unique per RFC 821 [please verify]. Jeff Notationally, it would look similar to below. KDF can be an approved KDF, or a hash. But again, you need to look at your requirements and the properties of the primitives. key_m: master secret key_s: session key key_s = KDF( key_m || SHA( email.messageID ) ) auth = CMAC( key_s, email ) { email, auth } would be transmitted
-
Hi Garth, From what I gather, confidentiality (encryption) is not a requirement; but authenticity is. There are no free lunches, and key exhange [even by another name] is thorny at best. From RFC 2289: The server must also facilitate the changing of the user's secret pass-phrase in a secure manner Let's side step the whole key exchange issue for now, and assume the client and server have a shared secret (i.e., a master key from which a session key can be generated). The session key will not be used for encryption - only authentication. > The server would ideally authenticate/verify > the otp/signature In the past, we would use an HMAC on a session key derived from the master key. However, HMACs have a defect under certain situations (it's somewhat obscure, but from the description of *this system* I believe it is easier to realize). NIST now recommends a CMAC. You can also use other NIST primitives such as CCM or GCM mode and only request authentication (CCM and GCM offers both encryption and authentication). Key exchange is a minefield because of active acttacks during exchange, key separation, and key management (archival and retrieval). The most common infrastructure is PKI and it uses X.509 certificiates. However, it is difficult to use at times. *If* your problem domain allows, plant the shared master key on the client during install. Have the setup program communicate it securely to the server on the fly (via a hard coded public key), or drop it on the server using sneaker-net. With a shared secret (master key/master secret) in place from setup, derive a per email session key using the email meta data. Given the session key, create a signature. Then transmit the email and signature. The tricky business is the session key. Generally, we have to be careful about how keys are derived so that keys are independent. Also, given the same message, we always have the same authenticator. So you will probably need some additional entropy below - based on a time variant. But, if you have the email message header available in adavance, you have your entropy since the message ID must be unique per RFC 821 [please verify]. Jeff Notationally, it would look similar to below. KDF can be an approved KDF, or a hash. But again, you need to look at your requirements and the properties of the primitives. key_m: master secret key_s: session key key_s = KDF( key_m || SHA( email.messageID ) ) auth = CMAC( key_s, email ) { email, auth } would be transmitted
Jeffrey Walton wrote:
confidentiality (encryption) is not a requirement; but authenticity is
yep - thats the hammer right on the nail
Jeffrey Walton wrote:
But, if you have the email message header available in adavance, you have your entropy since the message ID must be unique per RFC 821 [please verify].
I was thinking of letting the user use the standard Groupwise email client to generate the email, and right at this second Im not sure it will allow me to access this in email 'build' mode/advance, although, a plug-in to groupwise would .... thanks for the response Jeff - love the thoughts - I'll chew on it over the weekend cheers, Garth
-
Hi Garth, From what I gather, confidentiality (encryption) is not a requirement; but authenticity is. There are no free lunches, and key exhange [even by another name] is thorny at best. From RFC 2289: The server must also facilitate the changing of the user's secret pass-phrase in a secure manner Let's side step the whole key exchange issue for now, and assume the client and server have a shared secret (i.e., a master key from which a session key can be generated). The session key will not be used for encryption - only authentication. > The server would ideally authenticate/verify > the otp/signature In the past, we would use an HMAC on a session key derived from the master key. However, HMACs have a defect under certain situations (it's somewhat obscure, but from the description of *this system* I believe it is easier to realize). NIST now recommends a CMAC. You can also use other NIST primitives such as CCM or GCM mode and only request authentication (CCM and GCM offers both encryption and authentication). Key exchange is a minefield because of active acttacks during exchange, key separation, and key management (archival and retrieval). The most common infrastructure is PKI and it uses X.509 certificiates. However, it is difficult to use at times. *If* your problem domain allows, plant the shared master key on the client during install. Have the setup program communicate it securely to the server on the fly (via a hard coded public key), or drop it on the server using sneaker-net. With a shared secret (master key/master secret) in place from setup, derive a per email session key using the email meta data. Given the session key, create a signature. Then transmit the email and signature. The tricky business is the session key. Generally, we have to be careful about how keys are derived so that keys are independent. Also, given the same message, we always have the same authenticator. So you will probably need some additional entropy below - based on a time variant. But, if you have the email message header available in adavance, you have your entropy since the message ID must be unique per RFC 821 [please verify]. Jeff Notationally, it would look similar to below. KDF can be an approved KDF, or a hash. But again, you need to look at your requirements and the properties of the primitives. key_m: master secret key_s: session key key_s = KDF( key_m || SHA( email.messageID ) ) auth = CMAC( key_s, email ) { email, auth } would be transmitted
Hi Garth, I forgot to mention that you might want to ask on sci.crypt. There's a lot more talent over there (than I can offer). I haven't looked in the litereature, but I would not be suprised if someone took offense to the following. It could be a simple as they prefer KDF( SHA( email.messageID ) || key_m ). Or they might want more entropy. key_s = KDF( key_m || SHA( email.messageID ) ) Jeff
-
Hi Garth, From what I gather, confidentiality (encryption) is not a requirement; but authenticity is. There are no free lunches, and key exhange [even by another name] is thorny at best. From RFC 2289: The server must also facilitate the changing of the user's secret pass-phrase in a secure manner Let's side step the whole key exchange issue for now, and assume the client and server have a shared secret (i.e., a master key from which a session key can be generated). The session key will not be used for encryption - only authentication. > The server would ideally authenticate/verify > the otp/signature In the past, we would use an HMAC on a session key derived from the master key. However, HMACs have a defect under certain situations (it's somewhat obscure, but from the description of *this system* I believe it is easier to realize). NIST now recommends a CMAC. You can also use other NIST primitives such as CCM or GCM mode and only request authentication (CCM and GCM offers both encryption and authentication). Key exchange is a minefield because of active acttacks during exchange, key separation, and key management (archival and retrieval). The most common infrastructure is PKI and it uses X.509 certificiates. However, it is difficult to use at times. *If* your problem domain allows, plant the shared master key on the client during install. Have the setup program communicate it securely to the server on the fly (via a hard coded public key), or drop it on the server using sneaker-net. With a shared secret (master key/master secret) in place from setup, derive a per email session key using the email meta data. Given the session key, create a signature. Then transmit the email and signature. The tricky business is the session key. Generally, we have to be careful about how keys are derived so that keys are independent. Also, given the same message, we always have the same authenticator. So you will probably need some additional entropy below - based on a time variant. But, if you have the email message header available in adavance, you have your entropy since the message ID must be unique per RFC 821 [please verify]. Jeff Notationally, it would look similar to below. KDF can be an approved KDF, or a hash. But again, you need to look at your requirements and the properties of the primitives. key_m: master secret key_s: session key key_s = KDF( key_m || SHA( email.messageID ) ) auth = CMAC( key_s, email ) { email, auth } would be transmitted
Hi Garth,
Jeffrey Walton wrote:
There are no free lunches, and key exhange [even by another name] is thorny at best
Take a look at Guttman's Home Page[^]:
Despite two decades of work, X.509 PKI isn't doing very well. Deployment is minimal, and even when it's used it's frequently just security theatre... It doesn't have to be that bad though. By sidestepping some of the most dysfunctional aspects of the original OSI design (X.500 directories, Distinguished Names, CRLs), it's possible to build a highly functional, easy-to-use PKI based on the original X.509 blueprint.
Follow the link to the paper titled, How To Build a PKI that Works[^]. Also of interest should be Guttman's Underappreciated Security Mechanisms[^]. In the paper, he discusses User Identification and Email Based Identification. Jeff