Thực hành tốt nhất để lưu trữ và bảo vệ các khóa API riêng tư trong các ứng dụng [đã đóng]

Hầu hết các nhà phát triển ứng dụng sẽ tích hợp một số thư viện của bên thứ ba vào ứng dụng của họ. Nếu đó là để truy cập một dịch vụ, chẳng hạn như Dropbox hoặc YouTube hoặc để ghi nhật ký sự cố. Số lượng thư viện và dịch vụ của bên thứ ba rất đáng kinh ngạc. Hầu hết các thư viện và dịch vụ đó được tích hợp bằng cách xác thực bằng cách nào đó với dịch vụ, hầu hết thời gian, điều này xảy ra thông qua khóa API. Vì mục đích bảo mật, các dịch vụ thường tạo ra một khóa công khai và riêng tư, thường được gọi là khóa bí mật. Thật không may, để kết nối với các dịch vụ, khóa riêng này phải được sử dụng để xác thực và do đó, có lẽ là một phần của ứng dụng. Không cần phải nói, rằng điều này phải đối mặt với vấn đề an ninh rất lớn. Khóa API công khai và riêng tư có thể được trích xuất từ ​​APK trong vài phút và có thể dễ dàng được tự động hóa.

Giả sử tôi có một cái gì đó tương tự như thế này, làm thế nào tôi có thể bảo vệ khóa bí mật:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

Theo bạn, cách tốt nhất và an toàn nhất để lưu trữ khóa riêng là gì? Obfuscation, mã hóa, bạn nghĩ gì?

1. Như vậy, ứng dụng đã biên dịch của bạn chứa các chuỗi khóa, nhưng cũng có tên không đổi APP_KEY và APP_SECRET. Trích xuất các khóa từ mã tự viết tài liệu như vậy là không đáng kể, ví dụ với công cụ Android tiêu chuẩn dx.

2. Bạn có thể áp dụng ProGuard. Nó sẽ để lại các chuỗi khóa không bị ảnh hưởng, nhưng nó sẽ loại bỏ các tên không đổi. Nó cũng sẽ đổi tên các lớp và phương thức với các tên ngắn, vô nghĩa, nếu có thể. Việc trích xuất các khóa sau đó sẽ mất thêm thời gian để tìm ra chuỗi nào phục vụ mục đích nào.

   Lưu ý rằng việc thiết lập ProGuard không nên khó khăn như bạn sợ. Để bắt đầu, bạn chỉ cần kích hoạt ProGuard, như được ghi lại trong project.properations. Nếu có bất kỳ vấn đề nào với các thư viện của bên thứ ba, bạn có thể cần phải loại bỏ một số cảnh báo và / hoặc ngăn không cho chúng bị xáo trộn, trong proguard-project.txt. Ví dụ:

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }

   Đây là một cách tiếp cận vũ phu; bạn có thể tinh chỉnh cấu hình như vậy một khi ứng dụng được xử lý hoạt động.

3. Bạn có thể làm xáo trộn các chuỗi theo cách thủ công trong mã của mình, ví dụ với mã hóa Base64 hoặc tốt nhất là với một cái gì đó phức tạp hơn; thậm chí có thể mã nguồn. Sau đó, một hacker sẽ phải thiết kế đảo ngược tĩnh mã hóa mã hóa của bạn hoặc tự động chặn mã hóa ở vị trí thích hợp.

4. Bạn có thể áp dụng một obfuscator thương mại, như anh chị em chuyên biệt của ProGuard, DexGuard . Nó cũng có thể mã hóa / làm xáo trộn các chuỗi và các lớp cho bạn. Trích xuất các khóa sau đó thậm chí còn mất nhiều thời gian và chuyên môn hơn.

5. Bạn có thể chạy các phần của ứng dụng trên máy chủ của riêng bạn. Nếu bạn có thể giữ chìa khóa ở đó, chúng an toàn.

