Raw AES Keyring zeros out passed in unwrappedMasterKey
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- typescript
- Lĩnh vực
- cryptography
Hướng nghiên cứu
Đọc mã của trình quản lý vật liệu trong modules/material-management/src/cryptographic_material.ts quanh các dòng 823-838, sau đó kiểm tra hàm khởi tạo của Raw AES keyring trong modules/raw-aes-keyring-node/src/raw_aes_keyring_node.ts quanh dòng 63. Xác nhận rằng hàm khởi tạo tạo một bản sao phòng thủ của unwrappedMasterKey do khách hàng cung cấp để việc xử lý vật liệu sau đó không ghi số 0 vào buffer của bên gọi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem:
The materials manager zeros out the dataKey in the processing of creating wrapping key material during construction:
https://github.com/aws/aws-encryption-sdk-javascript/blob/6b1d1a6cd62d56dfb47eb9b70307b5f9083e5e10/modules/material-management/src/cryptographic_material.ts#L823-L838
This is normally good practice. However in the case where the buffer has been passed in by the customer via Keyring creation, for example in the Raw AES Keyring case, this leads to surprising behavior.
The Raw AES Keyrings does not make a defensive copy of the key material before creating this material: https://github.com/aws/aws-encryption-sdk-javascript/blob/master/modules/raw-aes-keyring-node/src/raw_aes_keyring_node.ts#L63
And thus the "unwrappedMasterKey" that the customer passed in looks like it gets "consumed." This is surprising to the customer, especially since our docs have no indication of this behavior.
Solution:
The Raw AES Keyring should make a defensive copy of the "unwrappedMasterKey" in it's constructor. It is the responsibility of the customer to zero out the "unwrappedMasterKey" in their application after creation of the Keyring if it is no longer needed, in order to minimize the time the data key exists in plaintext in memory.
Out of scope:
Is there anything the solution will intentionally NOT address?
- Ngôn ngữ chính
- TypeScript
- Star
- 260
- Fork
- 68
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của aws/aws-encryption-sdk-javascript
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
aws/aws-encryption-sdk-javascript#1656 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 68/100
aws/aws-encryption-sdk-javascript#1691 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
aws/aws-encryption-sdk-javascript#1665 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
aws/aws-encryption-sdk-javascript#1663 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
aws/aws-encryption-sdk-javascript#1520 · 1 bình luận ·
Tất cả issue của aws/aws-encryption-sdk-javascript
Issue tương tự
-
Claiming namespace Londopy Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
EclipseFdn/open-vsx.org#13385 · 1 bình luận ·
-
S: triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
snapshot-labs/stamp#666 ·
-
vangogh
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
knaw-huc/textannoviz#691 ·