Làm cách nào một máy chủ có thể xác thực ứng dụng iPhone (mã, chứ không phải người dùng)?

Question

Giả sử tôi có giải pháp liên quan đến ứng dụng iPhone tạo ra một số thông tin và sau đó gửi thông tin đó đến dịch vụ web để xử lý. Điều quan trọng là yêu cầu ONLY từ các trường hợp của ứng dụng iPhone cụ thể này được phép xử lý (có thể có nhiều trường hợp ứng dụng được nhiều người dùng sử dụng, nhưng tôi muốn chắc chắn rằng tất cả chúng đều sử dụng mã mà tôi tin tưởng). Nói cách khác, tôi muốn chắc chắn rằng ứng dụng iPhone của tôi không thể được (dễ dàng) mạo danh bởi các khách hàng khác. Bạn sẽ làm điều này như thế nào?

Answer 1

Tất cả các câu trả lời khác cung cấp các cách hợp pháp để cung cấp thêm một số bảo mật bổ sung nhưng không hoàn hảo. Bạn nên biết trước (vì không ai khác rõ ràng) rằng không thể để cung cấp các thông tin về mặt lý thuyết an toàn sao cho máy chủ của bạn luôn có thể xác thực rằng ứng dụng ở đầu kia là bản sao ứng dụng đang chạy của bạn phần cứng bị xử phạt. Bạn không thể làm điều này bởi vì bất kỳ bảo mật cấp độ phần cứng nào Apple đã xây dựng để khởi động một chuỗi tin cậy (để điều này có thể thực sự có thể cho họ), họ không tiếp xúc với bạn.

Chiến lược của bạn do đó phải là một trong nhiều "rào cản", một số lớn hơn, một số nhỏ hơn, được thiết kế để ngăn chặn mức độ phức tạp của tấn công và sự tinh tế của kẻ tấn công. Xem các câu trả lời khác cho câu hỏi này cho một số ý tưởng hay. Có bao nhiêu rào cản bạn cần, và của sự tinh tế, phụ thuộc hoàn toàn vào chi phí cho bạn (kinh tế, tin tưởng, bất cứ điều gì) của việc có một cuộc tấn công thành công.

Cũng nên xem xét ý tưởng rằng nếu bạn có thể tránh được cuộc tấn công bảo mật "có thể tái sản xuất", bạn sẽ tốt hơn. Nói cách khác, nếu ai đó phá vỡ ứng dụng/giao thức của bạn và dữ liệu cho những người khác làm điều đó giống nhau cho mỗi bản sao/bản sao thì bạn gặp nhiều rắc rối hơn, vì các hướng dẫn/khóa có thể được đăng lên web một vài nơi. Nếu bạn có thể tìm ra cách để làm cho mọi bản sao/khách hàng trở nên độc đáo, thì bạn có thể quan sát trên máy chủ và ở mức tồi tệ nhất, cắt các máy khách bị hỏng, v.v. (Điều này thật khó trên nền tảng iPhone.)

Answer 2

Bạn có thể ẩn khóa cá nhân trong ứng dụng của mình được sử dụng cho số challenge-response authentication.

Nếu câu trả lời này quá ngắn/trừu tượng, hãy để lại nhận xét và tôi sẽ giải thích chi tiết hơn.

Edit:

tôi muốn thêm rằng tôi không nghĩ rằng có một an toàn (như trong reverse-engeneering-safe) cách để làm việc chứng thực được mô tả. Nhưng trong những điều bảo mật, tôi thấy mình thường xuyên sai lầm hơn bao giờ hết.

Answer 3

Sử dụng Id thiết bị của bạn ... Gửi Id thiết bị với yêu cầu ... mỗi iphone sẽ có duy nhất Device ID

Answer 4

Bất kỳ thông tin liên lạc đi tạo bởi ứng dụng của bạn có thể bị chặn và tái hiện lại sau đó. Nếu bạn muốn chắc chắn rằng một yêu cầu đến từ ứng dụng của bạn, bạn có thể làm những việc như nhúng các khóa công cộng (không phải riêng tư) trong ứng dụng của bạn và sử dụng nó để ký thông tin liên lạc của bạn. Tuy nhiên, trong tình huống như vậy, khóa riêng và khóa công khai không làm bất kỳ điều gì ngoại trừ việc không loại bỏ (ví dụ: chứng minh rằng chỉ người nhận dự định mới có thể đọc thư, vì họ là người duy nhất có nửa khớp của cặp khóa).

Điều bạn đang tìm kiếm là cung cấp tính xác thực. Bạn có thể làm điều gì đó như thực hiện trao đổi khóa DH (http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange) để tạo bí mật được chia sẻ (do mã hóa bí mật trong ứng dụng của bạn không đảm bảo bí mật), sau đó sử dụng bí mật đó để thực hiện thao tác cụ thể trên thư của bạn (mặc dù điều này vẫn không phải là tính xác thực hoàn hảo).