Cuối cùng, đó là một sự đánh đổi kinh tế mà bạn phải thực hiện: các khóa quan trọng như thế nào, bạn có thể mua bao nhiêu thời gian hoặc phần mềm, các hacker quan tâm đến các khóa như thế nào, họ sẽ muốn bao nhiêu thời gian chi tiêu, đáng giá bao nhiêu là một sự chậm trễ trước khi các khóa bị hack, theo quy mô nào thì bất kỳ tin tặc thành công nào sẽ phân phối các khóa, v.v. Những mẩu thông tin nhỏ như khóa khó bảo vệ hơn toàn bộ ứng dụng. Về mặt bản chất, không có gì ở phía khách hàng là không thể phá vỡ, nhưng bạn chắc chắn có thể nâng thanh.

(Tôi là nhà phát triển của ProGuard và DexGuard)

Vài ý tưởng, theo tôi chỉ có ý tưởng đầu tiên đưa ra một số đảm bảo:

1. Giữ bí mật của bạn trên một số máy chủ trên internet, và khi cần chỉ cần lấy chúng và sử dụng. Nếu người dùng sắp sử dụng dropbox thì không có gì ngăn bạn đưa ra yêu cầu đến trang web của bạn và lấy khóa bí mật của bạn.

2. Đặt bí mật của bạn trong mã jni, thêm một số mã biến để làm cho thư viện của bạn lớn hơn và khó dịch hơn. Bạn cũng có thể chia chuỗi khóa thành nhiều phần và giữ chúng ở nhiều nơi.

3. sử dụng obfuscator, cũng đặt mã băm bí mật và sau đó không xóa nó khi cần sử dụng.

4. Đặt khóa bí mật của bạn làm pixel cuối cùng của một trong những hình ảnh của bạn trong tài sản. Sau đó, khi cần đọc nó trong mã của bạn. Làm xáo trộn mã của bạn sẽ giúp ẩn mã sẽ đọc nó.

Nếu bạn muốn có một cái nhìn nhanh chóng về việc đọc mã apk của bạn dễ dàng như thế nào thì hãy lấy APKAnalyser:

http://developer.sonymobile.com/ledgeledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

Một cách tiếp cận khác là không có bí mật trên thiết bị ngay từ đầu! Xem Kỹ thuật bảo mật API di động (đặc biệt là phần 3).

Sử dụng truyền thống tôn vinh thời gian được tôn vinh, chia sẻ bí mật giữa điểm cuối API của bạn và dịch vụ xác thực ứng dụng.

Khi khách hàng của bạn muốn thực hiện cuộc gọi API , nó sẽ yêu cầu dịch vụ xác thực ứng dụng xác thực nó (sử dụng các kỹ thuật chứng thực từ xa mạnh mẽ) và nó nhận được mã thông báo giới hạn thời gian (thường là JWT ) được ký bởi bí mật.

Mã thông báo được gửi với mỗi lệnh gọi API trong đó điểm cuối có thể xác minh chữ ký của nó trước khi thực hiện yêu cầu.

Bí mật thực sự không bao giờ có trên thiết bị; trong thực tế, ứng dụng không bao giờ có bất kỳ ý tưởng nào nếu nó hợp lệ hay không, nó sẽ yêu cầu xác thực và chuyển mã thông báo kết quả. Là một lợi ích tốt từ sự gián tiếp, nếu bạn muốn thay đổi bí mật, bạn có thể làm như vậy mà không yêu cầu người dùng cập nhật các ứng dụng đã cài đặt của họ.

Vì vậy, nếu bạn muốn bảo vệ bí mật của mình, không có nó trong ứng dụng của bạn ngay từ đầu là một cách khá tốt để đi.

Cách không bảo đảm cũ:

Thực hiện theo 3 bước đơn giản để bảo mật API / Khóa bí mật ( Câu trả lời cũ )

Chúng tôi có thể sử dụng Gradle để bảo mật khóa API hoặc Khóa bí mật.

1. gradle.properies (Thuộc tính dự án): Tạo biến bằng khóa.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Module: app): Đặt biến trong build.gradle để truy cập nó trong hoạt động hoặc đoạn. Thêm mã dưới đây vào buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Truy cập nó trong Activity / Fragment bởi ứng dụng BuildConfig:

