-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed encryption padding for PoP flow #2203
base: dev
Are you sure you want to change the base?
Conversation
if (enableImport && Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) { | ||
purposes |= KeyProperties.PURPOSE_WRAP_KEY; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need the PURPOSE_WRAP_KEY as well in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with suggestion.
@@ -450,10 +431,8 @@ private void initialize28(@androidx.annotation.NonNull final KeyPairGenerator ke | |||
final boolean useStrongbox, | |||
final boolean enableImport, | |||
final boolean trySetAttestationChallenge) throws InvalidAlgorithmParameterException { | |||
int purposes = KeyProperties.PURPOSE_SIGN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also need this change in initialize23 method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's verify with defender before merging this. Great work!
Issue description : When a device is newly Intune enrolled in A14, the user is able to login to Defender, but unable to retrieve the pop access token. As a fallback, Defender allows onboarding without pop token (which is why you were able to onboard fully to Defender). However, in absence of the correct token Defender backend does not acknowledge heartbeat calls we send every few hours to maintain device compliance. Heartbeat failure subsequently fails the signals being sent to Intune backend marking the device non-compliant (Device_Threat_Health_Not_Reported reported by Intune).
This is an issue especially when policies are setup to make the device noncompliant if Defender is not setup (this is what Microsoft has setup internally).
Bug link : https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2574078
Previous temporary fix : #2053
The fix in the PR above was only to catch the exception and swallow it and skip trying to use strong box for key pair generation.
Current fix : After I raised this issue with google, they suggested that we should reduce the keyParameters and try. By removing the encryption paddings, the issue seems to be resolved. Also checked with Amit and it seems we are not doing any encryption or decryption using the key pair generated. We are only signing. So, I also removed some of the purposes like VERIFY, ENCRYPT and DECRYPT. While I am still following up with them on why it is specifically failing on Android 14, I have applied the fix they suggested.
Testing : Tested with MsalTestApp with AuthScheme as POP and verified that acquireToken interactive and silent flows are working as expected. Also, I ran the UI tests for POP.
Note : This fix is yet to be verified by Defender team.