Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Tweeted twitter.com/StackSecurity/status/843333526388981760
    Bumped by Community user
2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

Im currently writing a authentication app based on RSA, for Android that should be impossible to copy, even if you have physical access to a phone without lockscreen/PIN.

However, the HSM inside the phone, that ensures the private key can never leave the storage, only be "used", does only support PKCS 1.5 padding due to a bug in the bouncycastle implementation.

The encrypted messages, will be different every time (nonce) so theres no possibility to observe that two encrypted messages are identical over the wire.

A attacker or adversiary, while not having access to the phone, does not have access to a padding oracle. The app works by having the user scan a encrypted QR and this encrypted QR decrypts into a OTP code. Yes, the attacker can display, on a phishing page or hijacked connection, a QR code containing padding errors, and observe if the user proceeds with authentication (enters a valid OTP) or not, but what I read on some pages, a padding oracle attack requires millions of "tests" against the padding.

When the attacker or adversiary do have access to the phone, the attacker can use the phone itself as padding oracle, but also, when having access to the phone, the attacker is able to decrypt arbitary messages using the app anyways.

The security goals that must be met, is that:

  • While the attacker does not have access to the phone, the attacker should not be able to authenticate.

  • If the attacker does have access to the phone, even for a long time, he should be able to authenticate, but not extract the private key.

  • When attacker does no longer have access to the phone, for example if the attacker is a previous employee that have been fired and then have turned in the phone, the attacker should no longer be able to authenticate, even if he previously did have access to the phone, and even if the keypair inside the secure hardware, has not been changed.

On this page, the answer mentions its possible to extract the private key, by mounting a padding oracle attack: What specific padding weakness does OAEP address in RSA?What specific padding weakness does OAEP address in RSA?

However, the wikipedia page, mentions no reveal of private keys: https://en.wikipedia.org/wiki/Padding_oracle_attack

But the wikipedia page mentions, using the padding oracle, a attacker is able to decrypt arbitary messages, by just checking the padding oracle replies, without having access to the either the key nor the plaintext output of the decryption engine. However, in this case, when a attacker does have access to the padding oracle, the attacker also have access to the plaintext output and vice versa, which means that decryption of arbitary messages is already possible when the attacker does have access to the decryption engine, without having to resort to a padding oracle attack.

The 2 things are completely different, because with the private key, the attacker is able to do decryption while he no longer have access to the padding oracle, but if the padding oracle can only be used to decrypt messages, the padding oracle effectively becomes useless to the attacker in this case, because when the attacker no longer have padding oracle access, he can no longer do decryption, and the security goal is met.

The questions I have is:

1: Is it safe to use PKCS 1.5 in this case?

2: Is it really possible to extract the private key using a padding oracle, or does the padding oracle just allow arbitary message decryption? The 2 linked articles are ambigious in that regard.

Im currently writing a authentication app based on RSA, for Android that should be impossible to copy, even if you have physical access to a phone without lockscreen/PIN.

However, the HSM inside the phone, that ensures the private key can never leave the storage, only be "used", does only support PKCS 1.5 padding due to a bug in the bouncycastle implementation.

The encrypted messages, will be different every time (nonce) so theres no possibility to observe that two encrypted messages are identical over the wire.

A attacker or adversiary, while not having access to the phone, does not have access to a padding oracle. The app works by having the user scan a encrypted QR and this encrypted QR decrypts into a OTP code. Yes, the attacker can display, on a phishing page or hijacked connection, a QR code containing padding errors, and observe if the user proceeds with authentication (enters a valid OTP) or not, but what I read on some pages, a padding oracle attack requires millions of "tests" against the padding.

When the attacker or adversiary do have access to the phone, the attacker can use the phone itself as padding oracle, but also, when having access to the phone, the attacker is able to decrypt arbitary messages using the app anyways.

The security goals that must be met, is that:

  • While the attacker does not have access to the phone, the attacker should not be able to authenticate.

  • If the attacker does have access to the phone, even for a long time, he should be able to authenticate, but not extract the private key.

  • When attacker does no longer have access to the phone, for example if the attacker is a previous employee that have been fired and then have turned in the phone, the attacker should no longer be able to authenticate, even if he previously did have access to the phone, and even if the keypair inside the secure hardware, has not been changed.

On this page, the answer mentions its possible to extract the private key, by mounting a padding oracle attack: What specific padding weakness does OAEP address in RSA?

However, the wikipedia page, mentions no reveal of private keys: https://en.wikipedia.org/wiki/Padding_oracle_attack

But the wikipedia page mentions, using the padding oracle, a attacker is able to decrypt arbitary messages, by just checking the padding oracle replies, without having access to the either the key nor the plaintext output of the decryption engine. However, in this case, when a attacker does have access to the padding oracle, the attacker also have access to the plaintext output and vice versa, which means that decryption of arbitary messages is already possible when the attacker does have access to the decryption engine, without having to resort to a padding oracle attack.

The 2 things are completely different, because with the private key, the attacker is able to do decryption while he no longer have access to the padding oracle, but if the padding oracle can only be used to decrypt messages, the padding oracle effectively becomes useless to the attacker in this case, because when the attacker no longer have padding oracle access, he can no longer do decryption, and the security goal is met.

The questions I have is:

1: Is it safe to use PKCS 1.5 in this case?

2: Is it really possible to extract the private key using a padding oracle, or does the padding oracle just allow arbitary message decryption? The 2 linked articles are ambigious in that regard.