BuildConfig.GoogleSecAPIKEY

Cập nhật:

Giải pháp trên hữu ích trong dự án nguồn mở để cam kết với Git. (Cảm ơn David Rawson và riyaz-ali vì bình luận của bạn).

Theo nhận xét của Matthew và Pablo Cegarra, cách trên không an toàn và Decompiler sẽ cho phép ai đó xem BuildConfig bằng các khóa bí mật của chúng tôi.

Giải pháp :

Chúng tôi có thể sử dụng NDK để bảo mật API khóa. Chúng ta có thể lưu trữ các khóa trong lớp C / C ++ bản địa và truy cập chúng trong các lớp Java của chúng ta.

Vui lòng theo dõi blog này để bảo mật các khóa API bằng NDK.

Hướng dẫn về cách lưu trữ mã thông báo an toàn trong Android

Khóa bí mật ứng dụng nên được giữ riêng tư - nhưng khi phát hành ứng dụng, chúng có thể bị đảo ngược bởi một số kẻ.

Đối với những kẻ đó, nó sẽ không ẩn, khóa ProGuardmã. Nó là một bộ tái cấu trúc và một số obfuscators trả phí đang chèn một vài toán tử bitwise để lấy lại jk433g34hg3 String. Bạn có thể thực hiện hack từ 5 đến 15 phút nếu bạn làm việc 3 ngày :)

Cách tốt nhất là giữ nó như nó là, imho.

Ngay cả khi bạn lưu trữ ở phía máy chủ (PC), khóa vẫn có thể bị hack và in ra. Có lẽ điều này mất nhiều thời gian nhất? Dù sao đó là vấn đề của vài phút hoặc vài giờ trong trường hợp tốt nhất.

Một người dùng bình thường sẽ không dịch ngược mã của bạn.

Một giải pháp khả thi là mã hóa dữ liệu trong ứng dụng của bạn và sử dụng giải mã khi chạy (khi bạn muốn sử dụng dữ liệu đó). Tôi cũng khuyên bạn nên sử dụng progaurd để làm cho nó khó đọc và hiểu mã nguồn được dịch ngược của ứng dụng của bạn. ví dụ: tôi đặt một khóa được mã hóa trong ứng dụng và sau đó sử dụng phương thức giải mã trong ứng dụng của mình để giải mã các khóa bí mật của mình khi chạy:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Mã nguồn được dịch ngược của ứng dụng được bảo vệ là đây:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

Ít nhất nó đủ phức tạp đối với tôi. đây là cách tôi làm khi không có lựa chọn nào khác ngoài việc lưu trữ một giá trị trong ứng dụng của mình. Tất nhiên tất cả chúng ta đều biết Đó không phải là cách tốt nhất nhưng nó hiệu quả với tôi.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Phiên bản dịch ngược:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

và bạn có thể tìm thấy rất nhiều lớp mã hóa với một chút tìm kiếm trong google.

Thêm vào giải pháp @Manohar Reddy, cơ sở dữ liệu firebase hoặc firebase RemoteConfig (với giá trị mặc định Null) có thể được sử dụng:

1. Mật mã khóa của bạn
2. Lưu trữ nó trong cơ sở dữ liệu firebase
3. Nhận nó trong khi khởi động ứng dụng hoặc bất cứ khi nào cần thiết
4. giải mã các khóa và sử dụng nó

Điều gì khác biệt trong giải pháp này?

• không có tín dụng cho căn cứ hỏa lực
• Quyền truy cập firebase được bảo vệ nên chỉ ứng dụng có chứng chỉ đã ký mới có đặc quyền thực hiện cuộc gọi API
• mã hóa / giải mã để ngăn chặn sự can thiệp của người trung gian. Tuy nhiên, cuộc gọi đã https đến căn cứ hỏa lực