Hoặc bạn có thể làm điều gì đó như kiểm tra chữ ký mã của ứng dụng và xác minh rằng đó là chữ ký thích hợp và đó là ứng dụng của bạn hoặc một thứ gì đó tương tự.

Có lẽ Graham Lee sẽ bật lên và đưa ra câu trả lời tốt hơn. :)

EDIT

(suy nghĩ thành lời) Dưới đây là một ý tưởng: Sau khi ứng dụng của bạn trên các cửa hàng, bạn có thể trích xuất chữ ký mã của ứng dụng xuất bản, đặt trên máy chủ của bạn, và sử dụng trong một thách thức-phản ứng. Khi khách hàng của bạn kết nối với máy chủ, máy chủ của bạn có thể tạo ra một giá trị ngẫu nhiên và gửi lại. Máy khách có thể điều khiển giá trị đó bằng cách sử dụng chữ ký mã dựng sẵn của ứng dụng và trả về giá trị thao tác. Trong khi đó, máy chủ của bạn có thể làm điều tương tự. Khi máy chủ nhận được giá trị thao tác, nó có thể so sánh nó với phiên bản của nó và sau đó chấm dứt/tiếp tục kết nối dựa trên việc chúng có khớp hay không. Về mặt kỹ thuật, điều này vẫn có thể bị giả mạo (một ứng dụng khác có thể ăn cắp mã chữ ký và sử dụng nó), nhưng có vẻ như nó sẽ an toàn hơn.

Answer 5

Tôi hỏi một câu hỏi tương tự một khi trở lại:

Restricting access to server to iPhone app

Những gì tôi đã kết thúc làm là sử dụng một tên người dùng ngẫu nhiên tạo ra (GUID).Sau đó tôi lấy tên người dùng, thêm một bí mật (mã hóa cứng trong ứng dụng của tôi, được nhân đôi trên máy chủ), và SHA1 kết quả, và gửi mật khẩu đó làm mật khẩu.

Trên máy chủ, tôi lấy tên người dùng được cung cấp, nối thêm cùng một bí mật, băm và so sánh nó với những gì khách hàng đã gửi. Lưu ý rằng điều này cần phải được gửi qua SSL để thậm chí là an toàn từ xa.

Một cách tiếp cận khác là gửi chứng chỉ ứng dụng khách SSL với gói ứng dụng của bạn và định cấu hình máy chủ của bạn để chỉ chấp nhận các kết nối từ khách hàng có chứng chỉ đó.

Điểm yếu của cả hai trường hợp này là nếu ứng dụng của bạn bị bẻ khóa, sẽ không đáng kể khi trích xuất bí mật hoặc chứng chỉ ứng dụng khách.

Nếu mối quan tâm của bạn là không trả tiền cho khách hàng sử dụng tài nguyên máy chủ của bạn, bạn có một vấn đề hoàn toàn khác, bởi vì sau đó mô hình mối đe dọa chính của bạn là bản sao khởi động của ứng dụng đang chạy trên điện thoại đã được bẻ khóa. Xem câu trả lời cho câu hỏi của tôi cho một số biện pháp đối phó.

Answer 6

là yêu cầu ứng dụng cho một số phần nội dung của gói ứng dụng - chẳng hạn như byte 59967 của tệp thi hành ứng dụng, hoặc bao gồm plist hoặc xib. Bằng cách giữ cả tên tệp và vị trí được yêu cầu hoàn toàn ngẫu nhiên, bất kỳ ai giả mạo đều phải nhúng toàn bộ bản sao ứng dụng của bạn - điều này giúp bạn dễ dàng xác định xem họ có đang giả mạo ứng dụng của bạn hay không và có thể rất dễ dàng xảy ra với google. Bạn chỉ đơn giản là có khách hàng cung cấp cho bạn số phiên bản và trên máy chủ, bạn sẽ có bản sao của tất cả các tệp cho tất cả các phiên bản công khai để kiểm tra câu trả lời (và quyết định thử thách nào để gửi).

Vì không thể ngăn chặn điều này, điều tốt nhất tiếp theo là phát hiện giả mạo dễ quét nhất có thể và vì vậy tôi nghĩ về các giải pháp giúp bạn quan tâm hơn là cố gắng chặn không thể bỏ chặn (mặc dù một số chặn ban đầu tầm thường sẽ giữ cho riff-raff).

Về cơ bản, nhiều lớp hơn là một lớp thực sự cứng là những gì bạn muốn trong việc đảm bảo điều gì đó.

Answer 7

Khi ứng dụng khởi động, hãy gửi yêu cầu mã thông báo đến máy chủ.Sau đó, máy chủ gửi một mã thông báo (chỉ là một chuỗi bí mật, mới được tạo) tới máy khách thông qua APNS. Tất cả các giao tiếp tiếp theo đều xác thực với mã thông báo đó. Bạn thậm chí có thể duy trì mã thông báo 'an toàn' bằng cách sử dụng mặt Keychain của iPhone. Trong giới hạn những gì bạn muốn là, thực sự, không thể, nhưng theo cách này bạn dựa vào các công cụ của Apple nhiều hơn một chút.