Im currently writing a authentication app based on RSA, for Android that should be impossible to copy, even if you have physical access to a phone without lockscreen/PIN.

However, the HSM inside the phone, that ensures the private key can never leave the storage, only be "used", does only support PKCS 1.5 padding due to a bug in the bouncycastle implementation.

The encrypted messages, will be different every time (nonce) so theres no possibility to observe that two encrypted messages are identical over the wire.

A attacker or adversiary, while not having access to the phone, does not have access to a padding oracle. The app works by having the user scan a encrypted QR and this encrypted QR decrypts into a OTP code. Yes, the attacker can display, on a phishing page or hijacked connection, a QR code containing padding errors, and observe if the user proceeds with authentication (enters a valid OTP) or not, but what I read on some pages, a padding oracle attack requires millions of "tests" against the padding.

When the attacker or adversiary do have access to the phone, the attacker can use the phone itself as padding oracle, but also, when having access to the phone, the attacker is able to decrypt arbitary messages using the app anyways.

The security goals that must be met, is that:

  • While the attacker does not have access to the phone, the attacker should not be able to authenticate.

  • If the attacker does have access to the phone, even for a long time, he should be able to authenticate, but not extract the private key.

  • When attacker does no longer have access to the phone, for example if the attacker is a previous employee that have been fired and then have turned in the phone, the attacker should no longer be able to authenticate, even if he previously did have access to the phone, and even if the keypair inside the secure hardware, has not been changed.

On this page, the answer mentions its possible to extract the private key, by mounting a padding oracle attack: What specific padding weakness does OAEP address in RSA?

However, the wikipedia page, mentions no reveal of private keys: https://en.wikipedia.org/wiki/Padding_oracle_attack

But the wikipedia page mentions, using the padding oracle, a attacker is able to decrypt arbitary messages, by just checking the padding oracle replies, without having access to the either the key nor the plaintext output of the decryption engine. However, in this case, when a attacker does have access to the padding oracle, the attacker also have access to the plaintext output and vice versa, which means that decryption of arbitary messages is already possible when the attacker does have access to the decryption engine, without having to resort to a padding oracle attack.

The 2 things are completely different, because with the private key, the attacker is able to do decryption while he no longer have access to the padding oracle, but if the padding oracle can only be used to decrypt messages, the padding oracle effectively becomes useless to the attacker in this case, because when the attacker no longer have padding oracle access, he can no longer do decryption, and the security goal is met.

The questions I have is:

1: Is it safe to use PKCS 1.5 in this case?

2: Is it really possible to extract the private key using a padding oracle, or does the padding oracle just allow arbitary message decryption? The 2 linked articles are ambigious in that regard.

    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
    Bumped by Community user
1
source | link

Does PKCS 1.5 padding make it possible for an attacker to extract the private key or not? Is PKCS 1.5 safe to use in authentication context?

Im currently writing a authentication app based on RSA, for Android that should be impossible to copy, even if you have physical access to a phone without lockscreen/PIN.

However, the HSM inside the phone, that ensures the private key can never leave the storage, only be "used", does only support PKCS 1.5 padding due to a bug in the bouncycastle implementation.

The encrypted messages, will be different every time (nonce) so theres no possibility to observe that two encrypted messages are identical over the wire.

A attacker or adversiary, while not having access to the phone, does not have access to a padding oracle. The app works by having the user scan a encrypted QR and this encrypted QR decrypts into a OTP code. Yes, the attacker can display, on a phishing page or hijacked connection, a QR code containing padding errors, and observe if the user proceeds with authentication (enters a valid OTP) or not, but what I read on some pages, a padding oracle attack requires millions of "tests" against the padding.

When the attacker or adversiary do have access to the phone, the attacker can use the phone itself as padding oracle, but also, when having access to the phone, the attacker is able to decrypt arbitary messages using the app anyways.

The security goals that must be met, is that:

  • While the attacker does not have access to the phone, the attacker should not be able to authenticate.

  • If the attacker does have access to the phone, even for a long time, he should be able to authenticate, but not extract the private key.

  • When attacker does no longer have access to the phone, for example if the attacker is a previous employee that have been fired and then have turned in the phone, the attacker should no longer be able to authenticate, even if he previously did have access to the phone, and even if the keypair inside the secure hardware, has not been changed.

On this page, the answer mentions its possible to extract the private key, by mounting a padding oracle attack: What specific padding weakness does OAEP address in RSA?

However, the wikipedia page, mentions no reveal of private keys: https://en.wikipedia.org/wiki/Padding_oracle_attack

But the wikipedia page mentions, using the padding oracle, a attacker is able to decrypt arbitary messages, by just checking the padding oracle replies, without having access to the either the key nor the plaintext output of the decryption engine. However, in this case, when a attacker does have access to the padding oracle, the attacker also have access to the plaintext output and vice versa, which means that decryption of arbitary messages is already possible when the attacker does have access to the decryption engine, without having to resort to a padding oracle attack.

The 2 things are completely different, because with the private key, the attacker is able to do decryption while he no longer have access to the padding oracle, but if the padding oracle can only be used to decrypt messages, the padding oracle effectively becomes useless to the attacker in this case, because when the attacker no longer have padding oracle access, he can no longer do decryption, and the security goal is met.

The questions I have is:

1: Is it safe to use PKCS 1.5 in this case?

2: Is it really possible to extract the private key using a padding oracle, or does the padding oracle just allow arbitary message decryption? The 2 linked articles are ambigious in that regard.