Ví dụ này có một số khía cạnh khác nhau với nó. Tôi sẽ đề cập đến một vài điểm mà tôi không nghĩ rằng đã được đề cập rõ ràng ở nơi khác.

Bảo vệ bí mật trong quá cảnh

Điều đầu tiên cần lưu ý là việc truy cập API dropbox bằng cơ chế xác thực ứng dụng của họ yêu cầu bạn truyền khóa và bí mật của mình. Kết nối là HTTPS, có nghĩa là bạn không thể chặn lưu lượng mà không biết chứng chỉ TLS. Điều này là để ngăn chặn một người chặn và đọc các gói trên hành trình của họ từ thiết bị di động đến máy chủ. Đối với người dùng bình thường, đó là một cách thực sự tốt để đảm bảo sự riêng tư của lưu lượng truy cập của họ.

Những gì nó không tốt, là ngăn chặn một kẻ độc hại tải xuống ứng dụng và kiểm tra lưu lượng. Thật sự dễ dàng khi sử dụng proxy trung gian cho tất cả lưu lượng truy cập vào và ra khỏi thiết bị di động. Nó sẽ không yêu cầu tháo gỡ hoặc thiết kế ngược mã để trích xuất khóa ứng dụng và bí mật trong trường hợp này do bản chất của API Dropbox.

Bạn có thể thực hiện ghim kiểm tra xem chứng chỉ TLS bạn nhận được từ máy chủ có phải là chứng chỉ bạn mong đợi không. Điều này thêm một kiểm tra cho khách hàng và làm cho việc chặn lưu lượng truy cập khó khăn hơn. Điều này sẽ khiến việc kiểm tra lưu lượng trong chuyến bay trở nên khó khăn hơn, nhưng kiểm tra ghim xảy ra trong máy khách, do đó có khả năng vẫn có thể vô hiệu hóa kiểm tra ghim. Nó làm cho nó khó hơn mặc dù.

Bảo vệ bí mật khi nghỉ ngơi

Bước đầu tiên, sử dụng một cái gì đó như proguard sẽ giúp làm cho nó ít rõ ràng hơn khi có bất kỳ bí mật nào được giữ. Bạn cũng có thể sử dụng NDK để lưu trữ khóa và bí mật và gửi yêu cầu trực tiếp, điều này sẽ giúp giảm đáng kể số lượng người có kỹ năng phù hợp để trích xuất thông tin. Việc che giấu thêm có thể đạt được bằng cách không lưu trữ các giá trị trực tiếp trong bộ nhớ trong bất kỳ khoảng thời gian nào, bạn có thể mã hóa chúng và giải mã chúng ngay trước khi sử dụng theo đề xuất của câu trả lời khác.

Tùy chọn nâng cao hơn

Nếu bây giờ bạn đang hoang tưởng về việc đặt bí mật ở bất cứ đâu trong ứng dụng của mình và bạn có thời gian và tiền bạc để đầu tư vào các giải pháp toàn diện hơn, thì bạn có thể xem xét việc lưu trữ thông tin đăng nhập trên máy chủ của mình (giả sử bạn có bất kỳ). Điều này sẽ làm tăng độ trễ của bất kỳ cuộc gọi nào tới API, vì nó sẽ phải liên lạc qua máy chủ của bạn và có thể làm tăng chi phí vận hành dịch vụ của bạn do tăng thông lượng dữ liệu.

Sau đó, bạn phải quyết định cách tốt nhất để liên lạc với máy chủ của mình để đảm bảo chúng được bảo vệ. Điều này rất quan trọng để ngăn chặn tất cả các vấn đề tương tự xuất hiện trở lại với API nội bộ của bạn. Nguyên tắc tốt nhất tôi có thể đưa ra là không truyền trực tiếp bất kỳ bí mật nào vì mối đe dọa trung gian. Thay vào đó, bạn có thể ký lưu lượng bằng cách sử dụng bí mật của mình và xác minh tính toàn vẹn của bất kỳ yêu cầu nào đến máy chủ của bạn. Một cách tiêu chuẩn để làm điều này là tính toán một HMAC của thông điệp được khóa trong một bí mật. Tôi làm việc tại một công ty có một sản phẩm bảo mật cũng hoạt động trong lĩnh vực này, đó là lý do tại sao loại công cụ này làm tôi quan tâm. Trong thực tế, đây là một bài viết blog từ một trong những đồng nghiệp của tôi đi qua hầu hết điều này.

