Fix for SDL violation in device pop scenarios

[somalaya]

• 1 of the SDL assessments has a requirement that we should avoid using multiple crypto purposes with the same key.
• There are multiple places where we are using multiple purposes and device pop scenario is one of them.
• In Device pop scenario, we do not use encrypt/decrypt methods anywhere in our code. Only signing is used. Hence removing the ununsed purposes encrypt, decrypt from the key gen spec.
• Also, encrypt and decrypt methods added in IDevicePopManager.java are probably for maintaining all the crypto operations but I have deprecated them as they are not getting used.
• Added telemetry in mintSignedHttpRequest method.

Note : The flight to remove encryption paddings in initialize method of AndroidDevicePopManager is not going to be enabled until we observe telemetry added in this PR first. Idea is that the telemetry should prove that encrypt/decrypt methods are not getting used. Only then, we can enable the flight! So, this is going to be enabled in Jan/Feb next year.

[github-actions[bot]]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[github-actions[bot]]

✅ Work item link check complete. Description contains link AB#3284510 to an Azure Boards work item.

[mohitc1]

Is this needed if purpose does not have encrypt/decrypt/wrap?

If not, then this method is identical to initialize23, since caller decides if wrap key is to be set or not.

---

Refers to: common/src/main/java/com/microsoft/identity/common/internal/platform/AndroidDevicePopManager.java:470 in 42bf650. [](commit_id = 42bf650db7c308f6fd344527c16fc0de82d2b93c, deletion_comment = True)

[somalaya]

Is this needed if purpose does not have encrypt/decrypt/wrap?

If not, then this method is identical to initialize23, since caller decides if wrap key is to be set or not.

Refers to: common/src/main/java/com/microsoft/identity/common/internal/platform/AndroidDevicePopManager.java:470 in 42bf650. [](commit_id = 42bf650, deletion_comment = True)

If you meant the encryption padding, then yes it is not needed when purpose is not encrypt/decrypt/wrap. I have skipped adding this padding when the flight is ON in 5c852dbfbd0539b64aa05a6a2bf21fb239ccc6ed . Once the flight is completely ON, we can remove initialize23 and initalize28 and just add a check for Build version to use strongbox in API >=28.

[github-actions[bot]]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[mohitc1]

}

this sets it to null. Do we really need this method? if we delete this method, initialize23 and initialize28 can be simplified.

initialize23() also does not need to worry about Strongbox. If strong box is needed call initialize28

---

Refers to: common/src/main/java/com/microsoft/identity/common/internal/platform/AndroidDevicePopManager.java:424 in 9691151. [](commit_id = 9691151d60a2699eba730ea437639709da769024, deletion_comment = False)

[github-actions[bot]]

✅ Work item link check complete. Description contains link AB#3284510 to an Azure Boards work item.

[github-actions[bot]]

❌ Invalid work item number: AB#3284510

. Work item number must be a valid integer.

Click here to learn more.

[somalaya]

}

this sets it to null. Do we really need this method? if we delete this method, initialize23 and initialize28 can be simplified.

initialize23() also does not need to worry about Strongbox. If strong box is needed call initialize28

Refers to: common/src/main/java/com/microsoft/identity/common/internal/platform/AndroidDevicePopManager.java:424 in 9691151. [](commit_id = 9691151, deletion_comment = False)

Coming in next PR with a different flight