PEM private keys detect enchancement

[babenek]

Description

Please include a summary of the change and which is fixed.

• "filter_type" is an optional field in rules.
• PEM private key Elliptic Curves are found also
• strict filtering for PEM keys (ASN1 or keyword "bcrypt")
• Encrypted keys are skipped
• PGP keys are checked with entropy only

How has this been tested?

Please describe the tests that you ran to verify your changes.

• UnitTest
• Benchmark
• TODO: rollback custom benchamark after PRIVATE KEYS markup CredData#52

[codecov-commenter]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (7559f13) 90.58% compared to head (5e87de1) 90.33%.

Files	Patch %	Lines
credsweeper/scanner/scan_type/pem_key_pattern.py	80.00%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #456      +/-   ##
==========================================
- Coverage   90.58%   90.33%   -0.26%     
==========================================
  Files         126      125       -1     
  Lines        4280     4293      +13     
  Branches      679      688       +9     
==========================================
+ Hits         3877     3878       +1     
- Misses        267      274       +7     
- Partials      136      141       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[csh519]

Could you explain it more about why you decided to remove EC keyword from the pattern?
I think EC(elliptic curve encryption) can't be decrypted..

[babenek]

In openssl/test exists not encrypted EC key https://github.com/openssl/openssl/blob/master/test/testec-p256.pem.
It can be analysed with ASN1 parser. It works without a password:

openssl dgst -sha256 -sign testec-p256.pem -out signature.bin smcont.txt 
openssl dgst -sha256 -verify testecpub-p256.pem  -signature signature.bin smcont.txt 

Encrypted key i found has structure like this and cannot be parsed with asn1:

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,692.....

BXv....

So, i think, with the simple analysis for ASN1 structure we can decide whether a key is encrypted or not in the level.

[csh519]

Oh.. i didn't know about that.
Yes, using ASN1 decryption can be a solution.
How about change the logic to check ASN1 decryptable if the line includes EC keyword?
And other cases that doesn't include EC keyword just follow the logic before.

[babenek]

Full decryption is not acceptable for obfuscated benchmark. If first symbols are not changed - the header might be parsed in benchmark.

[babenek]

@csh519
EC keys are ASN1 too (if are not encrypted), so the approach may be used too.
OPENSSH keys have PBKDF2 format and cannot be checked with the obfuscated values. Only keyword 'bcrypt' in header may point to encrypted key.
PGP is still checked for entropy..

[kmnls]

Agree

[babenek]

TODO: rollback benchmark reference before merge

[babenek]

@csh519 @kmnls @Yullia @xDizzix @iuriimet
please approve Samsung/CredData#52 first