Tôi nên làm bao nhiêu?

Với bất kỳ lời khuyên bảo mật nào như thế này, bạn cần đưa ra quyết định chi phí / lợi ích về mức độ khó khăn của bạn khi khiến ai đó đột nhập. Nếu bạn là ngân hàng bảo vệ hàng triệu khách hàng, ngân sách của bạn hoàn toàn khác với ai đó hỗ trợ ứng dụng trong họ thời gian rảnh. Hầu như không thể ngăn ai đó phá vỡ an ninh của bạn, nhưng trong thực tế, rất ít người cần tất cả chuông và còi và với một số biện pháp phòng ngừa cơ bản, bạn có thể đi được một chặng đường dài.

Giải pháp an toàn nhất là giữ các khóa của bạn trên máy chủ và định tuyến tất cả các yêu cầu cần khóa đó thông qua máy chủ của bạn. Bằng cách đó, khóa không bao giờ rời khỏi máy chủ của bạn, miễn là máy chủ của bạn được bảo mật thì khóa của bạn cũng vậy. Tất nhiên có một chi phí hiệu suất với giải pháp này.

Giữ bí mật firebase databasevà nhận được từ nó khi ứng dụng bắt đầu, Nó tốt hơn nhiều so với việc gọi một dịch vụ web.

Bất cứ điều gì bạn làm để bảo mật các khóa bí mật của bạn sẽ không phải là một giải pháp thực sự. Nếu nhà phát triển có thể dịch ngược ứng dụng thì không có cách nào để bảo mật khóa, việc ẩn khóa chỉ là bảo mật bằng cách che khuất và mã obfuscation cũng vậy. Vấn đề với việc bảo mật một khóa bí mật là để bảo mật nó, bạn phải sử dụng một khóa khác và khóa đó cũng cần phải được bảo mật. Hãy nghĩ về một chìa khóa được giấu trong một hộp được khóa bằng một chìa khóa. Bạn đặt một hộp bên trong một căn phòng và khóa phòng. Bạn còn lại một chìa khóa khác để bảo mật. Và khóa đó vẫn sẽ được mã hóa cứng trong ứng dụng của bạn.

Vì vậy, trừ khi người dùng nhập mã PIN hoặc cụm từ, không có cách nào để ẩn khóa. Nhưng để làm được điều đó, bạn sẽ phải có một kế hoạch quản lý mã PIN xảy ra ngoài băng, nghĩa là thông qua một kênh khác. Chắc chắn không thực tế để bảo mật các khóa cho các dịch vụ như Google API.

Lứa tuổi bài cũ, nhưng vẫn đủ tốt. Tôi nghĩ việc giấu nó trong một thư viện .so sẽ rất tuyệt, sử dụng NDK và C ++. Các tập tin .so có thể được xem trong trình soạn thảo hex, nhưng chúc may mắn dịch ngược rằng: P

Cách thực sự duy nhất để giữ riêng tư này là giữ chúng trên máy chủ của bạn và yêu cầu ứng dụng gửi bất cứ thứ gì đến máy chủ và máy chủ tương tác với Dropbox. Bằng cách đó, bạn KHÔNG BAO GIỜ phân phối khóa riêng của mình ở bất kỳ định dạng nào.

Dựa trên kinh nghiệm cay đắng và sau khi tham khảo ý kiến ​​chuyên gia IDA-Pro, giải pháp tốt nhất là chuyển một phần quan trọng của mã vào DLL / SharedObject, sau đó tìm nạp nó từ máy chủ và tải khi chạy.

Dữ liệu nhạy cảm phải được mã hóa vì nó rất dễ thực hiện như thế này:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD